From: Benjamin Herrenschmidt on
On Wed, 2010-03-31 at 13:47 -0700, Yinghai Lu wrote:
> > perhaps the second one isn't needed? Perhaps no architecture
> requires
> > that local interrupts be disabled across the above initialisations?
>
> spin_unlock_irq from arm is different from other archs?

No, it's not, it will enable IRQs and thats illegal to do so early
during boot. We've been over that one again and again, the problem is
that people want to keep using that instead of irqsave/restore because
it's a nano-optimisation on x86... oh well...

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 03/31/2010 03:31 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2010-03-31 at 13:47 -0700, Yinghai Lu wrote:
>>> perhaps the second one isn't needed? Perhaps no architecture
>> requires
>>> that local interrupts be disabled across the above initialisations?
>>
>> spin_unlock_irq from arm is different from other archs?
>
> No, it's not, it will enable IRQs and thats illegal to do so early
> during boot. We've been over that one again and again, the problem is
> that people want to keep using that instead of irqsave/restore because
> it's a nano-optimisation on x86... oh well...
>

Well, guess what... the particular user in this case *isn't used at all
on x86* so it is a non-issue here. So I take it we have your particular
vote to use irqsave/irqrestore in lib/rwsem-spinlock.c?

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on
On Thu, 01 Apr 2010 09:37:51 +1100
Benjamin Herrenschmidt <benh(a)kernel.crashing.org> wrote:

> On Wed, 2010-03-31 at 14:57 -0700, H. Peter Anvin wrote:
> >
> > The question still remains what the incremental cost is of doing
> > irqsave/irqrestore.
>
> The only other option is to have local_irq_enable() check a global
> (system_state ?) before enabling. Almost as gross ...
>

Add an irq-disable-depth counter to the task_struct, fix all the bugs
which that exposes..

But these things are all utterly gross. The bottom line is that
radix_tree_init() is manifestly unsuited to being called with local
interrupts disabled. 773e3eb7b81e5ba13b5155dfb3bb75b8ce37f8f9 was just
a wrong patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Howells on
Russell King <rmk(a)arm.linux.org.uk> wrote:

> We use the standard generic kernel implementation. Is x86 different? ;)

The optimised fast paths used on x86 rwsems don't disable interrupts.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on
On Wed, 2010-03-31 at 15:49 -0700, Andrew Morton wrote:
>
> But these things are all utterly gross. The bottom line is that
> radix_tree_init() is manifestly unsuited to being called with local
> interrupts disabled. 773e3eb7b81e5ba13b5155dfb3bb75b8ce37f8f9 was
> just a wrong patch.

Except that powerpc (and now it seems x86) both want to use radix trees
for interrupt handling... At least on powerpc, we trick and use a linear
search until the radix trees are initialized, which we do later during
boot, but that somewhat sucks.

I believe sherry picking things like not calling radix_tree_init() is
going to fix one case today, until we have another one, and another one,
and etc...

I suspect we're better off fixing the root of the problem in down/up.

Cheers,
Ben.


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