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 7663EC3601A for ; Thu, 3 Apr 2025 17:35:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A88A2280006; Thu, 3 Apr 2025 13:35:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A370D280005; Thu, 3 Apr 2025 13:35:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 925F5280006; Thu, 3 Apr 2025 13:35:45 -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 74496280005 for ; Thu, 3 Apr 2025 13:35:45 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 16B6A58DC4 for ; Thu, 3 Apr 2025 17:35:47 +0000 (UTC) X-FDA: 83293435134.01.5F1B5F1 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id 4B71640017 for ; Thu, 3 Apr 2025 17:35:45 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=osqwXwn0; dmarc=none; spf=none (imf27.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=1743701745; a=rsa-sha256; cv=none; b=msRJOylgYvtWADZ5Jg44xjo8cIyeOt8AlZurIHT/bGMnV5hVtSi4WtInzk8rxqCXb8Aysc IrgRhA116Mki+h9M0PFIfcJbcnH1utPh4rI4IqQ5TCR7r5y5WKORSYZ2ZQnm0L7gHImwer iRc3BIZIKKXQ0ErhFwdRIXRtx5WFFmk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=osqwXwn0; dmarc=none; spf=none (imf27.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=1743701745; 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=+zNCb4oElSV++JAIxIy8ekV4APM4kOcdN9c8XwdVuQM=; b=NF1waanAaXYtvpkg9SKz8GZmGl+zDR8suY5vRe2HyW8WDAha2qo/b9YBlQ/x0QJo6vdshA 7dKGbXguCKwR5HrVpHPZLS60L9yuEpRYeMPoPqwEJzo2+3oH0lI+CXeRWx4D03G4WXkoSm vbSm0C/rRC7uZ5qgqkn3UMrVSIxBb14= 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=+zNCb4oElSV++JAIxIy8ekV4APM4kOcdN9c8XwdVuQM=; b=osqwXwn0wMWUxQtyTC40Lv91ML HSG85bEEGPO5mZb3oDOxb8u7trcXhCenNqXAlRZXvOEM52dHN9r8WpieqwDSbBjgQVot+/mtu1mPm BBbervCmlr1RYjM02vxZBRyslpWy8KOoQB31VtJYzzr0hBv3RZRh37GcFLGNPBedjn/XmKqJ6Dp5O PqIeR57OZi7qyync5onN6uDvfcMWNtfDjfJqCp5bAbx/rR/nnfmZXc/fYMtXzQFF7v6wNmimNY3Ov +WzaK0pHNDAnpZlFd+kIK30RFVN/1rxbQ58SUIrSScDo1FxljuAV6qh2wMqd5hZYZ8iOoGVyJ636c Q0dGiLAg==; Received: from willy by casper.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1u0OTb-0000000DOaJ-17Bp; Thu, 03 Apr 2025 17:35:39 +0000 Date: Thu, 3 Apr 2025 18:35:39 +0100 From: Matthew Wilcox To: Kees Cook Cc: Vlastimil Babka , Przemek Kitszel , linux-kernel@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org, peterz@infradead.org, Jann Horn , andriy.shevchenko@linux.intel.com, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, Harry Yoo , Christoph Lameter Subject: Re: [RFC] slab: introduce auto_kfree macro Message-ID: References: <20250401134408.37312-1-przemyslaw.kitszel@intel.com> <3f387b13-5482-46ed-9f52-4a9ed7001e67@suse.cz> <202504030955.5C4B7D82@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202504030955.5C4B7D82@keescook> X-Rspamd-Queue-Id: 4B71640017 X-Stat-Signature: tp51pdtih481wsm41qe8mdgqo984dp8a X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1743701745-675434 X-HE-Meta: U2FsdGVkX19YKStItYJi0/TVz0fph/LhOwURB1B2eLxC0FXBNFCsqmt9QROiYYlOnRLpa0v+NgnyFgizjkyG3rkRBrwepeWu/SDNQiGSAgB785IByZ556KC+l1CxdiKN0RRDp5HHOFWbyT1Mxy49sdNSgHaBjkoEH33C8YSwdiRxSkaq4J7/xpFcs8dp84f5no2PjYch6rJys7l0O76LwPw8Cil2ibIuh9UsAHo2lEz/6xtphi0UcyUj7yqfuNTcKtwRBB6/ccvDZdFLcxGOcyQao5xyFbou4ieph3vO1JJV63kR7UNnga45Afx6zmTJBgoYF/6KgsQFVrTvgwG0vh1+PmwUAyFcfZWinHUU6ZPZhx29Km04tnbW4DLhM3IrlHYVQZDkWxay5ORqKVYf/+tpYz/vYtuoVnt3mB5B1Zzyj1OPFTbtIiIVac+aPh8OV8gKJj/sh4oPr3twEQ7BUTmHuPu357fienVI1ds3ZUiKsZqNZc8jVEbLqpOBtiqn9WFlkSvaVF29G6oHUK5OcHKEXonwHrfnuCrKv1VLl+nDOnPo966OP7WkCwQKVz37bQiu5EuNSALDN3HX6KxgymS53pfHqNknLhvaMcGr0Slbu7PBsjFLXnGpmAjp02K56YjCmTLKAG7JFnpOCGxIQ3BEbuzUOISEEQnrkYkBTM5sZYZFtkoR2HYqOhEpzSe2QaiLdSbXLYitoSaRTNK5tNmv++gZk8ZLjKdmOxXsDJbuIpxNY7JGaXJnINs67ReLUeSHdfhv4imhsW1Jc4+qIUxnaIWKvNrdWjEJoLphTB146Irm1cTov84KhwchUgF8+WLp38XS8jyD775aAnvdE6wxI107igYtONYqpNZJjQMkJMZb2s+lhFFYx8TIe7OJqv+C7zAYJkqt3F3++LZqJhU0E6w4ENNjJRjVa6+tm4Oj2aPD/TGv5Ke4QIPg0e5yi2uFhOWGfQ+BQ/Vd5hu b6cbq1QG 4kCBezHhpARI/deY5oOkhQbuvBAHGBUnRckaHbMUtcaAzrgLwoZPgXIWvrgMyim74iCK2qf3u9IykKFCdr4/OC178/qtXqWE6hQOoEBCTQVSPRiwInBmGYW1yijox8jREUlwxuO66VBArL8uDbid6htjybaRpHogLdCojXMSbWLFRnRJu718rgm8cQxcVwMSyFeaQ9ycyKeXaYgmn3GZa2rlmFMBSPYSMPt+W/Co/0k2SkF17C4xOlDTwSf4MQz+m2vI+9EF1jHoCYYoNxNVym3GQuCcrYURpqIfn+kjGo5F+Mzg= 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 Thu, Apr 03, 2025 at 09:59:41AM -0700, Kees Cook wrote: > On Wed, Apr 02, 2025 at 12:44:50PM +0200, Vlastimil Babka wrote: > > Cc Kees and others from his related efforts: > > > > https://lore.kernel.org/all/20250321202620.work.175-kees@kernel.org/ > > I think, unfortunately, the consensus is that "invisible side-effects" > are not going to be tolerated. After I finish with kmalloc_obj(), I'd > like to take another run at this for basically providing something like: > > static inline __must_check > void *kfree(void *p) { __kfree(p); return NULL; } > > And then switch all: > > kfree(s->ptr); > > to > > s->ptr = kfree(s->ptr); > > Where s->ptr isn't used again. Umm ... kfree is now going to be __must_check? That's a lot of churn. I'd just go with making kfree() return NULL and leave off the __must_check. It doesn't need the __kfree() indirection either. That lets individual functions opt into the new safety.