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 48941C6FD1F for ; Wed, 20 Mar 2024 19:14:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B96E26B0082; Wed, 20 Mar 2024 15:14:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B46C36B0092; Wed, 20 Mar 2024 15:14:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A36956B0093; Wed, 20 Mar 2024 15:14:42 -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 902526B0082 for ; Wed, 20 Mar 2024 15:14:42 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 36971A11C5 for ; Wed, 20 Mar 2024 19:14:42 +0000 (UTC) X-FDA: 81918369204.10.D91849B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 8383EC0006 for ; Wed, 20 Mar 2024 19:14:40 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PlTQoTIG; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710962080; 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=pgJOHL6eKLRoRRqaIiPicRmx3T3NmG07fCD4Avz/des=; b=4NQMh02aC1bH/9frdsgOJwZ3WOAXufl/krPziDzDxQdnLHQjZXKavxUYAFZ00sKqlO7AE6 L8wIGh4a/sJ1qjC54faUPpbUjW6tbeSLFNrwgKrXNs2AbeiYXBg7MaNVRKYOnvbDLFdZDF jUFNYGkWki5BtjV62zVBnEMoE34tpAI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710962080; a=rsa-sha256; cv=none; b=Krw7IQZ37k3qNcB9AgZzs4HpapjaoF1Ok0rRXDL8fmzvUy9csrdR7mME0B7pGoMbCk3nCI zS2gYE/Ej7G8UQsKWUQNtlSf+RyI8JHAlu/SIQNY0oWTTrMB85zDv+pX0K53VLL3E2fN4Z ivK/x3hCPrZs1smE8Llwq4dqpZbspwo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PlTQoTIG; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=pgJOHL6eKLRoRRqaIiPicRmx3T3NmG07fCD4Avz/des=; b=PlTQoTIGrWd6EWOWpdwcOYiEgB VGV2aoDF0qGjUja+owJJnEVjwBuQRrcYOfa6Rcb07U6ZDhAj64hK5y2oMvQQsHEhothBL11YF+UFX O+s0LX/dZhGWs1lr48W6ZAdqkTYVcwz5YNqC+jxK8fffkD/3RQqNrBChbWZIQDfY5frf+isSCQCZQ rTPdkUjpM48pnL85Ge8h/3b4GLDoPHRUABR3R4IJcdh+U7xpaBjA8paFf++PqGxFeJmxFjXni1edN pYKm5nsVKZ405d1AEw0Nq6lQKgMkDJqYN0OTyq9URZqciOOPTXIeRlNHm1xQ3DRyVN1OfeMo9r32S Zd7kgPGg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rn1OV-00000004wlD-3e8J; Wed, 20 Mar 2024 19:14:36 +0000 Date: Wed, 20 Mar 2024 19:14:35 +0000 From: Matthew Wilcox To: Kent Overstreet Cc: Vlastimil Babka , Dan Carpenter , NeilBrown , 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: <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: X-Rspamd-Queue-Id: 8383EC0006 X-Rspam-User: X-Stat-Signature: 7cbpegu9cig5qwfzmmnhwtad1dk7p4dj X-Rspamd-Server: rspam03 X-HE-Tag: 1710962080-732721 X-HE-Meta: U2FsdGVkX19qZHHQuDnWXg9EIzaZb9DAvrAZ2cWmnK+44irH43Q30JXbtn3eTBkDtcoDHdZ4UtB9Rt1/t4UoKdPvJfbVAiBNS5TZsVnYpytuB8xzMERz5S88J+Hr8ChTozW2LCe9Yu8XPFSEdB6vQmDOx/zZR4pbJQHc2q/TM3oeJCf1tgb9NoSETlm3Huc3G4GuVfM60AQdwhk1ImecJCkIlC3MeWREzHNELCoedlRrILLLCHv2GvdmBsClYORV9KusW+OoY4MwNqRpHLlRtKu0KZcYTRi+UwoZhsW96PhT1wE2SZ4FMbZ2bKrec8j5wgDBMXDZ2na/TBiz/9RvCGEEF6T2i9quKTokuf6r382sqHGaViWyZUQRLZqYGaXopkYlIrVRBYxIOE2pLrp9Jr9Sz16tmk0AbPipubzE3lj7HLfHY0aHMRR0muqSVjYPA8e6mIniA/1qTwQaM7apJRbodNIRQzRXrQUnYOkBT4AX72TeQKdxeUWwnP1uJeHQy4+GX7lPkk+GTfjAJdvtOXi998GCkZRG5iaQBXaqjGDISl4FnRGJRCnq0/DX2ujGHQbi7OPMgUhdI9KdGCJqt+NE3/Rp2r5lyQ/KBdbM7FgMIssxz38VUmbqUOYTzsqIw/WyDTIPbX/JuanptKhWIT/2eN1b75+YPVySnZez/DU1xogV8FpSZMXnWk+Mm/Y3NLNxV9Ml8G+EPkwLg0676EwFSjrdk7VQmCzF6U68XXmc6196DkvLTis86+pyETq707wNJ7oLqE4UlLIPunOs57CtVDA/FpfZk3WmKyHCWOlqbaEWP5MfiuL7WwUptZGvp91HsK31KfAQ7M89uKXoLw== 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 03:07:38PM -0400, Kent Overstreet wrote: > On Wed, Mar 20, 2024 at 06:55:36PM +0000, Matthew Wilcox wrote: > > 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. > > Why do we even need KMALLOC_MAX_SIZE...? > > Given that kmalloc internally switches to the page allocator when > needed, I would think that that's something we can do away with. ... maybe check what I said before replying? /* * SLUB directly allocates requests fitting in to an order-1 page * (PAGE_SIZE*2). Larger requests are passed to the page allocator. */ #define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT) You caan't allocate larger than that without going to CMA or some other custom allocator. So. The caller has requested NOFAIL, and requested a size larger than we can allocate. Do we panic, go into an uninterruptible sleep, or return NULL?