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=-10.1 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,USER_AGENT_GIT autolearn=unavailable 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 A3580C31E40 for ; Tue, 6 Aug 2019 21:41:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7314B218A2 for ; Tue, 6 Aug 2019 21:41:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565127683; bh=vMeXn4r8zIRk/kbjlB9xWUci9fJf1v22wI04NOoZ6+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=NvCReFDqVnZKctms+te88L3ShkZTHZHplo+BG4KPctjMYcVbtej+QHpHEVHxoAi+9 p3GkLIEkfsadqVSHC4tS9Uv4VEhUEqBjr7oVLg0XXdtG/o/WgDwCgOEFmWbnTpX6Fs ETI1z2ghc6nSNNRkjPFNo9FNxyUj5wgwfM43ktwI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728015AbfHFVlR (ORCPT ); Tue, 6 Aug 2019 17:41:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:54100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728898AbfHFVgS (ORCPT ); Tue, 6 Aug 2019 17:36:18 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C30912187F; Tue, 6 Aug 2019 21:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565127377; bh=vMeXn4r8zIRk/kbjlB9xWUci9fJf1v22wI04NOoZ6+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s+QePJ3G06ESw8aXi3AbyVzNAALiman8kJSlLUU11pPkqeVACDTcDRcuUb299xkem SACiha8S5L1mLVsOvrjbO+ymWI3QsR7gAMYiTigI1fyUNXXsCeAgKwMYWNwpXp9mGs PQYn5Mgz7s4vjVS2JSOWmhHbI/IiSuF+jtF8nxjE= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yang Shi , Catalin Marinas , Michal Hocko , Dmitry Vyukov , David Rientjes , Matthew Wilcox , Qian Cai , Andrew Morton , Linus Torvalds , Sasha Levin , linux-mm@kvack.org Subject: [PATCH AUTOSEL 4.19 29/32] Revert "kmemleak: allow to coexist with fault injection" Date: Tue, 6 Aug 2019 17:35:17 -0400 Message-Id: <20190806213522.19859-29-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190806213522.19859-1-sashal@kernel.org> References: <20190806213522.19859-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Yang Shi [ Upstream commit df9576def004d2cd5beedc00cb6e8901427634b9 ] 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 mempool_alloc_slab+0x2d/0x40 mempool_alloc+0x118/0x2b0 bio_alloc_bioset+0x19d/0x350 get_swap_bio+0x80/0x230 __swap_writepage+0x5ff/0xb20 The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak has __GFP_NOFAIL set all the time due to d9570ee3bd1d4f2 ("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. Link: http://lkml.kernel.org/r/1563299431-111710-1-git-send-email-yang.shi@linux.alibaba.com Fixes: d9570ee3bd1d4f2 ("kmemleak: allow to coexist with fault injection") Signed-off-by: Yang Shi Suggested-by: Catalin Marinas Acked-by: Michal Hocko Cc: Dmitry Vyukov Cc: David Rientjes Cc: Matthew Wilcox Cc: Qian Cai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- mm/kmemleak.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 6c94b6865ac22..5eeabece0c178 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -126,7 +126,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 { -- 2.20.1