Messages in this thread | | | Subject | Re: [PATCH] mm: page_alloc: document kmemleak's non-blockable __GFP_NOFAIL case | From | Yang Shi <> | Date | Mon, 15 Jul 2019 09:58:14 -0700 |
| |
On 7/15/19 8:18 AM, Qian Cai wrote: > On Mon, 2019-07-15 at 10:01 -0500, Catalin Marinas wrote: >> On 15 Jul 2019, at 08:17, Michal Hocko <mhocko@kernel.org> wrote: >>> On Sat 13-07-19 04:49:04, Yang Shi wrote: >>>> When running ltp's oom test with kmemleak enabled, the below warning was >>>> triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is >>>> passed in: >>> kmemleak is broken and this is a long term issue. I thought that >>> Catalin had something to address this. >> What needs to be done in the short term is revert commit >> d9570ee3bd1d4f20ce63485f5ef05663866fe6c0. Longer term the solution is to embed >> kmemleak metadata into the slab so that we don’t have the situation where the >> primary slab allocation success but the kmemleak metadata fails. >> >> I’m on holiday for one more week with just a phone to reply from but feel free >> to revert the above commit. I’ll follow up with a better solution. > Well, the reverting will only make the situation worst for the kmemleak under > memory pressure. In the meantime, if someone wants to push for the mempool
I think this is expected by reverting that commit since kmemleak metadata could fail. But, it could fail too even though that commit is not reverted if the context is non-blockable.
> solution with tunable pool sizes along with the reverting, that could be an > improvement. > > https://lore.kernel.org/linux-mm/20190328145917.GC10283@arrakis.emea.arm.com/
| |