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 A5031C47DD9 for ; Sun, 24 Mar 2024 22:32:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6D446B007B; Sun, 24 Mar 2024 18:32:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C1DAE6B0082; Sun, 24 Mar 2024 18:32:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABE6C6B0083; Sun, 24 Mar 2024 18:32:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 998806B007B for ; Sun, 24 Mar 2024 18:32:13 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 12AEE160529 for ; Sun, 24 Mar 2024 22:32:13 +0000 (UTC) X-FDA: 81933382146.13.12A1E29 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf17.hostedemail.com (Postfix) with ESMTP id 0885240003 for ; Sun, 24 Mar 2024 22:32:10 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jvhVb9dC; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=5fS4Wrel; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jvhVb9dC; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=5fS4Wrel; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf17.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711319531; 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=3x2fH80xwTkZxJqVhWR9l/YQmasWQHczWuqXjNJsFXk=; b=iR479f0AC+xOlnX8zi5iZl9jaVHhSWm7pCKI+4Rj4CyoSNeh4oyd1V5qMH2siP+bLTbCdk t2yjueM/94zODUva/YYuMqtyi3vtrpm+uJ9TLuOmmYCVAOpHeYiEiH3UxhS3grWgheQn3q OlWFybrC8vL5cB/37bVyN7oYCHxmjpU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jvhVb9dC; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=5fS4Wrel; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=jvhVb9dC; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=5fS4Wrel; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf17.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711319531; a=rsa-sha256; cv=none; b=BG+M9moaRhRJg567N1qfFztrwRBDOY45SQqx/EJpRnXMM1dLBnoH89UiMyVP6D0pe+xAvT wVSWhFgoiq4/pZCV9ttW5HNgKJoJDzCrhj7b+uux6baY2C0eROEaPXRWZI9N9ean82aFaM xwDulE6v0GddphqQXErY2pfaTuNE8g0= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 43DB73497A; Sun, 24 Mar 2024 22:32:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1711319529; h=from:from:reply-to: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; bh=3x2fH80xwTkZxJqVhWR9l/YQmasWQHczWuqXjNJsFXk=; b=jvhVb9dC8c9rBnQhVZkI6IY6+y+rnnsHgLTQKjlNSmIY9YfvIKR+UCP+a2aqQknj7zcR57 7dQS1w4s3kV6KnCaVi+xHXsgJPkFLakrzZA/OHLyovRKl4SaQ/b+TDN2LwVkNITbUaOmmY cLb1Qve0fW/qlTcsFL4hQWUn8dGYljY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1711319529; h=from:from:reply-to: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; bh=3x2fH80xwTkZxJqVhWR9l/YQmasWQHczWuqXjNJsFXk=; b=5fS4Wrel5FtNNRdEMIRLlyrQPbPoWBfnesnsTD7tmGP2WI33mAwbpXcxPhS4TJJrjc5var 2y/liehtYfQwf5DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1711319529; h=from:from:reply-to: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; bh=3x2fH80xwTkZxJqVhWR9l/YQmasWQHczWuqXjNJsFXk=; b=jvhVb9dC8c9rBnQhVZkI6IY6+y+rnnsHgLTQKjlNSmIY9YfvIKR+UCP+a2aqQknj7zcR57 7dQS1w4s3kV6KnCaVi+xHXsgJPkFLakrzZA/OHLyovRKl4SaQ/b+TDN2LwVkNITbUaOmmY cLb1Qve0fW/qlTcsFL4hQWUn8dGYljY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1711319529; h=from:from:reply-to: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; bh=3x2fH80xwTkZxJqVhWR9l/YQmasWQHczWuqXjNJsFXk=; b=5fS4Wrel5FtNNRdEMIRLlyrQPbPoWBfnesnsTD7tmGP2WI33mAwbpXcxPhS4TJJrjc5var 2y/liehtYfQwf5DA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C4F7613695; Sun, 24 Mar 2024 22:32:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id N0HoGeSpAGYPNQAAD6G6ig (envelope-from ); Sun, 24 Mar 2024 22:32:04 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Dan Carpenter" 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 In-reply-to: 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>, Date: Mon, 25 Mar 2024 09:31:53 +1100 Message-id: <171131951305.13576.14679515391685379475@noble.neil.brown.name> X-Rspamd-Queue-Id: 0885240003 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 7xp9ow69tphcat3wi3k8j6zedqieq6gx X-HE-Tag: 1711319530-764725 X-HE-Meta: U2FsdGVkX19ErMoflRxHfE/hTj6mMgyDrVZ3SzumyM/ylWA46ZB1h7fhXb65h1ndW9hPhcrqaPTpTH/yIM+KjF7ROa6o4JAUtr7r7qKdyQX9rMQqc1FrWHx13h+7NxRQJlYtJo/muVOZH9yJTtC+idwV9nJwW5nulCG0dRrGadQFz0fASTDfkkwPmQd6BDZtVew90E/fFDAd3yfBQ5iWke4N8AFe1WAPWRKkSbQnFxDDqZDwHGOLOyTAsMzw7vqraaBA+33jxZo9raavMS+G7KSe1Jp1hiB8+7ygu/ntj4OBHDzlysFUV63CIV+sL3ESuq6l/1popcacN0vsnk3VwM+eBvTE3fEIlSdY9YhQNVSTZvie+2EW/EdiAAlWA6W7Ljgkt29vgJoqy5WL1IWkyAv64mWrfp6ll4tJr+V2h3kxXVCdy7ERh1O/ebHWZIvEQtAd3d7NXD3ZSA3GSZ+SqIuBRV9v6RuBpmxjIxpWFcOU4yzv4IzaKlRWUOtN5qErUJxnokZtRtrjTyPERuH5Qvap90emM+t4t/gKIrgR4jPkpEZqgAtiu2FyvHpW89CC/+cr2J/lIHb0JQtTx6z/g4qInflmM8beWR2p88BOYHbjNIR81mmP2lMMAystaVglQO3uWHMcPiHW2wb/64UoVBEfQKA0w7NNiDfl4a6j4g30Yu2JLVNejF/tXDKY8wvSqn2sB3wFGe5fKXhduN/LgH68sAJsT0LZJKCRA8c8CDb6iDodq3CPHvnHotoM+H1GGN/rStAbpeTmSHGgWBoZrxRt+TV7JKtdAFmafSOFnF4qDJSNlRbwFkT2Dzs4OtGMIy/+Uua9QmS5MyMlDoRuKSlYWitJm69vBlcXLvG3ZuE5lBBF0RgSOz90XQ83lNab 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, 22 Mar 2024, Dan Carpenter wrote: > 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. What do you mean exactly by "keep"?? Do you mean WARN_ON if it is "too big" - certainly agree. Do you mean BUG_ON if it is "too big" - maybe agree. Do you mean return NULL if it is "too big" - definitely disagree. Do you mean build failure if it could be too big - I would LOVE that, but I don't think we can do that with current build tools. Thanks, NeilBrown > > > > > > > > > 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 > > >