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 2412CC54E58 for ; Wed, 20 Mar 2024 18:55:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C9936B0088; Wed, 20 Mar 2024 14:55:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6793A6B008A; Wed, 20 Mar 2024 14:55:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51A176B008C; Wed, 20 Mar 2024 14:55:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 42AA76B0088 for ; Wed, 20 Mar 2024 14:55:47 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E31331412CA for ; Wed, 20 Mar 2024 18:55:46 +0000 (UTC) X-FDA: 81918321492.16.F7466CF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id BD46C12001A for ; Wed, 20 Mar 2024 18:55:43 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PDnCBuEZ; dmarc=none; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710960945; 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:dkim-signature; bh=3PmEI0D9WC6qbWjMQFdByNKzMVLkjA1cfp8fJnMIdSU=; b=59MBFuhqKbjLDw9Yi/QPaxAjZdiBWPLsPO12w3oTa2K2Cc2fhyUItyJdOOOzK/z5lVP3Nv 2pUpEm6e3PINBtVUOVT1KpFsJYMt5O25uZqPuJ5vKm+dyWjcQUXHln9lxZmcNTgyoty5dF AqBneeCcoMX5p+XOvngV8T3MDDIdK+w= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PDnCBuEZ; dmarc=none; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710960945; a=rsa-sha256; cv=none; b=BOJdWDhIsD5emG+XqfWgPWwvBr3fGXoGOhCTeuYlM5nHc0WFQPZPsCAirLluzDY9jLQG73 XYAV5ZrigVSahkOhWBQcDYSyRu7Um/vaTEKtj2kOH3CuMJnvPIPmuoYlmo2xaL99cCdKZf z7PNua+fsMD1mpNCBjc5lVXPHMBNCsc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=3PmEI0D9WC6qbWjMQFdByNKzMVLkjA1cfp8fJnMIdSU=; b=PDnCBuEZfLfrEv+/kKxhyViKtW QaQIvr77L/TQkHjj68hUuIPYk0KmOm4JlZ+WLF+zyuEpW7HmzAKjQGqQUPcNqv0D+YzLQOQV4VASO pzDogHHxWuLmgcZPuO/9OxabRb1ADXQpIeh16wAmcCeZ3G1ZRjsw94u3ZRT4YZPq1z1DfHXeWFDp8 TUCSXpUJ/rroG/xU3vYX9jNSV/2rqfNGZjYE6EZyaw5L2Xvm0hhhMKsYZA5BiO+KF6FrNEe2glgp/ 6JSoZLmdnHAPvmFKMoB7g9sbz1TTfZBpUt85TCoNHs1IKnXlDLYz4q58g+S44SnhtmbWWYNlyNQAN Rr21zTBw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rn168-00000004uuD-1AMI; Wed, 20 Mar 2024 18:55:36 +0000 Date: Wed, 20 Mar 2024 18:55:36 +0000 From: Matthew Wilcox To: Vlastimil Babka Cc: Dan Carpenter , NeilBrown , Kent Overstreet , Dave Chinner , Amir Goldstein , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , Jan Kara Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU Message-ID: References: <170925937840.24797.2167230750547152404@noble.neil.brown.name> <170933687972.24797.18406852925615624495@noble.neil.brown.name> <170950594802.24797.17587526251920021411@noble.neil.brown.name> <73533d54-2b92-4794-818e-753aaea887f9@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73533d54-2b92-4794-818e-753aaea887f9@suse.cz> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: BD46C12001A X-Stat-Signature: zd9bpy5a95b7fkyjjdhghq5745drmyg9 X-HE-Tag: 1710960943-419950 X-HE-Meta: U2FsdGVkX1+GMMxH0CKZxsUzrW8VQWmIOKt5PBpncNxUHjhIiX0cYu40jz938vBXvexoOCmtyaavwQhcOghWW+vzGch3p56CpeDMFzCFcc3+3GToMb2qsQlVNgMtSckLgxJQyUmc5lei8Nxxf7UFZ/Fi0nGTpQIgBl3zbCw6MQmVZPeAi0QGg/VkuXN/POdxLWi9DNdSMY9J7paeNXwIsyWlsuOkcah5HsUI8hE7CSFkUy4/KjnDXhNRxDiI3B3z/jug3uAMHIj2+6T26yNrpR3dZx2/otCLVJgHnuqIQNzPX2tGPiMksQd7xxdWJvC5IY8+NSk+di2OLJ6yB/zAjhhwgRqvRgnXu9wzRC14tZj+QGDC74/yCCF9dCx9q8QTGBiRPKoWrrQljIxEMwR9ceYTqatE6OEQgyRASJAWvGsio5JvEKqyMw+HEBy0EiHJ9d7I8rsb3C6Q9pOJDQGJIxzgrKH9X+H9bw63ltCIm0HOFbPby7vFqxZhOc4/TwilHKnErkYxxGvijPHQkgb5b7ok5+D7QhBdwMC5d3ihyhB4hGU1snUj8L/9IGKCm8E6sWWkpj8TBX7UvpWY9CsES2X5J7ukU+F45aGH/At9CZvmmEFRbutctFdZjwQE7AUeyKwQbf2Or4ywi5FrOeOzP3bqkhHoq4gjSPSJp1du3C7KCcAFKBUbehb++zM0J1L5tKGh9QZAQ1M8FCPQ5+ddWejnrpCfoZvKYD2cee6i3Jc0VvhHZXAa4QrUoMCDVUgTGlZG9WQfx7t8RsPg25FdUTPt1QvUBw/14lBXc9ftJdA1LUlGq8ZuMz62e1casJO7A+qu/XMEjd5QCnv8tZC/t4nU/wybYGJ+Q1BWXcCNN2I2ZV6lcmogT5bglvtwS+a8MTDgPE3w/p3q+V89BbpxYM8tC/Y51k8wF6S2p2ZmUyOSh+s76H5FnIJyCnerYWEQ0NcGTpKkEfrS80mbWdF fHauIRFS t2S9cMT2h6A8li/w6zC8Oer7Z+wXU3lO79VfTgPZR75bwCvlsRMaXjE/1bb6HS+sFv7ncbvLidkGqGTU4JEL7fgCtFpdInrKtfxygwMtce3FHwB2FX6oEiROxckujyqXLDJDxqZNoMY8Gjwg= 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 Wed, Mar 20, 2024 at 07:48:01PM +0100, Vlastimil Babka wrote: > On 3/20/24 19:32, Dan Carpenter wrote: > > On Tue, Mar 12, 2024 at 03:46:32PM +0100, Vlastimil Babka wrote: > >> But if we change it to effectively mean GFP_NOFAIL (for non-costly > >> allocations), there should be a manageable number of places to change to a > >> variant that allows failure. > > > > What does that even mean if GFP_NOFAIL can fail for "costly" allocations? > > I thought GFP_NOFAIL couldn't fail at all... > > Yeah, the suggestion was that GFP_KERNEL would act as GFP_NOFAIL but only > for non-costly allocations. Anything marked GFP_NOFAIL would still be fully > nofail. GFP_NOFAIL should still fail for allocations larger than KMALLOC_MAX_SIZE. Or should we interpret that as "die now"? Or "go into an unkillable sleep"? If the caller really has taken the opportunity to remove their error handling path, returning NULL will lead to a crash and a lot of beard stroking trying to understand why a GFP_NOFAIL allocation has returned NULL. May as well BUG_ON(size > KMALLOC_MAX_SIZE) and give the developer a clear indication of what they did wrong.