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 SM
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 wait
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 r
> 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
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
> >
** 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 th
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'
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 they
** 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
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 interfac
[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.
>
> Double take: we *did* fix the problems with del_t
> 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
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 (equ
[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
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, yo
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 di
** 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.
/usr/src/linux/Docume
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 "unsubsc
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
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
>
> joh
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
> 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 proc
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
/usr/src/linux-2.4/Documentation/Doc
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 kno
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 SMP.
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);
>
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 lin
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 proble
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()
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 sle
[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
39 matches
Mail list logo
