lkml.org 
[lkml]   [2008]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.27-rc4-git1: Reported regressions from 2.6.26
On Sun, Aug 24, 2008 at 8:03 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Sat, 23 Aug 2008, Rafael J. Wysocki wrote:
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11410
>> Subject : SLUB list_lock vs obj_hash.lock...
>> Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
>> Date : 2008-08-22 21:48 (2 days old)
>> References : http://marc.info/?l=linux-kernel&m=121944176609042&w=4
>
> This one now has a suggested patch for Daniel to try from Vegard, but no
> reply yet:
>
> http://marc.info/?l=linux-kernel&m=121946972307110&w=4
>

Hi!

> Vegard, I think your patch is a bit odd, though. The result of your patch
> is
>
> - first loop:
>
> hlist_for_each_entry_safe(obj, node, tmp, &db->list, node) {
> hlist_del(&obj->node);
> hlist_add_head(&obj->node, &freelist);
> }
>
> and quite frankly, I don't see what the difference between that and a
> something like a simple
>
> struct hlist_node *first = bd->list.first;
> if (first) {
> bd->list.first = NULL;
> first->pprev = &first;
> }
>
> really is?
>
> I dunno. We don't have list splicing ops for the hlist things.

Hm.

I haven't really used the hlists before, so my first instinct was to
do what is obvious. That's also why I put the XXX comment. Other than
that, I guess open-coding list ops is also not very good programming
practice? :-)

But... feel free to submit your own patch. Oh, what am I saying.


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


\
 
 \ /
  Last update: 2008-08-24 20:47    [W:0.346 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site