[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <19f34abd0808251244v439e78b1hbb24f77c637559c3@mail.gmail.com>
Date: Mon, 25 Aug 2008 21:44:09 +0200
From: "Vegard Nossum" <vegard.nossum@...il.com>
To: "Daniel J Blueman" <daniel.blueman@...il.com>
Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Ingo Molnar" <mingo@...e.hu>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Adrian Bunk" <bunk@...nel.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Natalie Protasevich" <protasnb@...il.com>,
"Kernel Testers List" <kernel-testers@...r.kernel.org>
Subject: SLUB/debugobjects locking (Re: 2.6.27-rc4-git1: Reported regressions from 2.6.26)
On Mon, Aug 25, 2008 at 3:03 PM, Daniel J Blueman
<daniel.blueman@...il.com> wrote:
> Hi Linus, Vegard,
>
> On Sun, Aug 24, 2008 at 7:58 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> On Sun, 24 Aug 2008, Vegard Nossum wrote:
> [snip]
>> Anyway, I think your patch is likely fine, I just thought it looked a bit
>> odd to have a loop to move a list from one head pointer to another.
>>
>> But regardless, it would need some testing. Daniel?
>
> This opens another lockdep report at boot-time [1] - promoting
> pool_lock may not be the best fix?
>
> We then see a new deadlock condition (on the pool_lock spinlock) [2],
> which seemingly was avoided by taking the debug-bucket lock first.
>
> We reproduce this by booting with debug_objects=1 and causing a lot of activity.
Thanks. I get the same thing here as well.
I tried your suggestion of promoting the lock to irq-safe, and it
fixed the warning for me (didn't get or look for deadlocks yet, but it
seems likely that it is caused by the same thing?), the patch is
attached for reference.
I also don't know if this is the best fix, but I also don't have any
other (better) suggestions.
Others are welcome to pick it up from here...
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
Download attachment "promoted.patch" of type "application/octet-stream" (1577 bytes)
Powered by blists - more mailing lists