Possible Bug

[Valdis.Kletnieks at vt.edu]

On Thu, 31 Mar 2016 15:46:51 -0230, Roger H Newell said:

> I had a look inside the .config I used to compile this kernel.
> I think I found the information you're looking for.
>
> # CONFIG_KASAN is not set
> # CONFIG_SLAB is not set
> CONFIG_SLUB=y
> # CONFIG_SLOB is not set

Well, that cuts down on the amount of code that needs to be stared at.

I don't suppose we get extra-ordinarily lucky and the system was set up to
do crash dumps, was it?

I've spent a few more minutes looking at the relevant code, and the more I
stare at it, the more I understand why we see the same stack trace in varied
forums going back over a year - it looks like it only craps out if something
during resume or hotplug or similar processing stomps on memory, and the next
call to apparmor_file_alloc_security() has to allocate a new slab.

Or more correctly, it only dies with *this* traceback under those conditions.
If something else is next up to allocate a slab, it gets a different traceback.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160331/eb62ce61/attachment.bin