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 C00B3C3601A for ; Wed, 2 Apr 2025 10:40:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 224B1280005; Wed, 2 Apr 2025 06:40:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D133280001; Wed, 2 Apr 2025 06:40:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09BA4280005; Wed, 2 Apr 2025 06:40:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DEE44280001 for ; Wed, 2 Apr 2025 06:40:27 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6D4AE12163C for ; Wed, 2 Apr 2025 10:40:29 +0000 (UTC) X-FDA: 83288759778.17.FC31372 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by imf22.hostedemail.com (Postfix) with ESMTP id 04B91C0005 for ; Wed, 2 Apr 2025 10:40:26 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fbf+rEtK; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.19) smtp.mailfrom=andriy.shevchenko@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743590427; 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=dT9HyL/hV+skBEwMnhJp3GQdWq/EZWto30S4XhTDXq0=; b=NDPodB3CVV9HtHfNROyFHk7N6pKzs+k5j28LYlatJtp7secarqrSON8zpBiYFDBfxzLvZS 6EJhxsZQCmiWkXt2qSdrshDN/bBgElf5OqlzGJlL59W/0yDkPix0RXgrPcjQg9fFTU4f71 4qkXk/IwAoUAa3dChQdJdIPIufk6MGA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fbf+rEtK; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.19) smtp.mailfrom=andriy.shevchenko@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743590427; a=rsa-sha256; cv=none; b=XvM+PQtM2sShHtLds+5vCp83egJuiHwAlCuOaMcPCPIF3IlHCgYAYJwi7FIyXm+YglZAqX uz3Q4f6CvZpVaeldCgpMA43Jw8lJGLaKL6/lM5A6UFZP1NGLs5rF1S6IDc32TucLtMtoZW MALGZY2sgX+bFd+pfGHP5BfWtWUDFpM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1743590427; x=1775126427; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=CoY9PcV0OuQT2I+HqoR9fOe7ZJeqTGaH6ofEwP5Qw60=; b=fbf+rEtKUybD8SUH4OeXj5dN5aX3vDnlnyDJolyF6S169lBSreCe9+Ki nLdVwjgHnW3dYGWTpENcGCf1ogZVWGaKHCPaOfbUgW3tukkR9/gXMyLcU F1Zijb1CoXXt74hgLXM6Lk6EKbJIWEfo3aZEE3B8aLxsCkA+41+l7nueU kwylhL4OC3mwZNO1JsT3vQnZRPD2ilGpWywdJ9Pim9gJXbCKphf/fnPMm xm9dwBcT/qQa7JO+gLWR4ZdzH0/MjJpnmC+ETun16yRSXGDA5vVCTzR7m o+r3ejYfq5DQLtVZuJCeldncHcbdfq92ObuDnmdxZ7uiHT61BqJ379yaj Q==; X-CSE-ConnectionGUID: cCepE0a2TlmqQO7/7jUFsA== X-CSE-MsgGUID: 81ISOoBfSS6FZa3FY+DjOw== X-IronPort-AV: E=McAfee;i="6700,10204,11391"; a="44094635" X-IronPort-AV: E=Sophos;i="6.14,182,1736841600"; d="scan'208";a="44094635" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2025 03:40:25 -0700 X-CSE-ConnectionGUID: MYYHhJdkTrmZBOSTYrqHtg== X-CSE-MsgGUID: XTbPLY+pQv61IgbZ7SJ4ug== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,182,1736841600"; d="scan'208";a="126639518" Received: from smile.fi.intel.com ([10.237.72.58]) by fmviesa007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2025 03:40:23 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98.2) (envelope-from ) id 1tzvW8-00000008RM3-2kDU; Wed, 02 Apr 2025 13:40:20 +0300 Date: Wed, 2 Apr 2025 13:40:20 +0300 From: Andy Shevchenko To: Przemek Kitszel Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz, torvalds@linux-foundation.org, peterz@infradead.org, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org Subject: Re: [RFC] slab: introduce auto_kfree macro Message-ID: References: <20250401134408.37312-1-przemyslaw.kitszel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 04B91C0005 X-Stat-Signature: pkh7hnf5g1kwc13bctwff9kwse7c97qj X-Rspam-User: X-HE-Tag: 1743590426-142361 X-HE-Meta: U2FsdGVkX18NqHvRA4RmH3QOU8qPWG3y2erdH6759lrTJ71HDJDJnY/5HaiPu5NSo6y9pA1HdY6viZcqfi4d72bqkMQwPf7WXKBWZye3yB+Xd5JsAofpWf11iplUJEYiBr/d9cdOWZrAjjLWPxN+f087yEiZsE2qSY35puNhPoKEhc/ry2Gd7i5B5EpmrNMn0yWfpZZudQ6SyxKrS2ny1RsrPoBgx0k4quE6VYoxpAgXuZCAkbKE/ZDwBM8F4SHvqlND+UyMvUU48llgE40virAxOuDLCfHCOxs2cE2MFx/iHaxgVoomNOIO7hZzB30x9ZEi8wRP9SSJ6JpIjFZ1692y4/I8CqcYwTcG0XkwSHI8no4z/nHaRJdkA77yd06YwQwZwtB9TXcXB+p+3kBaacBc/dvO2OK6XAK16CT+LslEJS+/abgLp0BUUZWIeOc+7DJVmoLiY9jmwzoSYt9jdZfwTFPqz5VYkxwKM84eCjTFKspv4GJHSSVXf4S46iNIT6uFV7Ct4afSEFw93d5F27AwLf/Hqm/kQHa5ynpYfFiqwzMmtQwISChlVA8M38sk1MnOWNfMBFcwfiNQ1jJjOeFcCPy1WqeWjdMSunaSsQIeFZutbyuOQ34UDftBMOK+k7asluM1bqIpqoKuGBPVIOcyuKo98kb1xWHPilRLzERYkWnEEO8Dyjrs6H9tkmVtgMgeYzU22vA/PTCZdgiBGJmdR3F17otAOTk9vcgom97Ay8UpHzTQlXZvpZnHglPLy/pwgSDQcO1Vb8DLQl6VyYrjGd5KSYZx4bnX/Noa7W8OZgcM9mSDRlJrLmnh4Ni3rxilpSu6zFfAjUL251NOFcuJB2uCEpZUw3MFQudSZdnNx9MPAjksYtPvsZxs+bgqjnaUiqjvq4xU7CFv56Px0KQGBaa4znrJQM28U6Z412tFFzOB3vToFZL/TrYeWPHh6KA2sbBvCHhgJkYekMq K1bBZNUd W+NzBmX3HkkiLFa6Acm159eUQ873JYjoJahb6ggNtu8dYY2eLezyJ89Vp2h6UeN+/n0O0adFG6t6yIuGNyKGdLsH1no2X47WUokg4ccb8s/QBEEU5iXMCxFbQ05YNK3Cw71UP0E24fw9MEN22CLDqPhcf1Jk3yMSyjjhEPMILJd65+/JStCsE3AslXQl7crsGaqH/Cp3eShUfMowCW/yWVYjcAXs3isjrkDZcPn88cUKKJRc3n83uediNi++ssmXqmEqwW7/6Zw0av0o= 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, Apr 02, 2025 at 01:32:52PM +0300, Andy Shevchenko wrote: > On Tue, Apr 01, 2025 at 03:44:08PM +0200, Przemek Kitszel wrote: > > Add auto_kfree macro that acts as a higher level wrapper for manual > > __free(kfree) invocation, and sets the pointer to NULL - to have both > > well defined behavior also for the case code would lack other assignement. > > > > Consider the following code: > > int my_foo(int arg) > > { > > struct my_dev_foo *foo __free(kfree); /* no assignement */ > > > > foo = kzalloc(sizeof(*foo), GFP_KERNEL); > > /* ... */ > > } > > > > So far it is fine and even optimal in terms of not assigning when > > not needed. But it is typical to don't touch (and sadly to don't > > think about) code that is not related to the change, so let's consider > > an extension to the above, namely an "early return" style to check > > arg prior to allocation: > > int my_foo(int arg) > > { > > struct my_dev_foo *foo __free(kfree); /* no assignement */ > > + > > + if (!arg) > > + return -EINVAL; > > foo = kzalloc(sizeof(*foo), GFP_KERNEL); > > /* ... */ > > } > > Now we have uninitialized foo passed to kfree, what likely will crash. > > One could argue that `= NULL` should be added to this patch, but it is > > easy to forgot, especially when the foo declaration is outside of the > > default git context. > > > > With new auto_kfree, we simply will start with > > struct my_dev_foo *foo auto_kfree; > > and be safe against future extensions. > > > > I believe this will open up way for broader adoption of Scope Based > > Resource Management, say in networking. > > I also believe that my proposed name is special enough that it will > > be easy to know/spot that the assignement is hidden. > > > I understand the issue and the problem it solves, but... > > > +#define auto_kfree __free(kfree) = NULL > > ...I do not like this syntax at all (note, you forgot to show the result > in the code how it will look like). > > What would be better in my opinion is to have it something like DEFINE_*() > type, which will look more naturally in the current kernel codebase > (as we have tons of DEFINE_FOO(). > > DEFINE_AUTO_KFREE_VAR(name, struct foo); Maybe slightly better name is DEFINE_AUTO_KFREE_PTR() as we expect this to be a pointer. > with equivalent to > > struct foo *name __free(kfree) = NULL -- With Best Regards, Andy Shevchenko