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 3000DC54E71 for ; Fri, 22 Mar 2024 06:13:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9809F6B0092; Fri, 22 Mar 2024 02:13:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 92F4A6B0093; Fri, 22 Mar 2024 02:13:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D0696B0095; Fri, 22 Mar 2024 02:13:38 -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 6BAA76B0092 for ; Fri, 22 Mar 2024 02:13:38 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 35EFF1409EC for ; Fri, 22 Mar 2024 06:13:38 +0000 (UTC) X-FDA: 81923658516.03.73D3260 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf03.hostedemail.com (Postfix) with ESMTP id 4D8522000A for ; Fri, 22 Mar 2024 06:13:36 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=YRQKTgOU; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf03.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.221.44 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711088016; 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=vjqo6wElKZtgGNj6GGnnTBQeXO+eE9diL9uYn1NC34Q=; b=t+FLV5F688N0zdf2g1krqHpQwBLz32Kab+gDUP/KxjfoDPMXegwI2BMArO7qpReiWZHdXI Ct2topH+vcUuj6DmKmt4QsRPYdZ1+ThhTuBeuwDHemMrBO/m67Cml4jm/LlF/JxDnF0FWt 7bmnwTiJA1IW7pC78FA0nOgKp7rTWoM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=YRQKTgOU; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf03.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.221.44 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711088016; a=rsa-sha256; cv=none; b=41+XpqhI41QOOzR4ihJ595eV3jprOnClYWP7Zrd51LtXSCaGwLPzW9eKLwp8TRzXOfohlg FKR4b6usdwNGGdUVEsVQj13ZjSXxtkSnmwgCrht684tQpD5813hK9L7QrRev5ZICCxBNyv hr68YaROjtz2joNAZoXEEjoJS2Yl/E8= Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-33ff53528ceso1027367f8f.0 for ; Thu, 21 Mar 2024 23:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1711088015; x=1711692815; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vjqo6wElKZtgGNj6GGnnTBQeXO+eE9diL9uYn1NC34Q=; b=YRQKTgOUiTIhdPXhIBITuWDYvcfNLNKtpq+WvXkVpm+wh5+XMYw9hOwsrZPNrO+KMF gSgmuxR/jduflFnXwFzQkQ55FSwQvbQeC1nzIx5Jtr8u8/zk20WK0leHIrvrdqZDHgml moRyCUPRfMjM8UyBy2495460x6GUkqn1kkkyvchN54XJ8vfbUYlH1k7WBFmCFCXwY19t S50f72GJrAKD3s/Ida4zAMhHgE52mmtGUz2kdi173pYPjQrRy0c43ICyS4BM8ArvqApC a3vqpccVzP1K2TNCws2Iwfd/oO2nk2WvdN3oV6y1hK45AqZHemj1fzSn3Djh6niBfwno uNSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711088015; x=1711692815; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vjqo6wElKZtgGNj6GGnnTBQeXO+eE9diL9uYn1NC34Q=; b=Wr0ZTciWPcx5poyVc8JGtkh3MgqO7dk+/KeL9gDiWQO+TV98FtFnDE/UkShsxjpWSw BMrxGN8Y4bzDd/QCbPE2UkYwhKMpUpMm3LOnv6XRXbMab5AWMub09ccVAKT1Oc2paiAj zBD3K9hfDRpNdYuXxIPHW2ZP/lnZnbo3Jti6sFv93ToFePOx5sX9+46foqeJ0chovgq5 v+fXv8EsVzRUKCuku+XlHa3S44/QzMUZPoNpzno7ie6GeatIckNM5xhVUyO0gTMOR0fm 7M1Rri0O6zL3gzn5pqkw/ttdzrXb1mHvXHByWx1bjpC6uX7JrwhQD11LyBVE/yg82qFY vFSA== X-Forwarded-Encrypted: i=1; AJvYcCVLCm3IBFsaOpK7LlcCqugGAQHUxNS9jx5H9byHhzRv2YNT9iMqb3OcaV84LVoj8hKV8Elw7pYJVjrjaf51k8+ceqE= X-Gm-Message-State: AOJu0Yydfz5MS83g47IRlHU7sXfqoXBcy7QIX0JCkA2gHJLqxCBYnJqP LNhIkxAi7dJ623XXjPCen2jPEucFY5pFATFN5YG5tc4big1FNHXRhRqAoztHo5o= X-Google-Smtp-Source: AGHT+IHm8OsbpGQ2JHUp5hBd388gtEhT3nrU3IpFVsVcGMJeNceWFfJltzX1vVpM68rf361cJgKaKQ== X-Received: by 2002:a5d:6dc1:0:b0:33c:e396:b035 with SMTP id d1-20020a5d6dc1000000b0033ce396b035mr733113wrz.69.1711088014591; Thu, 21 Mar 2024 23:13:34 -0700 (PDT) Received: from localhost ([102.222.70.76]) by smtp.gmail.com with ESMTPSA id e9-20020adffc49000000b0033e192a5852sm1263895wrs.30.2024.03.21.23.13.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Mar 2024 23:13:34 -0700 (PDT) Date: Fri, 22 Mar 2024 09:13:29 +0300 From: Dan Carpenter To: NeilBrown Cc: Kent Overstreet , Dave Chinner , Matthew Wilcox , Amir Goldstein , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , Jan Kara , Jiri Pirko 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> <22363d0a-71db-4ba7-b5e1-8bb515811d1c@moroto.mountain> <171107206231.13576.16550758513765438714@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <171107206231.13576.16550758513765438714@noble.neil.brown.name> X-Rspamd-Queue-Id: 4D8522000A X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 3hzk4hztujt7hiacnizgzkxoibx7u4b1 X-HE-Tag: 1711088016-839677 X-HE-Meta: U2FsdGVkX18tDm3AduS7M/bDTstfpwu1aGNYF0ASZosCUtt+c7V8JQn+b3Y2Z3j+PGD7YHn1yMRc1DdLmrFbCXTiJnaDcrcG3xzxi4DABy3EZyTLzYcM5Saw7BIzrJ3lLvIxRZjETYTANXa7NBqlMsWT5BIR+pikfO6AyAA77i5rhKGEw8lqKNgXitSmlKwqkg1jvGCTTPc7pXDJbZx4CZHRQ9mZuc9DN/dNNIWbrBEFZJSjoM8JMRUOXv1pM8m6nNtpf0AYcpcoWCnAAD5JyxrCICUPNAB7AoGnpCKZVCL0T1MYkDA0LL0Q14zDzM6Zj43Wbp1oOpHtKK/w7XUXNEtaksdx0xb21exBMhmDpVholkLgUxnK+H4VGv4nK//TgyaABK1lgLS2k940LK/8MSFtS7D1pt3rpGWxDwPTYIQJytyflBfw90otEtZaU6QP9Ij1+E0ZESXxQ+GOl2gqPSIklwi2HrbFrn9p/SBdLkh+f89bJf0RbDorrTtmKlMG6w1jfcfWhdyEGOA5QRaPYIwGGz6yghUIk+BnoUNe43oWpDTSQrN+wt+5z70nHhINX2ZP5SkpI6CmSOGRDewG67LVA2twvESYYVtihWH61ALyLLJb2WY3AP7mLknYVRqEwI0yez+bMbEVoz7otv1lq97Xv1byjTyo/GsyudSIUHB6MPTaAon1g3pCQol1yxTbJw0VafFiJZfrzFKL/HqzZ5nW+2t6Qz2PmUomKpKzZ8ZzengeqrppIWgDCK2HeAQDL+0O1mQpd4oIpxVc2LBQCyZUyVmAE1fFANRUJC2a4Kbk6s+yYV6VzWkQDTNY8rdZvx8TQrIXpvyXO4E7z5vO7MH2T7qUs1kFiYVq0GpB35Uxk6fLXRUb1He+d07Zqfuz0wH0aKwXNV2OKczu2q/8pHRHWRLK4dQdJC9Z7/fsO0iC+5O8B76QDUkITg4LcW7ZnaJLrCoxNE1nfdyBBNe Ep4mtC5i d2Q9ccfeuj78+YZXsADXIBx3tIT68XF8ZeKAuPBHD2txZlAO1861i83Xi4RMrsJIH6bT3sQiPMhaAcja6Sz+uvKE0Pa+b7S+QShwDHe5xx4ZX90X4Qin1mN8+Y40EW2q1hq1Oznypb2ynWepzEOeuCXYN4dgBwL1pO6Hsp0p3Jiu//ooKAjByqvoxc40CrvfqtfaH/sXwkG9spC49Rq/KvVzycNT1jJTldduYgQ0Y5RLoA7KRp7ePyabv3WcOpQnpzM4FqQE2CNzS27aMLTw/MtESY+ORtwhHvpquLG/VoryJTml10TmmkLOVfG7hESidWpew8WulninU6voJretc42DgBDbRT+Xkp4klch529K1whE0= 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 Fri, Mar 22, 2024 at 12:47:42PM +1100, NeilBrown wrote: > On Thu, 21 Mar 2024, Dan Carpenter wrote: > > On Mon, Mar 04, 2024 at 09:45:48AM +1100, NeilBrown wrote: > > > I have in mind a more explicit statement of how much waiting is > > > acceptable. > > > > > > GFP_NOFAIL - wait indefinitely > > > > Why not call it GFP_SMALL? It wouldn't fail. The size would have to be > > less than some limit. If the size was too large, that would trigger a > > WARN_ON_ONCE(). > > I would be happy with GFP_SMALL. It would never return NULL but might > block indefinitely. It would (as you say) WARN (maybe ONCE) if the size > was considered "COSTLY" and would possibly BUG if the size exceeded > KMALLOC_MAX_SIZE. I'd like to keep GFP_SMALL much smaller than KMALLOC_MAX_SIZE. IIf you're allocating larger than that, you'd still be able to GFP_NOFAIL. I looked quickly an I think over 60% of allocations are just sizeof(*p) and probably 90% are under 4k. > > > > > I obviously understand that this duplicates the information in the size > > parameter but the point is that GFP_SMALL allocations have been > > reviewed, updated, and don't have error handling code. > > We are on the same page here. > > > > > We'd keep GFP_KERNEL which would keep the existing behavior. (Which is > > that it can sleep and it can fail). I think that maps to GFP_RETRY but > > GFP_RETRY is an uglier name. > > Can it fail though? I know it is allowed to, but does it happen? > In some sense, I don't really care about this, I just want the rules clear from a static analysis perspective. Btw, you're discussing making the too small to fail rule official but other times we have discussed getting rid of it all together. So I think maybe it's better to keep the rules strict but allow the actual implentation to change later. The GFP_SMALL stuff is nice for static analysis because it would warn about anything larger than whatever the small limit is. So that means I have fewer allocations to review for integer overflow bugs. Btw, Jiri Pirko, was proposing a macro which would automatically allocate the 60+% of allocations which are sizeof(*p). https://lore.kernel.org/all/20240315132249.2515468-1-jiri@resnulli.us/ I had offered an alternative macro but the idea is the same: #define __ALLOC(p) p __free(kfree) = kzalloc(sizeof(*p), GFP_KERNEL) struct ice_aqc_get_phy_caps_data *__ALLOC(pcaps); Combining no fail allocations with automatic cleanup changes the way you write code. And then on the success patch you have the no_free_ptr() which I haven't used but I think will be so useful for static analysis. I'm so excited about this. regards, dan carpenter