Hello Christopher and Kees, Excuse me for the delayed reply. On 28.07.2017 02:53, Christopher Lameter wrote: > On Fri, 28 Jul 2017, Alexander Popov wrote: > >> I don't really like ignoring double-free. I think, that: >> - it will hide dangerous bugs in the kernel, >> - it can make some kernel exploits more stable. >> I would rather add BUG_ON to set_freepointer() behind SLAB_FREELIST_HARDENED. Is >> it fine? > > I think Kees already added some logging output. Hm, I don't see anything like that in v4 of "SLUB free list pointer obfuscation": https://patchwork.kernel.org/patch/9864165/ >> At the same time avoiding the consequences of some double-free errors is better >> than not doing that. It may be considered as kernel "self-healing", I don't >> know. I can prepare a second patch for do_slab_free(), as you described. Would >> you like it? > > The SLUB allocator is already self healing if you enable the option to do > so on bootup (covers more than just the double free case). What you > propose here is no different than that and just another way of having > similar functionality. In the best case it would work the same way. Ok, I see. Thanks. Best regards, Alexander -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
