From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 495CEC76186 for ; Wed, 17 Jul 2019 05:07:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1B77C2173E for ; Wed, 17 Jul 2019 05:07:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563340035; bh=j9J9T3sw3SK8J3EgLlkEAcafmoedig5qXZS7A2od+ww=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=xVVqFXgsV0NQL5t2zOO79acxyIPbGDXXgwbRSmr4wX1Hjz9zRIB5MGuNYM5lSr+cq V/tGfyFXDuNP3OjoNbUGxq2pP8DK0M1AE02zrD4yZhmSfoK0Pb7XPNt/z9jytoXucW IYyIWlskTRnRlILINCX8k5QsvMoz5c288LflkFk8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726748AbfGQFHN (ORCPT ); Wed, 17 Jul 2019 01:07:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:53510 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725799AbfGQFHN (ORCPT ); Wed, 17 Jul 2019 01:07:13 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 31D91ABCD; Wed, 17 Jul 2019 05:07:12 +0000 (UTC) Date: Wed, 17 Jul 2019 07:07:11 +0200 From: Michal Hocko To: Yang Shi Cc: catalin.marinas@arm.com, dvyukov@google.com, rientjes@google.com, willy@infradead.org, cai@lca.pw, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Revert "kmemleak: allow to coexist with fault injection" Message-ID: <20190717050711.GA16284@dhcp22.suse.cz> References: <1563299431-111710-1-git-send-email-yang.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1563299431-111710-1-git-send-email-yang.shi@linux.alibaba.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 17-07-19 01:50:31, 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: > > WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 __alloc_pages_nodemask+0x1c31/0x1d50 > Modules linked in: loop dax_pmem dax_pmem_core ip_tables x_tables xfs virtio_net net_failover virtio_blk failover ata_generic virtio_pci virtio_ring virtio libata > CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 > RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50 > ... > kmemleak_alloc+0x4e/0xb0 > kmem_cache_alloc+0x2a7/0x3e0 > ? __kmalloc+0x1d6/0x470 > ? ___might_sleep+0x9c/0x170 > ? mempool_alloc+0x2b0/0x2b0 > mempool_alloc_slab+0x2d/0x40 > mempool_alloc+0x118/0x2b0 > ? __kasan_check_read+0x11/0x20 > ? mempool_resize+0x390/0x390 > ? lock_downgrade+0x3c0/0x3c0 > bio_alloc_bioset+0x19d/0x350 > ? __swap_duplicate+0x161/0x240 > ? bvec_alloc+0x1b0/0x1b0 > ? do_raw_spin_unlock+0xa8/0x140 > ? _raw_spin_unlock+0x27/0x40 > get_swap_bio+0x80/0x230 > ? __x64_sys_madvise+0x50/0x50 > ? end_swap_bio_read+0x310/0x310 > ? __kasan_check_read+0x11/0x20 > ? check_chain_key+0x24e/0x300 > ? bdev_write_page+0x55/0x130 > __swap_writepage+0x5ff/0xb20 > > The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak has > __GFP_NOFAIL set all the time due to commit > d9570ee3bd1d4f20ce63485f5ef05663866fe6c0 ("kmemleak: allow to coexist > with fault injection"). But, it doesn't make any sense to have > __GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM specified at the same time. > > According to the discussion on the mailing list, the commit should be > reverted for short term solution. Catalin Marinas would follow up with a better > solution for longer term. > > The failure rate of kmemleak metadata allocation may increase in some > circumstances, but this should be expected side effect. > > Suggested-by: Catalin Marinas > Cc: Michal Hocko > Cc: Dmitry Vyukov > Cc: David Rientjes > Cc: Matthew Wilcox > Cc: Qian Cai > Signed-off-by: Yang Shi I forgot Acked-by: Michal Hocko > --- > mm/kmemleak.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 9dd581d..884a5e3 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -114,7 +114,7 @@ > /* GFP bitmask for kmemleak internal allocations */ > #define gfp_kmemleak_mask(gfp) (((gfp) & (GFP_KERNEL | GFP_ATOMIC)) | \ > __GFP_NORETRY | __GFP_NOMEMALLOC | \ > - __GFP_NOWARN | __GFP_NOFAIL) > + __GFP_NOWARN) > > /* scanning area inside a memory block */ > struct kmemleak_scan_area { > -- > 1.8.3.1 -- Michal Hocko SUSE Labs