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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2CB5C531DC for ; Sun, 18 Aug 2024 02:55:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AEB58D00D7; Sat, 17 Aug 2024 22:55:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55D6F8D00CF; Sat, 17 Aug 2024 22:55:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 424DE8D00D7; Sat, 17 Aug 2024 22:55:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 237BE8D00CF for ; Sat, 17 Aug 2024 22:55:50 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 999FEA09B7 for ; Sun, 18 Aug 2024 02:55:49 +0000 (UTC) X-FDA: 82463851218.12.7CB1CC3 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by imf28.hostedemail.com (Postfix) with ESMTP id DC11CC0009 for ; Sun, 18 Aug 2024 02:55:47 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bWKkRonx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.181 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723949686; a=rsa-sha256; cv=none; b=Dkfw2RmdahG6rzvDGeSYAhG8i+87DeU6iEiMuJheN+n4JwFRZ7X6QlrWiNp2MIsGP+EEFM LJE1JvkJ27fik0jzIlqZncOt+GmMEt7+UxV+SnG/e/dkhBp5q1tIA9P/7u7tw6baduI4KW BnnQ4Ch9Xv9mAGCvnEk+ZDmo5XyeL2I= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bWKkRonx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.181 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723949686; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=l7FAjbIWmnnLeDsFAqPZWRKJ78oaIxOyyfrjrwD/sSk=; b=vkFY7GG1ALQnhZosD4tZGOzWIgHRJ4xyMUVL/U/KVOfJvxsdz2OpRNq+AfjqfffFv+kD3J PX9Wq8zQJ9h0ELyHNL9sH+LytJTRasuiVESG3YDbwkU393zlBGzh58QlNqPo09jaNfbCRI M42w9tpcpZhmD2AKZ86yKsTdgRFNSTI= Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-7a1e1f6a924so221937285a.1 for ; Sat, 17 Aug 2024 19:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723949747; x=1724554547; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l7FAjbIWmnnLeDsFAqPZWRKJ78oaIxOyyfrjrwD/sSk=; b=bWKkRonxdInOz53rMFmKJ+FO4e74IOBvnyncH9tqrIey4Z7U+q0PM07lnYn9joDjMi vtZCavQgTx2Yd91e1d1J9g70kXH7N3TVpJhIBvZfedxipiuQBprvsPUgnrt/5NVmBfl/ CCKtyqWTuNZPg0uU5WmXfRWfJayoWrvE5Q6yFEmzRCa+S/jRYMkgVwv+gUiHmnOVjrKD I8SyziCBArQP/QA3iMSbzEbDKdKQf8M0B0Ev0qMcsef3tWmCGImwM0vbQdhhmreQtoz+ 8R0FOcSG0+4k2mZeKmXtifNZuUbYKsNrUGsHoKwcw0EUpY35U1NVKK0cgCSD3Iu8SitR zTnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723949747; x=1724554547; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l7FAjbIWmnnLeDsFAqPZWRKJ78oaIxOyyfrjrwD/sSk=; b=g0TYmgzR0NNnKfrRYE/0fMGWR3WDm01vLH6w4C2NuFb9IuzbdW1Eb4a0my2jt3tjWU VN5HJ9HRnM1YxoA2LeYwLSF/w3Nh5GC2e17+p4bJhklR9hwjGOSqJH0Vf48aUFGhI/Im 7WKourR3KLPkjMK6PYNhsOrPydzKTyu8ha+mpFckIzL9xd6W0p8Wx7C/AvLFx/Zrfvmk hsv/krqRkzE+7K/I1pLjH9mz3J1c4dNOIVx0AnRwt9lKyExH4qlXUFPvGVlZhmUjoOCd PtKB4NFGVjfB8Bd6sVy/U73el6Bsx2ZWnEtOtr9fpAK1kuq9e6v2tSQYSGODPptfctKx Dh+A== X-Forwarded-Encrypted: i=1; AJvYcCWhSH1hfxD+eqkv0IaPvZaO5mZb10sMP33rnkj93XkwDm2fafUfB+fcNptlT8dWsoKyOdeXLPHuz42d1clVbup6Ajs= X-Gm-Message-State: AOJu0YzgXF7Kf8FnQ4TLc7Z5jDYAwQWIlYSIfT7IdJ2vTNNAPr68PnlX GqfZGw7w72HLl9fXu+eAmxXLGhui/KlCxvrI8VrrHeTJO93kUqlG2IPbomZTGQs8vEuZ95NAxm0 KnEpbvFX8OREhXzjheNC1Cf6jI5U= X-Google-Smtp-Source: AGHT+IHBV9d7TSGH0cnvkTXDtJjFYApR7PLg6RaABxXprpAuWiVpZgsyN4ru2X2D9leocVXnLWZT15KMZXOAK4RMGeU= X-Received: by 2002:a05:6214:33c5:b0:6bf:8afa:6162 with SMTP id 6a1803df08f44-6bf8afa63c1mr43804546d6.46.1723949746777; Sat, 17 Aug 2024 19:55:46 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <20240817062449.21164-5-21cnbao@gmail.com> In-Reply-To: <20240817062449.21164-5-21cnbao@gmail.com> From: Yafang Shao Date: Sun, 18 Aug 2024 10:55:09 +0800 Message-ID: Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, mhocko@suse.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev, Lorenzo Stoakes , Kees Cook , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , Jason Wang , Maxime Coquelin , "Michael S. Tsirkin" , Xuan Zhuo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DC11CC0009 X-Stat-Signature: y8jqcccoyyaqbg97a9npdxymjpf9qtej X-Rspam-User: X-HE-Tag: 1723949747-978839 X-HE-Meta: U2FsdGVkX1//qdUIO1fe8cX/8fbLCfzHmfZ/s534FO2FEM1bXX4WHJzVvYJ+PkukCpyFcYDDC69mOGfD5KKKnzHi+K/npCTYz0YN3BN11NVqAXvPHGVQE4aKkTQlEQ5K0T6RXl/ED4P01NxowP9jc9j5AwWIUNjcH/GEXcCv8c0IebHFwTvn//ZTw+5x/qjCHolsclQuhs1/E2BYyFUAKo5tCXxqeBYP8Yv4WRwu40nw0eyhy38wL1fBdSlv0Dv1iNK13mUODGivoHnbrCYPr92RiVCzrd1FUfehcmDIfhTFZQsya0S+2QPCk7UPQu4AhbGwQkGQSvYTk8ASd+jn2Mt3X9pnrG6OLb3lpJuqHbXW5nqBdIldtp0SYNT1d/hhstbmuVSKBtyyqxxATcCPKhP2AU7pWxDzIOf70dd0g50dH8OZMQjTGxs3HJ7I4rFIs/1K29DOzagt2jZixxNqJqSUCX7o6KKoBouJ8Va1cVn/HUsqF6zYqHkHsr0gHNJdgYJIM8qbiKw4V+L84AZ6nX5cJraDzDGMTeTWFc8pQ20AYKoQZgsgiBvYA9TM+SyEwF4TTjKMZKUi5MjxoR/HrBFKu93KL2teC+mzpOjYLaNiBNHp4YLVAdU93Ih5GFhxJ2i+PeH36AuddHryFbQQinxElcb1WB+b+M1c6ik6fZYezeTwBV680/Xn5tJoYFRzYyDRXPCIfyQBTTNRGNnWcjVsZPyTn+W1x1kWzkUVUfjRSsueYaEHybAZ6DqoxhJdeu9fUkAQc7AnXsVoSABPENbqPSRhzq69bN0lQOSi3fZoD+SQA7Pl1V+NiSGxApOGD74sV81VMpvWjY9QnVxUxObf4YnJS2CmjGytqomuSD2KCw18D2N3qBk+fEqOiKn8tO5rxgwULVRi172wcG0gptqRyVPBckxm8prpuE3oYMxlQEtViTSKkQyA3VJ9qAtDz2s0otDmVYaICZQKp++ yxVT1uA3 BJbJKIo9mb6TQh4g4aafB0SgwNTfL8LBIFi2EdE4lEJONjDFm0J+WLGI++yZNjJKeFwOOEimDAKOpxReVQwRTkY20xrSYudMvSkbNxv1FiYBzB+zG9krvCn3da7yqhTuZnmSLSUGQonq+PQwON457yLSlPN5t9Su2itoi6I3wgRR9FbZQQAZ8mg2YXcCyOak3P6d8mNn9H4JI6h6K9ZX3mKQWPApOeYoH2+uUV2QjvQZe4Z3BXu420c7p3oAJ5siKf/C09UKZd8hlFSpv7wgkcV28jaURiRXDXPr8WMHddT3lIPfEnuX3jwsmgyAO7oMUYT8htBL3ad7RfqaE5xkM7n/ON61MhB0BfW9aZ7hzq8bMZ+3uEi4PA7F4jDyXkk9ZUMKKepF2zpJnTrxzoXokNNSxddPbxhWGihLScFfPIyBvzQEL7rzvApL5l5PAoT2p0sTWrHJTnbcnSwMDpsR7RxMEJhqGKwnxEW7bOukSluvTbv0PDVqtIEMuRp3xS+lgBxoYbweGC8MsWl8h/+mmW/HyDJJisBIbzEHO1yPCBViYCAgZ9L1TUQAcYqNK7fYKIBTDc0yUXnn+jV4+pUUQw3evgzppCebRk3mxKTwhb8Ux9puhLmKuTz4DJDMagWpvW3sOGrIicHEZJaRLLMhq24aphhR/amemh1eWSyI5dHFKyangbUWBaRNknQ2O15cccHDgbBSPjVOhucFAZax+EWLFLn9HQWspaKk7FQg2z7SgMv6Qx+uwJ1xVqCfnmeBdDa/olEDnk4W2BWqyp6DGADt9D10Qav4TL+WeQLf3soTSJeRA/pCt9f64nhfQKT7+u2aR773TiUkqg76WCNxNfA/69i8FSOnIwHZV+EM6V9Zjmq2b/jrOejQyWLz3Yetb+rBYJkGq2f2xvhRUsU/b2efw8JDPiOzJKtm2IDqNBuwHJrvgK9FsnxUsnCwKqjbZVjRIX9X+moDTgnawgNCqqx95K7SM kQ/O3WUC X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, Aug 17, 2024 at 2:25=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > From: Barry Song > > When users allocate memory with the __GFP_NOFAIL flag, they might > incorrectly use it alongside GFP_ATOMIC, GFP_NOWAIT, etc. This kind of > non-blockable __GFP_NOFAIL is not supported and is pointless. If we > attempt and still fail to allocate memory for these users, we have two > choices: > > 1. We could busy-loop and hope that some other direct reclamation or > kswapd rescues the current process. However, this is unreliable > and could ultimately lead to hard or soft lockups, That can occur even if we set both __GFP_NOFAIL and __GFP_DIRECT_RECLAIM, right? So, I don't believe the issue is related to setting __GFP_DIRECT_RECLAIM; rather, it stems from the flawed design of __GFP_NOFAIL itself. > which might not > be well supported by some architectures. > > 2. We could use BUG_ON to trigger a reliable system crash, avoiding > exposing NULL dereference. > > Neither option is ideal, but both are improvements over the existing code= . > This patch selects the second option because, with the introduction of > scoped API and GFP_NOFAIL=E2=80=94capable of enforcing direct reclamation= for > nofail users(which is in my plan), non-blockable nofail allocations will > no longer be possible. > > Signed-off-by: Barry Song > Cc: Michal Hocko > Cc: Uladzislau Rezki (Sony) > Cc: Christoph Hellwig > Cc: Lorenzo Stoakes > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Vlastimil Babka > Cc: Roman Gushchin > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Cc: Linus Torvalds > Cc: Kees Cook > Cc: "Eugenio P=C3=A9rez" > Cc: Hailong.Liu > Cc: Jason Wang > Cc: Maxime Coquelin > Cc: "Michael S. Tsirkin" > Cc: Xuan Zhuo > --- > mm/page_alloc.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index d2c37f8f8d09..fb5850ecd3ae 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4399,11 +4399,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned i= nt order, > */ > if (gfp_mask & __GFP_NOFAIL) { > /* > - * All existing users of the __GFP_NOFAIL are blockable, = so warn > - * of any new users that actually require GFP_NOWAIT > + * All existing users of the __GFP_NOFAIL are blockable > + * otherwise we introduce a busy loop with inside the pag= e > + * allocator from non-sleepable contexts > */ > - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > - goto fail; > + BUG_ON(!can_direct_reclaim); I'm not in favor of using BUG_ON() here, as many call sites already handle the return value of __GFP_NOFAIL. If we believe BUG_ON() is necessary, why not place it at the beginning of __alloc_pages_slowpath() instead of after numerous operations, which could potentially obscure the issue? > > /* > * PF_MEMALLOC request from this context is rather bizarr= e > @@ -4434,7 +4434,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int= order, > cond_resched(); > goto retry; > } > -fail: > + > warn_alloc(gfp_mask, ac->nodemask, > "page allocation failure: order:%u", order); > got_pg: > -- > 2.39.3 (Apple Git-146) > > -- Regards Yafang