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.
Attachment:
pgptnGtjOs0af.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
