lkml.org 
[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled
On Wed, Aug 24 2005, Esben Nielsen wrote:
> On Wed, 24 Aug 2005, Jens Axboe wrote:
>
> > On Wed, Aug 24 2005, Lee Revell wrote:
> > > Just found this in dmesg.
> > >
> > > BUG: scheduling with irqs disabled: libc6.postinst/0x20000000/13229
> > > caller is ___down_mutex+0xe9/0x1a0
> > > [<c029c1f9>] schedule+0x59/0xf0 (8)
> > > [<c029ced9>] ___down_mutex+0xe9/0x1a0 (28)
> > > [<c0221832>] cfq_exit_single_io_context+0x22/0xa0 (84)
> > > [<c02218ea>] cfq_exit_io_context+0x3a/0x50 (16)
> > > [<c021db84>] exit_io_context+0x64/0x70 (16)
> > > [<c011efda>] do_exit+0x5a/0x3e0 (20)
> > > [<c011f3ca>] do_group_exit+0x2a/0xb0 (24)
> > > [<c0103039>] syscall_call+0x7/0xb (20)
> >
> > Hmm, Ingo I seem to remember you saying that the following construct:
> >
> > local_irq_save(flags);
> > spin_lock(lock);
> >
> > which is equivelant to spin_lock_irqsave() in mainline being illegal in
> > -RT, is that correct?
>
> I can easily answer this for Ingo.
>
> Yes, spin_lock(lock) is blocking since lock is mutex, not a spinlock under
> preempt-rt. But isn't it easy to fix? Replace the two lines by
> spin_lock_irqsave(flags). That would work for both preempt-rt
> and !preempt-rt.

Well, it might and it might not be. There's a correctness and
optimization side to it. For this case it is probably doable, but I have
to say that the new semantics defy normal logic.

> You supposed to ask if the macro name spin_lock() isn't confusing. It very
> much is, but one of Ingo's aims is not to change existing code too much.
> The purist would probably change all instances of spin_lock() to lock() or
> down() to stop refering to a specific lock type when it can be changed
> with config-options. That would, however, require a large patch,
> which does the preempt-rt branch harder to merge with the main-line.

I can certainly understand Ingo's point of view, as long as he is
maintaining the patch outside of the kernel. Where it ever to go in,
this would have to change.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-25 08:13    [W:0.107 / U:0.608 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site