----- Original Message ----- > From: "Tetsuo Handa" <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > To: mhocko@xxxxxxxx > Cc: malat@xxxxxxxxxx, dvyukov@xxxxxxxxxx, linux-mm@xxxxxxxxx, "catalin marinas" <catalin.marinas@xxxxxxx>, > chuhu@xxxxxxxxxx > Sent: Tuesday, May 29, 2018 5:05:45 AM > Subject: Re: [PATCH] kmemleak: don't use __GFP_NOFAIL > > Michal Hocko wrote: > > I've found the previous report [1] finally. Adding Chunyu Hu to the CC > > list. The report which triggered this one is [2] > > > > [1] > > http://lkml.kernel.org/r/1524243513-29118-1-git-send-email-chuhu@xxxxxxxxxx > > [2] > > http://lkml.kernel.org/r/CA+7wUswp_Sr=hHqi1bwRZ3FE2wY5ozZWZ8Z1BgrFnSAmijUKjA@xxxxxxxxxxxxxx > > > > I am not really familiar with the kmemleak code but the expectation that > > you can make a forward progress in an unknown allocation context seems > > broken to me. Why kmemleak cannot pre-allocate a pool of object_cache > > and refill it from a reasonably strong contexts (e.g. in a sleepable > > context)? > > Or, we can undo the original allocation if the kmemleak allocation failed? If so, you are making kmemleak a fault injection trigger. But the original purpose for adding GFP_NOFAIL[2] is just for making kmemleak avoid fault injection. (discussion in [1]) I'm trying with per task way for fault injection, and did some tries. In my try, I removed this from NOFAIL kmemleak and kmemleak survived with the per task fault injection helper (disable/enable of task). Maybe I can send another RFC for the api. > > kmalloc(size, gfp) { > ptr = do_kmalloc(size, gfp); > if (ptr) { > object = do_kmalloc(size, gfp_kmemleak_mask(gfp)); > if (!object) { > kfree(ptr); > return NULL; > } > // Store information of ptr into object. > } > return ptr; > } > -- Regards, Chunyu Hu
