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 smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E151BC3600C for ; Thu, 3 Apr 2025 17:46:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8C3BD40811; Thu, 3 Apr 2025 17:46:31 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id xRNF_6M6Dyhg; Thu, 3 Apr 2025 17:46:30 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CB4B540856 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1743702390; bh=Q5gcc5IFZwT5cwfkK1LdyPdDF9nyGh/E1mfzORV+BT4=; h=Date:From:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=J07qyZgwLAqK4ZF5IhAOrTof1EZQv9QUoB/Y77+tmV3ePXpGbhlvDsWiRK1FhWXJn WZFxl4aVtdUSWbBd/o1tm/8mC8mCfgmgnEM9yq1JyxaqQcj7d5lEHX+AKy4AjjfNJl hasEKQwH0ycfHqTVMbsSBUNOb90H8PFYebmQBIcV6rBXdsy1xk6aJzuL0un4qTrJV0 o2ivbCtPqbRcW1VvceMe4KEIMyrcnrrVuj7AJMiToRBuGKGSBb0tVzjlTDb2t3pXF/ zLPu/CRSul4UTUp1T8Z54tlFBL7UA01Xc8VJpHp3KBiD59hJcb4kwIsQlxMvc7cXH7 YW73L1vsEW8og== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp4.osuosl.org (Postfix) with ESMTP id CB4B540856; Thu, 3 Apr 2025 17:46:30 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists1.osuosl.org (Postfix) with ESMTP id 4EADE119 for ; Thu, 3 Apr 2025 17:46:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 35D5741B39 for ; Thu, 3 Apr 2025 17:46:29 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id GEBYEfA1U-3w for ; Thu, 3 Apr 2025 17:46:28 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=192.198.163.15; helo=mgamail.intel.com; envelope-from=andriy.shevchenko@linux.intel.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp2.osuosl.org C563C400C4 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C563C400C4 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by smtp2.osuosl.org (Postfix) with ESMTPS id C563C400C4 for ; Thu, 3 Apr 2025 17:46:27 +0000 (UTC) X-CSE-ConnectionGUID: JvdBrp0KSZKbmc9JjxP9VA== X-CSE-MsgGUID: AsNT57cMRhK5BMsWCUxhkw== X-IronPort-AV: E=McAfee;i="6700,10204,11393"; a="45247837" X-IronPort-AV: E=Sophos;i="6.15,184,1739865600"; d="scan'208";a="45247837" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2025 10:46:27 -0700 X-CSE-ConnectionGUID: XL8V0+HVRweSrPe2l+1fFA== X-CSE-MsgGUID: fYhD+ywtTVC4LwHnZlU8Zg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,184,1739865600"; d="scan'208";a="164309309" Received: from smile.fi.intel.com ([10.237.72.58]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2025 10:46:24 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98.2) (envelope-from ) id 1u0Odw-00000008ssY-2AYW; Thu, 03 Apr 2025 20:46:20 +0300 Date: Thu, 3 Apr 2025 20:46:20 +0300 From: Andy Shevchenko To: Matthew Wilcox Cc: Kees Cook , Vlastimil Babka , Przemek Kitszel , linux-kernel@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org, peterz@infradead.org, Jann Horn , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, Harry Yoo , Christoph Lameter 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: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1743702388; x=1775238388; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=CrVVJHvTACiAZiAbOqNpxsX5Sm/7YBaDo7amhX5eups=; b=ZGZmO3yGH5xYed/hHCi6XnPYnhJHt5z+mSXCMEJV8aWe2oaHofjeIygd KzOyLjJX49KZPBsX919wmk5TcbDHOHcyd09W7YlzlPg/PJKks3hLUvz0w oV5Me9Ut42XEc6qYMtZG7CR7zJ41q574hAJfeSPTRVTpfsGKwwXLqjtOL Cbjdija+y8AAHsCS8djEvP/JJKrCTSQpw3QwHSQcJ7nIBrA5iYtqh2TqX G74E37OG6T5JmJ1KF9uf1Uoz6+aSLzfSKwW7Hos0P77SZZAXl/v+/bIuO 2uq4jYutnA2VCo5nYqLhTvDT4Jv+crpYpuf9IotDMeVkk8K/7T7AC8Y53 w==; X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dmarc=none (p=none dis=none) header.from=linux.intel.com X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=ZGZmO3yG Subject: Re: [Intel-wired-lan] [RFC] slab: introduce auto_kfree macro X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Thu, Apr 03, 2025 at 06:35:39PM +0100, Matthew Wilcox wrote: > 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. Maybe something like void kfree_and_null(void **ptr) { __kfree(*ptr); *ptr = NULL; } ? -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 342BC24BBE9; Thu, 3 Apr 2025 17:46:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743702389; cv=none; b=aUrChNfC+ObQx8yBSkECJdUw7y2lcmwGYf3f+yBZ7X1NSxpJT5ClyP4h2ujMKTJ57C06yBbzgWnp2a59MicdpM410XMisYlVuEgABSXuvmUA0q18aX8K1Dv0hTibI6WP5TWPmAZ8pUaYZCQ0GsIgW7J91Uy6oWi/vC379kyEH/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743702389; c=relaxed/simple; bh=CrVVJHvTACiAZiAbOqNpxsX5Sm/7YBaDo7amhX5eups=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=re6UXnE0xbOaRPkB5ShmevOX+w84S26sF8K3kktu9zTDsHDQKtaaiJ5VrozXPRSwU8FZUWEc81ZDAoGweC6Yq7dRsAoTJyUrEzNT21KZqqPLEZwgFsFJ0TkILq/k9CcuLhPcQxN87SxiCzdqL7PlRCtksWEIH9PrIOral4AYlaM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZGZmO3yG; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZGZmO3yG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1743702388; x=1775238388; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=CrVVJHvTACiAZiAbOqNpxsX5Sm/7YBaDo7amhX5eups=; b=ZGZmO3yGH5xYed/hHCi6XnPYnhJHt5z+mSXCMEJV8aWe2oaHofjeIygd KzOyLjJX49KZPBsX919wmk5TcbDHOHcyd09W7YlzlPg/PJKks3hLUvz0w oV5Me9Ut42XEc6qYMtZG7CR7zJ41q574hAJfeSPTRVTpfsGKwwXLqjtOL Cbjdija+y8AAHsCS8djEvP/JJKrCTSQpw3QwHSQcJ7nIBrA5iYtqh2TqX G74E37OG6T5JmJ1KF9uf1Uoz6+aSLzfSKwW7Hos0P77SZZAXl/v+/bIuO 2uq4jYutnA2VCo5nYqLhTvDT4Jv+crpYpuf9IotDMeVkk8K/7T7AC8Y53 w==; X-CSE-ConnectionGUID: ZQ3GbaH6TzahkG/A5JKI+w== X-CSE-MsgGUID: Qs74iPb+RVaWSn7FWNcHaw== X-IronPort-AV: E=McAfee;i="6700,10204,11393"; a="45247842" X-IronPort-AV: E=Sophos;i="6.15,184,1739865600"; d="scan'208";a="45247842" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2025 10:46:27 -0700 X-CSE-ConnectionGUID: XL8V0+HVRweSrPe2l+1fFA== X-CSE-MsgGUID: fYhD+ywtTVC4LwHnZlU8Zg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,184,1739865600"; d="scan'208";a="164309309" Received: from smile.fi.intel.com ([10.237.72.58]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2025 10:46:24 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98.2) (envelope-from ) id 1u0Odw-00000008ssY-2AYW; Thu, 03 Apr 2025 20:46:20 +0300 Date: Thu, 3 Apr 2025 20:46:20 +0300 From: Andy Shevchenko To: Matthew Wilcox Cc: Kees Cook , Vlastimil Babka , Przemek Kitszel , linux-kernel@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org, peterz@infradead.org, Jann Horn , 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> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 On Thu, Apr 03, 2025 at 06:35:39PM +0100, Matthew Wilcox wrote: > 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. Maybe something like void kfree_and_null(void **ptr) { __kfree(*ptr); *ptr = NULL; } ? -- With Best Regards, Andy Shevchenko