On Thursday 15 November 2007 21:43, Ingo Molnar wrote: > * David Miller <[EMAIL PROTECTED]> wrote: > > From: Matt Mackall <[EMAIL PROTECTED]> > > Date: Wed, 14 Nov 2007 17:37:13 -0600 > > > > > No, the usual strategy for debugging problems -outside- SLOB is to > > > switch to another allocator with more extensive debugging facilities. > > > > Ok, so the thing we still can do is do a dump_stack() at the list > > debugging assertion trigger points. > > ok, i'll first try to trigger it again.
I had implemented SLOB in userspace, so I resynched and think I found your problem. Sorry for the attachment format -- this mailer isn't the best. I'm really computer illiterate when it comes to userspace... Anyway, I'm really happy to see you're testing and using SLOB upstream :) Is there any particular reason that you're using it? Thanks, Nick
Previously, it would be possible for prev->next to point to &free_slob_pages, and thus we would try to move a list onto itself, and bad things would happen. It seems a bit hairy to be doing list operations with the list marker as an entry, rather than a head, but... Signed-off-by: Nick Piggin <[EMAIL PROTECTED]> --- Index: linux-2.6/mm/slob.c =================================================================== --- linux-2.6.orig/mm/slob.c +++ linux-2.6/mm/slob.c @@ -321,7 +321,8 @@ static void *slob_alloc(size_t size, gfp /* Improve fragment distribution and reduce our average * search time by starting our next search here. (see * Knuth vol 1, sec 2.5, pg 449) */ - if (free_slob_pages.next != prev->next) + if (prev != free_slob_pages.prev && + free_slob_pages.next != prev->next) list_move_tail(&free_slob_pages, prev->next); break; }
