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;
}
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
