Re: kernel BUGs when removing largish files with the SLOB allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



IMHO the problem is nommu.c is written for slab only. So when slob is
enabled, it need to be considered to make some modification to make
two or more memory allocator algorithms work properly, rather than to
force all others algorithm to be compatible with the current one(slab)
to match the code in the nommu.c, which is not common enough.

Does that make sense?

Regards,
-Aubrey

On 9/4/06, David Howells <[email protected]> wrote:

Aubrey <[email protected]> wrote:

> Is there any solution/patch to fix the issue?

Make the SLOB allocator mark its pages PG_slab, just like the SLAB allocator
does.  I think this should be okay as the SLOB allocator and the SLAB
allocator seem to be mutually exclusive.

Using PG_slab would also give an instant check to things like SLOB's kfree().

> +#ifdef CONFIG_SLAB
>        if (PageSlab(page))
> +#endif

This is not a valid workaround as the object won't necessarily have been
allocated from a slab (shared ramfs mappings and SYSV SHM for example).  You
may not pass to ksize() objects allocated by means other than SLAB/SLOB.

David

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

[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]
  Powered by Linux