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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 8DE86C432C1 for ; Tue, 24 Sep 2019 23:06:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 551EC21655 for ; Tue, 24 Sep 2019 23:06:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569366375; bh=Ta+lNJBKZpe+dxyTHVaewQ0RnBcISpVZitUsTbFvGHc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=O8LNr6wLaCX/MhBUw1Y1z4GGjB7NKsf/XQN4cs7ZHKjcyZ8xdsqajpjE0fylIlmvM isBgsgmRonfEs109uU/VFxx3rmTFFzZ3/s9zq8Fo7mK/q3ffuKvIyngbVClgmCYA1O 9rpiYFgskVQ1D3yelLFoXz2JBhm1hwdY6Y/MfiJk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2411115AbfIXXGO (ORCPT ); Tue, 24 Sep 2019 19:06:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:47158 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389100AbfIXXGO (ORCPT ); Tue, 24 Sep 2019 19:06:14 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 77B7C2064A; Tue, 24 Sep 2019 23:06:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569366372; bh=Ta+lNJBKZpe+dxyTHVaewQ0RnBcISpVZitUsTbFvGHc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=o1VFnUdJBdfBqyZ9JxydqdcGGHX5NSyRKMf3mDIP7NFLLvCCx3fFJ30wFQrBQbJTE Pku3cXr7t0atc31Mu7sMtUNF20CQ94oOhN3z4s9/fPnAd8suuyTsn6k6GOGfr+gCJc kZ7XY34DxaJssBsAZKn78DlJwqkA6+Gjuy//xdAE= Date: Tue, 24 Sep 2019 16:06:11 -0700 From: Andrew Morton To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , LKML , linux-mm@kvack.org, Andrey Ryabinin , Thomas Lindroth , Tetsuo Handa Subject: Re: [PATCH] memcg, kmem: do not fail __GFP_NOFAIL charges Message-Id: <20190924160611.d1bbc6246a1fe025959fb913@linux-foundation.org> In-Reply-To: <20190924105355.GA28904@dhcp22.suse.cz> References: <31131c2d-a936-8bbf-e58d-a3baaa457340@gmail.com> <20190906125608.32129-1-mhocko@kernel.org> <20190924105355.GA28904@dhcp22.suse.cz> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 24 Sep 2019 12:53:55 +0200 Michal Hocko wrote: > Andrew, do you plan to send this patch to Linus as ell? I suppose so. We don't actually have any reviewed-bys or acked-bys but I expect that's because Shakeel forgot to type them in. The followup deprecation warning patch I parked for 5.4-rc1. Best to give it a spin in -next and see if anyone complains before we go bothering mainline users. From: Michal Hocko Subject: memcg, kmem: do not fail __GFP_NOFAIL charges Thomas has noticed the following NULL ptr dereference when using cgroup v1 kmem limit: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 16923 Comm: gtk-update-icon Not tainted 4.19.51 #42 Hardware name: Gigabyte Technology Co., Ltd. Z97X-Gaming G1/Z97X-Gaming G1, BIOS F9 07/31/2015 RIP: 0010:create_empty_buffers+0x24/0x100 Code: cd 0f 1f 44 00 00 0f 1f 44 00 00 41 54 49 89 d4 ba 01 00 00 00 55 53 48 89 fb e8 97 fe ff ff 48 89 c5 48 89 c2 eb 03 48 89 ca <48> 8b 4a 08 4c 09 22 48 85 c9 75 f1 48 89 6a 08 48 8b 43 18 48 8d RSP: 0018:ffff927ac1b37bf8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: fffff2d4429fd740 RCX: 0000000100097149 RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff9075a99fbe00 RBP: 0000000000000000 R08: fffff2d440949cc8 R09: 00000000000960c0 R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 R13: ffff907601f18360 R14: 0000000000002000 R15: 0000000000001000 FS: 00007fb55b288bc0(0000) GS:ffff90761f8c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000007aebc002 CR4: 00000000001606e0 Call Trace: create_page_buffers+0x4d/0x60 __block_write_begin_int+0x8e/0x5a0 ? ext4_inode_attach_jinode.part.82+0xb0/0xb0 ? jbd2__journal_start+0xd7/0x1f0 ext4_da_write_begin+0x112/0x3d0 generic_perform_write+0xf1/0x1b0 ? file_update_time+0x70/0x140 __generic_file_write_iter+0x141/0x1a0 ext4_file_write_iter+0xef/0x3b0 __vfs_write+0x17e/0x1e0 vfs_write+0xa5/0x1a0 ksys_write+0x57/0xd0 do_syscall_64+0x55/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Tetsuo then noticed that this is because the __memcg_kmem_charge_memcg fails __GFP_NOFAIL charge when the kmem limit is reached. This is a wrong behavior because nofail allocations are not allowed to fail. Normal charge path simply forces the charge even if that means to cross the limit. Kmem accounting should be doing the same. Link: http://lkml.kernel.org/r/20190906125608.32129-1-mhocko@kernel.org Signed-off-by: Michal Hocko Reported-by: Thomas Lindroth Debugged-by: Tetsuo Handa Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Andrey Ryabinin Cc: Thomas Lindroth Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton --- mm/memcontrol.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/mm/memcontrol.c~memcg-kmem-do-not-fail-__gfp_nofail-charges +++ a/mm/memcontrol.c @@ -2943,6 +2943,16 @@ int __memcg_kmem_charge_memcg(struct pag if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && !page_counter_try_charge(&memcg->kmem, nr_pages, &counter)) { + + /* + * Enforce __GFP_NOFAIL allocation because callers are not + * prepared to see failures and likely do not have any failure + * handling code. + */ + if (gfp & __GFP_NOFAIL) { + page_counter_charge(&memcg->kmem, nr_pages); + return 0; + } cancel_charge(memcg, nr_pages); return -ENOMEM; } _