On 03.01.20 15:49, Christopher Lameter wrote: > On Fri, 3 Jan 2020, Qian Cai wrote: > >>> On Jan 3, 2020, at 6:17 AM, lijiazi <jqqlijiazi@xxxxxxxxx> wrote: >>> >>> If current object's memory is corrupted, there is a high >>> probability that next_objext stored in it will be rewritten as an >>> illegal value. It's better to check next_object this time than to >>> encounter a illegal pointer in next slub alloc like the following: >> >> Rather than papering over the issue, the key to figure out is how was the current object memory corrupted? > > Yes and this is a performance critical path. Keep expensive operations out > and enable them only if debugging is enabled. > VM_BUG_ON(!virt_addr_valid(next_object)); But I agree that this might be misplaces, because we certainly don't want to add random memory corruption checks in many call paths. -- Thanks, David / dhildenb
