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 C0A09C3DA4A for ; Mon, 19 Aug 2024 12:53:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57BBE6B0089; Mon, 19 Aug 2024 08:53:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52B856B0092; Mon, 19 Aug 2024 08:53:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41ACE6B0095; Mon, 19 Aug 2024 08:53:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 233FD6B0089 for ; Mon, 19 Aug 2024 08:53:54 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AF4561C4E51 for ; Mon, 19 Aug 2024 12:53:53 +0000 (UTC) X-FDA: 82468987146.05.327F83A Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf15.hostedemail.com (Postfix) with ESMTP id 034EDA000D for ; Mon, 19 Aug 2024 12:53:51 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724071954; 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: in-reply-to:in-reply-to:references:references; bh=Wqo8qP6djVxiuY5/xeqr0EFLuJmY20yEsnbyb/YVWLI=; b=qnHMdYPGRsqzC6kMZV5HSHoBjKDdCtx2N00gRtNWMLpVUiKqcCo2vNJyKlWBZ964g2kmLk vP25wkYSbt1VvzMRmSobucHjsW6kp0oqN2EM/67bWLQgW1/r9ozHHcPeD1yCDjvhqVXOte HPGOj72BU4YUQW2zw8sdPRWL4wux85M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724071954; a=rsa-sha256; cv=none; b=BBql05Xh5Dt/FXYAvdfHWVksV/Kh2kBhOCYQK/dVCBTky+Z/G3IJuNa2ygS2/qlR5nYWSQ fVsRTSwQBGZWWx6jaLo7+MZ1ilOFkxn+y5XKpLd6i8s4OhgjQfJbGC8xvcFFE8W/hYX5qq B43eynH/EL1rYeXjQQ2MUCfjaBYdM2I= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none Received: by verein.lst.de (Postfix, from userid 2407) id EF34D68BFE; Mon, 19 Aug 2024 14:53:46 +0200 (CEST) Date: Mon, 19 Aug 2024 14:53:46 +0200 From: Christoph Hellwig To: David Hildenbrand Cc: Christoph Hellwig , Barry Song <21cnbao@gmail.com>, 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 , Eugenio =?iso-8859-1?Q?P=E9rez?= , Jason Wang , Maxime Coquelin , "Michael S. Tsirkin" , Xuan Zhuo Subject: Re: [PATCH v3 3/4] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Message-ID: <20240819125346.GA7992@lst.de> References: <20240817062449.21164-1-21cnbao@gmail.com> <20240817062449.21164-4-21cnbao@gmail.com> <5654b71c-1d9d-4c48-b28b-664662da8897@redhat.com> <416ac265-ced2-4f90-a347-0a256edf7fdf@redhat.com> <54a4619d-e826-465e-9a0f-0a8f37798e15@redhat.com> <20240819124924.GA7642@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 034EDA000D X-Stat-Signature: tthomkr98febjzp7jbrh59w1atagc897 X-HE-Tag: 1724072031-984470 X-HE-Meta: U2FsdGVkX19EWTmGXu7OdHwVYqT+TbCYNIHApqOk/msfCyJVeef/Yb0PK4uLa0GcdUaDMarm07EtOUb80XFdDp0+bRt+3F3Q2DKxSpoFnTKEilLt4C9BhCMFEtBl64pODmKTRcmNzYIuv9T5Z2hTdTWxDl4lZ3CtFWG5Ndcj3pxVBAv1HUBQ8xMrkqJp9ojH1usNA26rrYHKePiJx8dGcZpLPXRjamrqcxrU3ILdseQEpXehQriuS9bkdBIQ77mi7K+EPYZat959bJiBnTkRyVVrXUPPxx037wZqhiZCI+a1TNtd+Ulhkh9ZWSWLCBkAaeq/dgvon8lbBRe/DkdgVRO28kCkcY19KYAuC9keAyPuW7+r3g5xd8Tlsva7RIwPChoESKqIiS69DU2kpCxJZMnMwambuGrYNE8oF12lcpwBFsO9kyQrkDvN5e7lq4Ilpabw54+EHsKddhxpfb9wK6oskNf9UZxa3qFVnagTaLC/ITp14hKc6/0MWKyyTYEL7XpDl30ipVjYm31NnZvQ/kwLt7+yYzvLOR5k6tEc9mokn19DB7i0ubPMR0bbJ3FPEc9td4DvZJAoBl72eMz/JQCOhL9dAZt59302a8RH08D8mXIDVuBShe346jOLS0NVGbWpf3uzKzdAYtHS8AbUsB/Ad+cWBolzEWiYcCtJRb+d+h8jOiQirOrANYiAk0qBvoN2AUileqTwVEr9kYMnl+FkDsJ4e35VfLpIwqqaFqxeqTORj+YqP5t+NVeY7lqoxiWAlBXOUzcHc/uqzmVeBI3ca1ItbOHXmuIKOb67UQX/rf7hDvpQRh2OLaL3yA0jpCE5kd1RgrZflWWM5XUcirnHSeFX6/K7F2VHWyAXP85VMF8ZXNCmSIfsLu80PXeeUvbtAhPO/G1eABUnmvrVX+tceyOsFKLKkUdg0NVsMc6IOJxvBVE2n7kLRr5nhB3vk69tAxq1FPuy4d6M+Mh ls+fIMp/ AnR2qYweCxEsNlB4w8DfqlzNau43ycx15KIZ/Jwc+CgZM83gvvT8hYQpzJQLD6yZJy5/FADiig0L0DbCISL+Kuvr1fHH0JHgGOxGPsQqsz99A/T2Kkp6vYs1d1lp+YzBpEscIgrk2nGSwIP6WVdqfwYGtJDpWUvpX6vQz4iIdrZjokulNlaz6uLeCvkp/vVqdDY4U 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 Mon, Aug 19, 2024 at 02:51:06PM +0200, David Hildenbrand wrote: > On 19.08.24 14:49, Christoph Hellwig wrote: >> On Mon, Aug 19, 2024 at 02:33:06PM +0200, David Hildenbrand wrote: >>> It should all be caught during testing either way. And if some OOT module >>> does something nasty, that's not our responsibility. >>> >>> BUG_ON is not a way to write assertions into the code. >> >> So you'd rather create exploits than crashing on a fundamental API >> violation? That's exactly what the series is trying to fix. > > I'd rather have a sane API that doesn't even allow this level of > flexibility with NOFAIL. > > But probably I'm missing more details here why this all has to be so > complicated ;) Well, the only way to do that is to remove (__)GFP_NOFAIL and require either explicit _nofail variants without a way to pass gfp flags, or endless loops in the callers. I suggested the first one earlier, but no one liked it due to the API complexity and overhead. And I've not heard anyone arguing for the latter yet. One other way might be a compile time check that requires any GPF flag that contains (__)GFP_NOFAIL to be a compile time constants. This is true for many but not all callers currently.