On Tue 04-04-17 14:58:06, Cristopher Lameter wrote: > On Tue, 4 Apr 2017, Michal Hocko wrote: > > > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote: > > > On Tue, 4 Apr 2017, Michal Hocko wrote: > > > > > > > Yes, but we do not have to blow the kernel, right? Why cannot we simply > > > > leak that memory? > > > > > > Because it is a serious bug to attempt to free a non slab object using > > > slab operations. This is often the result of memory corruption, coding > > > errs etc. The system needs to stop right there. > > > > Why when an alternative is a memory leak? > > Because the slab allocators fail also in case you free an object multiple > times etc etc. Continuation is supported by enabling a special resiliency > feature via the kernel command line. The alternative is selectable but not > the default. I disagree! We should try to continue as long as we _know_ that the internal state of the allocator is still consistent and a further operation will not spread the corruption even more. This is clearly not the case for an invalid pointer to kfree. I can see why checking for an early allocator corruption is not always feasible and you can only detect after-the-fact but this is not the case here and putting your system down just because some buggy code is trying to free something it hasn't allocated is not really useful. I completely agree with Linus that we overuse BUG way too much and this is just another example of it. -- Michal Hocko SUSE Labs -- 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>
