On Mon, Jan 29, 2001 at 09:35:53PM +0100, Andi Kleen wrote:
> On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
> > You still miss wakeups. :)
>
> And there was another race in it, I know. The first __set_task_state
> has to be set_task_state to get the right memory write order on
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
> Hi,
>
> On Mon, 29 Jan 2001, Andi Kleen wrote:
>
> > You can miss wakeups. The standard pattern is:
> >
> > get locks
> >
> > add_wait_queue(, );
> > for (;;) {
> > if (condition you're waiting for is
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
Hi,
On Mon, 29 Jan 2001, Andi Kleen wrote:
You can miss wakeups. The standard pattern is:
get locks
add_wait_queue(waitqueue, wait);
for (;;) {
if (condition you're waiting for is true)
On Mon, Jan 29, 2001 at 09:35:53PM +0100, Andi Kleen wrote:
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
You still miss wakeups. :)
And there was another race in it, I know. The first __set_task_state
has to be set_task_state to get the right memory write order on SMP.
Alan Cox wrote:
>
> > And one more point for the Janitor's list:
> > Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
> > either spin_lock_irq() or spin_lock() is sufficient. That's both faster
> > and better readable.
>
> Expect me to drop any submissions that do this. I'd
> And one more point for the Janitor's list:
> Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
> either spin_lock_irq() or spin_lock() is sufficient. That's both faster
> and better readable.
Expect me to drop any submissions that do this. I'd rather take the two
clock hit
On Tue, 30 Jan 2001, Timur Tabi wrote:
> > If you have a task that looks like:
> >
> > loop:
> >
> > sleep_on(q)
> >
> > And you do wakeup(q) hoping to get something important done, then if the
> > task isn't sleeping at the time of the wakeup it will ignore the wakeup
> >
And one more point for the Janitor's list:
Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
either spin_lock_irq() or spin_lock() is sufficient. That's both faster
and better readable.
Expect me to drop any submissions that do this. I'd rather take the two
clock hit in
Alan Cox wrote:
And one more point for the Janitor's list:
Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
either spin_lock_irq() or spin_lock() is sufficient. That's both faster
and better readable.
Expect me to drop any submissions that do this. I'd rather take
** Reply to message from Daniel Phillips <[EMAIL PROTECTED]> on Wed, 31
Jan 2001 01:06:08 +0100
> > What is wrong with sleep_on()?
>
> If you have a task that looks like:
>
> loop:
>
> sleep_on(q)
>
> And you do wakeup(q) hoping to get something important done, then if
Timur Tabi wrote:
>
> ** Reply to message from David Woodhouse
>
> > Note that this is _precisely_ the reason I'm advocating the removal of
> > sleep_on(). When I was young and stupid (ok, "younger and stupider") I used
> > sleep_on() in my code. I pondered briefly the fact that I really
Daniel Phillips wrote:
>
> Rusty Russell wrote:
> >
> > In message <[EMAIL PROTECTED]> you write:
> > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
> > >
> > > A lot of the timer deletion races are hard to fix because of
> > > the deadlock problem.
> >
> > Hmmm...
> >
>
[EMAIL PROTECTED] said:
> What is wrong with sleep_on()?
Are you asking me? If so, why did I not receive a copy in my inbox? If I
want to filter duplicates locally, I can. I don't.
It's almost impossible to use it safely, and the few ways you _can_ use it
safely are frowned upon, because
** Reply to message from David Woodhouse <[EMAIL PROTECTED]> on Tue, 30 Jan
2001 11:11:27 +
> Note that this is _precisely_ the reason I'm advocating the removal of
> sleep_on(). When I was young and stupid (ok, "younger and stupider") I used
> sleep_on() in my code. I pondered briefly
Rusty Russell wrote:
>
> In message <[EMAIL PROTECTED]> you write:
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
> >
> > A lot of the timer deletion races are hard to fix because of
> > the deadlock problem.
>
> Hmmm...
>
> For 2.5, changing the timer
[EMAIL PROTECTED] said:
> Remember, most of you guys have been coding for years, or working on
> the kernel for years. Some of us don't have that level of expertise,
> are trying to get it, and feel like we're being told that information
> is a private domain we aren't allowed in to.
Note that
[EMAIL PROTECTED] said:
Remember, most of you guys have been coding for years, or working on
the kernel for years. Some of us don't have that level of expertise,
are trying to get it, and feel like we're being told that information
is a private domain we aren't allowed in to.
Note that
Rusty Russell wrote:
In message [EMAIL PROTECTED] you write:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
A lot of the timer deletion races are hard to fix because of
the deadlock problem.
Hmmm...
For 2.5, changing the timer interface to disallow
** Reply to message from David Woodhouse [EMAIL PROTECTED] on Tue, 30 Jan
2001 11:11:27 +
Note that this is _precisely_ the reason I'm advocating the removal of
sleep_on(). When I was young and stupid (ok, "younger and stupider") I used
sleep_on() in my code. I pondered briefly the
Timur Tabi wrote:
** Reply to message from David Woodhouse
Note that this is _precisely_ the reason I'm advocating the removal of
sleep_on(). When I was young and stupid (ok, "younger and stupider") I used
sleep_on() in my code. I pondered briefly the fact that I really couldn't
** Reply to message from Daniel Phillips [EMAIL PROTECTED] on Wed, 31
Jan 2001 01:06:08 +0100
What is wrong with sleep_on()?
If you have a task that looks like:
loop:
do something important
sleep_on(q)
And you do wakeup(q) hoping to get something important done,
Rusty Russell wrote:
>
> > In message <[EMAIL PROTECTED]> you write:
> > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
> > >
> > > A lot of the timer deletion races are hard to fix because of
> > > the deadlock problem.
>
> Double take: we *did* fix the problems with
> In message <[EMAIL PROTECTED]> you write:
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
> >
> > A lot of the timer deletion races are hard to fix because of
> > the deadlock problem.
Double take: we *did* fix the problems with del_timer_sync(). We
should probably
In message <[EMAIL PROTECTED]> you write:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
>
> A lot of the timer deletion races are hard to fix because of
> the deadlock problem.
Hmmm...
For 2.5, changing the timer interface to disallow mod_timer or
add_timer
[Timur Tabi]
> [ttabi@one DocBook]$ make pdfdocs
> Makefile:140: /Rules.make: No such file or directory
>
> There's no Rules.make anywhere on my hard drive.
There had better be one in '../..'. Do the 'make pdfdocs' from the top
level of the kernel source tree.
Peter
-
To unsubscribe from
On Mon, Jan 29, 2001 at 10:27:50AM -0800, David D.W. Downey wrote:
> And don't tell me "Well, then you shouldn't be touching the kernel if
> you're not a developer" because that's crap too.
No this is a good advise. "Never touch anything you don't
understand." If you like to develop for Linux,
On Mon, Jan 29, 2001 at 02:51:18PM -0600, Timur Tabi wrote:
> ** Reply to message from [EMAIL PROTECTED] on Mon, 29 Jan 2001 20:44:55 + (GMT)
>
>
> > make pdfdocs
>
> [ttabi@one DocBook]$ make pdfdocs
> Makefile:140: /Rules.make: No such file or directory
You have to be in the top level
** Reply to message from [EMAIL PROTECTED] on Mon, 29 Jan 2001 20:44:55 + (GMT)
> make pdfdocs
[ttabi@one DocBook]$ make pdfdocs
Makefile:140: /Rules.make: No such file or directory
There's no Rules.make anywhere on my hard drive.
--
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon -
On Mon, 29 Jan 2001, David D.W. Downey wrote:
> Simply put, with all bitterness and finger pointing aside, WHERE do we
> find information on various kernel functions, their general usage (as in
> the WHY, not only the HOW) and reasonings on why not to use some
> vs. others.
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
> You still miss wakeups. :)
And there was another race in it, I know. The first __set_task_state
has to be set_task_state to get the right memory write order on SMP.
-Andi
-
To unsubscribe from this list: send the line
Hi,
On Mon, 29 Jan 2001, Andi Kleen wrote:
> You can miss wakeups. The standard pattern is:
>
> get locks
>
> add_wait_queue(, );
> for (;;) {
> if (condition you're waiting for is true)
> break;
> unlock any non sleeping
On Mon, 29 Jan 2001, John Levon wrote:
> huh ?
>
> http://www.kernelnewbies.org/books.php3
>
> /usr/src/linux-2.4/Documentation/DocBook
>
> /usr/src/linux/*
>
> try the last one on Windows. Please get your facts at least remotely near
> the truth before you rant on linux-kernel again
>
>
On Mon, Jan 29, 2001 at 11:01:31AM -0600, Timur Tabi wrote:
> What makes it more frustrating is that some people on this list talk as if
> things things are common knowledge. I've been following this mailing list for
> months, and until today I had no idea sleep_on was bad. All the
> Anything which uses sleep_on() has a 90% chance of being broken. Fix
> them all, because we want to remove sleep_on() and friends in 2.5.
This reminds me of a question I've been meaning to ask...
Suppose you were working on the new edition of the device drivers book,
which was just in the
On Mon, 29 Jan 2001, Timur Tabi wrote:
> This is driving me crazy! There is absolutely no documentation anywhere that
> tells you when to use or not use sleep_on or spin_lock_whatever or any of these
> calls.
huh ?
http://www.kernelnewbies.org/books.php3
This is driving me crazy! There is absolutely no documentation anywhere that
tells you when to use or not use sleep_on or spin_lock_whatever or any of these
calls. How is anyone supposed to know how to use these functions?! The post I
quoted below just proves that a lot of people think they
This is driving me crazy! There is absolutely no documentation anywhere that
tells you when to use or not use sleep_on or spin_lock_whatever or any of these
calls. How is anyone supposed to know how to use these functions?! The post I
quoted below just proves that a lot of people think they
On Mon, 29 Jan 2001, Timur Tabi wrote:
This is driving me crazy! There is absolutely no documentation anywhere that
tells you when to use or not use sleep_on or spin_lock_whatever or any of these
calls.
huh ?
http://www.kernelnewbies.org/books.php3
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and friends in 2.5.
This reminds me of a question I've been meaning to ask...
Suppose you were working on the new edition of the device drivers book,
which was just in the
On Mon, Jan 29, 2001 at 11:01:31AM -0600, Timur Tabi wrote:
What makes it more frustrating is that some people on this list talk as if
things things are common knowledge. I've been following this mailing list for
months, and until today I had no idea sleep_on was bad. All the documentation
On Mon, 29 Jan 2001, John Levon wrote:
huh ?
http://www.kernelnewbies.org/books.php3
/usr/src/linux-2.4/Documentation/DocBook
/usr/src/linux/*
try the last one on Windows. Please get your facts at least remotely near
the truth before you rant on linux-kernel again
john
Umm,
Hi,
On Mon, 29 Jan 2001, Andi Kleen wrote:
You can miss wakeups. The standard pattern is:
get locks
add_wait_queue(waitqueue, wait);
for (;;) {
if (condition you're waiting for is true)
break;
unlock any non
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
You still miss wakeups. :)
And there was another race in it, I know. The first __set_task_state
has to be set_task_state to get the right memory write order on SMP.
-Andi
-
To unsubscribe from this list: send the line
On Mon, 29 Jan 2001, David D.W. Downey wrote:
Simply put, with all bitterness and finger pointing aside, WHERE do we
find information on various kernel functions, their general usage (as in
the WHY, not only the HOW) and reasonings on why not to use some
vs. others.
** Reply to message from [EMAIL PROTECTED] on Mon, 29 Jan 2001 20:44:55 + (GMT)
make pdfdocs
[ttabi@one DocBook]$ make pdfdocs
Makefile:140: /Rules.make: No such file or directory
There's no Rules.make anywhere on my hard drive.
--
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon -
On Mon, Jan 29, 2001 at 02:51:18PM -0600, Timur Tabi wrote:
** Reply to message from [EMAIL PROTECTED] on Mon, 29 Jan 2001 20:44:55 + (GMT)
make pdfdocs
[ttabi@one DocBook]$ make pdfdocs
Makefile:140: /Rules.make: No such file or directory
You have to be in the top level
On Mon, Jan 29, 2001 at 10:27:50AM -0800, David D.W. Downey wrote:
And don't tell me "Well, then you shouldn't be touching the kernel if
you're not a developer" because that's crap too.
No this is a good advise. "Never touch anything you don't
understand." If you like to develop for Linux, you
[Timur Tabi]
[ttabi@one DocBook]$ make pdfdocs
Makefile:140: /Rules.make: No such file or directory
There's no Rules.make anywhere on my hard drive.
There had better be one in '../..'. Do the 'make pdfdocs' from the top
level of the kernel source tree.
Peter
-
To unsubscribe from this
In message [EMAIL PROTECTED] you write:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
A lot of the timer deletion races are hard to fix because of
the deadlock problem.
Hmmm...
For 2.5, changing the timer interface to disallow mod_timer or
add_timer
In message [EMAIL PROTECTED] you write:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
A lot of the timer deletion races are hard to fix because of
the deadlock problem.
Double take: we *did* fix the problems with del_timer_sync(). We
should probably have renamed
Hi,
On Sun, 28 Jan 2001, Manfred Spraul wrote:
> And one more point for the Janitor's list:
> Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
> either spin_lock_irq() or spin_lock() is sufficient. That's both faster
> and better readable.
>
> spin_lock_irq(): you know that
David Woodhouse wrote:
>
> TIOCMIWAIT does restore_flags() before interruptible_sleep_on(). It's
> broken too.
>
Yes, and I found a second bug: it doesn't sti() immediately after
interruptible_sleep_on(), thus cli() doesn't reacquire the global irq
lock --> the atomic copy won't be atomic on
On Sun, 28 Jan 2001, Manfred Spraul wrote:
> It isn't wrong to call schedule() with disabled interrupts - it's a
> feature ;-)
> Those 10% sleep_on() users that aren't broken use it:
>
> for(;;) {
> cli();
> if(condition)
> break;
> sleep_on(_wait_queue);
>
Arnaldo Carvalho de Melo wrote:
>
> Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu:
> > >
> > > Anything which uses sleep_on() has a 90% chance of being broken. Fix
> > > them all, because we want to remove sleep_on() and friends in 2.5.
> > >
> >
> > Then you can add 'calling
Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu:
> >
> > Anything which uses sleep_on() has a 90% chance of being broken. Fix
> > them all, because we want to remove sleep_on() and friends in 2.5.
> >
>
> Then you can add 'calling schedule() with disabled local interrupts()'
Em Sun, Jan 28, 2001 at 12:28:50PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu:
> > Arnaldo Carvalho de Melo wrote:
> > >
> > > Please send additions and corrections to me and I'll try
> > > to keep it updated.
> >
> > Here - have
>
> Anything which uses sleep_on() has a 90% chance of being broken. Fix
> them all, because we want to remove sleep_on() and friends in 2.5.
>
Then you can add 'calling schedule() with disabled local interrupts()'
to your list.
--
Manfred
-
To unsubscribe from this list: send the
Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu:
> Arnaldo Carvalho de Melo wrote:
> >
> > Please send additions and corrections to me and I'll try
> > to keep it updated.
>
> Here - have about 300 bugs:
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
Arnaldo Carvalho de Melo wrote:
>
> Please send additions and corrections to me and I'll try
> to keep it updated.
Here - have about 300 bugs:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
A lot of the timer deletion races are hard to fix because of
the deadlock
On Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > Please send additions and corrections to me and I'll try to keep it
> > updated.
> Anything which uses sleep_on() has a 90% chance of being broken. Fix
> them all, because we want to remove
Em Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse escreveu:
>
> [EMAIL PROTECTED] said:
> > Please send additions and corrections to me and I'll try to keep it
> > updated.
>
> Anything which uses sleep_on() has a 90% chance of being broken. Fix
> them all, because we want to remove
[EMAIL PROTECTED] said:
> Please send additions and corrections to me and I'll try to keep it
> updated.
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and friends in 2.5.
--
dwmw2
-
To unsubscribe from this list: send the
[EMAIL PROTECTED] said:
Please send additions and corrections to me and I'll try to keep it
updated.
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and friends in 2.5.
--
dwmw2
-
To unsubscribe from this list: send the
Em Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse escreveu:
[EMAIL PROTECTED] said:
Please send additions and corrections to me and I'll try to keep it
updated.
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on()
On Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse wrote:
[EMAIL PROTECTED] said:
Please send additions and corrections to me and I'll try to keep it
updated.
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and
Arnaldo Carvalho de Melo wrote:
Please send additions and corrections to me and I'll try
to keep it updated.
Here - have about 300 bugs:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
A lot of the timer deletion races are hard to fix because of
the deadlock problem.
Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu:
Arnaldo Carvalho de Melo wrote:
Please send additions and corrections to me and I'll try
to keep it updated.
Here - have about 300 bugs:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
A lot of
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and friends in 2.5.
Then you can add 'calling schedule() with disabled local interrupts()'
to your list.
--
Manfred
-
To unsubscribe from this list: send the line
Em Sun, Jan 28, 2001 at 12:28:50PM -0200, Arnaldo Carvalho de Melo escreveu:
Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu:
Arnaldo Carvalho de Melo wrote:
Please send additions and corrections to me and I'll try
to keep it updated.
Here - have about 300 bugs:
Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu:
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and friends in 2.5.
Then you can add 'calling schedule() with disabled local interrupts()'
to your
Arnaldo Carvalho de Melo wrote:
Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu:
Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and friends in 2.5.
Then you can add 'calling schedule() with
On Sun, 28 Jan 2001, Manfred Spraul wrote:
It isn't wrong to call schedule() with disabled interrupts - it's a
feature ;-)
Those 10% sleep_on() users that aren't broken use it:
for(;;) {
cli();
if(condition)
break;
sleep_on(my_wait_queue);
sti();
David Woodhouse wrote:
TIOCMIWAIT does restore_flags() before interruptible_sleep_on(). It's
broken too.
Yes, and I found a second bug: it doesn't sti() immediately after
interruptible_sleep_on(), thus cli() doesn't reacquire the global irq
lock -- the atomic copy won't be atomic on SMP.
Hi,
On Sun, 28 Jan 2001, Manfred Spraul wrote:
And one more point for the Janitor's list:
Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
either spin_lock_irq() or spin_lock() is sufficient. That's both faster
and better readable.
spin_lock_irq(): you know that the
74 matches
Mail list logo
