Message ID | 20240228204919.3680786-8-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-85694-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:a1a:b0:17b:cd04:e0c6 with SMTP id 26csp240851rwa; Wed, 28 Feb 2024 14:53:38 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUWzddA602QS5gLF0waMhOTqjUjQgJFIhfAZsHIfMDR+pr16AiK76ePTaQjTr36xrU2KDH2MUU571I/Mhd9lGQHrwBGZQ== X-Google-Smtp-Source: AGHT+IH/vHMvky40JiJgbZsgGYEuKeiTBGswdUOfxX8H9HsXO425zktUvDLh0O0+kEcExN+Tlf+m X-Received: by 2002:a9d:7acb:0:b0:6e4:ab08:26f1 with SMTP id m11-20020a9d7acb000000b006e4ab0826f1mr348950otn.7.1709160817955; Wed, 28 Feb 2024 14:53:37 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709160817; cv=pass; d=google.com; s=arc-20160816; b=PsL7JGwkLyjvWpgKgJidUJMx1m58DLExRn8D99H+iAmHX41Nk9DR0okZwbEw4/Iv5a UczGxl6+nVNxfJ2a2lSlqXQGv4KEOSOFlet3rXtgQfs1realLABz96CVGZngenrKrtNG 9GIhXWvCn8r7iBSeMVIiURGo5YPWtivosdeKrwNS+9XZh2+Rs4+3hNzkcIxHG/yF7JMb zH3ks7rwRt9QGQNbIRgZ2f9Y0lVhqY7f9YLKeihRZo1CBZaWPNGR3cuJcF+qAthCM/M5 LtCzy9xYRcEvwEHQsHYXaWFrIHr9OsH7chqC5zcsyXXpPBeKRHtd1JHyN0jKkUMliOSS 6rBw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=VoOuNpVbp12gb0UNvqB1OvHcbWGCnuTG1v0q+w1cJfs=; fh=SDJEwBjUOHB9dr3Xf35E782n6oCWBirh57Q+2DGhRIA=; b=ekZMvhL7koMGHxEy+ZYDw2Sitifb1IXfksXpWPUYA4CfwmUeEc3WfBY4SB3+/3Fehn f+mkrxVo49KLw3V0TAcfYm6nDPlCpMX3gJ1rjp2sVJkw8iHnssy8ei1WzX+taplDVztj 2Vyeo5HkEIkxebcEBygmUguG7LbAF/Psut224NBwgEHO03+DOQba8qJ/CW1AoQvFtD/+ 2WiQJLtHH7aUF7DAXRW26bDFBSKCQLrt8hFzWa2hWUn8oaTn+pfSHhTNJZQ2YD/tiPpS fgKzQBMBDhIExQA+cxL/DG8BhdXUXdw0jcpJ+68VPb3HFjF6V+UVZUsILQfNGMcLLhTr 7I6g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="F/gkgw7Y"; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-85694-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-85694-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id h6-20020a635306000000b005d8505c96e1si31209pgb.423.2024.02.28.14.53.37 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Feb 2024 14:53:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-85694-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="F/gkgw7Y"; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-85694-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-85694-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 4B32FB21598 for <ouuuleilei@gmail.com>; Wed, 28 Feb 2024 20:52:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C731686258; Wed, 28 Feb 2024 20:49:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="F/gkgw7Y" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 1E9BD70043; Wed, 28 Feb 2024 20:49:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709153389; cv=none; b=rLt5856WQuBj8mieEEjC43sLL244EwMtjO1Wx4B4+zHO5h29rCNQ8dVjJq6xVWuV2yGHevkYyd+miykkLWRb+xbUWeJ6XnHZHVmWenKjYtBIsC9uku3q4KFFfsBqJb39bR8UhBjDmrKkUKdrX/P6Ch7xXiYtiB4teQYeh/zfKlw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709153389; c=relaxed/simple; bh=F4b2geX9W5KhXMqEu52b1/d3qPI5zOp6cxLtiYLUnNE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SqnoIAWR5oJNPkQss2PxqD+CUoxEOce/LfejPiVyWmVzORnozwPwlYOEY+3Byfg8NANbcMN6D2Isf6Lf+JbKxGjWQ2S1RM6fPGHiWjbaYgDUNpfjG3ElsB8g4GB69Y6E9vkJUl8eufVGP1KYfTVJmXs/2YjwVFptJvm6gFs9W6g= 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=F/gkgw7Y; arc=none smtp.client-ip=192.198.163.17 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1709153387; x=1740689387; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=F4b2geX9W5KhXMqEu52b1/d3qPI5zOp6cxLtiYLUnNE=; b=F/gkgw7YM9B+7loM2W0xpqJ6jU57HuXvleaDALSY3xUIkht9c2Uqq2if 1aCwAGj6DK5nwW7qgwzqB/VqHjhle1XB9yMxqu3/x0eiADWoVNNu3rTpm sqoeXt2/sj8R2OYBn27EIOl0d0F4FRN4FPoIAzAPHYac+E89ShrkltgIU qsOAujLc7sR2VoDzzr82BeHQTz/SyFzcQ/lP+G4RAYwNP7P4w7NKvp/bO 4mmqY/mOZWHCxcaXViIKhC7OrKpdGUGCmoYE+V2Yy6ofYV+v+DyXCBKDF cQ8fJYmxhMjhrrUIzP1S5rmCy1JB/eiFzFT0FbhCv7wz0DJ7XGyPzEN2Y g==; X-IronPort-AV: E=McAfee;i="6600,9927,10998"; a="3428771" X-IronPort-AV: E=Sophos;i="6.06,191,1705392000"; d="scan'208";a="3428771" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Feb 2024 12:49:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10998"; a="937034664" X-IronPort-AV: E=Sophos;i="6.06,191,1705392000"; d="scan'208";a="937034664" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2024 12:49:41 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id 5F749631; Wed, 28 Feb 2024 22:49:34 +0200 (EET) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Vinod Koul <vkoul@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Jonathan Cameron <Jonathan.Cameron@huawei.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Mark Brown <broonie@kernel.org>, Kees Cook <keescook@chromium.org>, linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, linux-spi@vger.kernel.org, netdev@vger.kernel.org, linux-hardening@vger.kernel.org Cc: Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, "Gustavo A. R. Silva" <gustavoars@kernel.org> Subject: [PATCH v4 7/8] net-device: Use new helpers from overflow.h in netdevice APIs Date: Wed, 28 Feb 2024 22:41:37 +0200 Message-ID: <20240228204919.3680786-8-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.43.0.rc1.1.gbec44491f096 In-Reply-To: <20240228204919.3680786-1-andriy.shevchenko@linux.intel.com> References: <20240228204919.3680786-1-andriy.shevchenko@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792181253983750251 X-GMAIL-MSGID: 1792185013851484260 |
Series |
iio: core: New macros and making use of them
|
|
Commit Message
Andy Shevchenko
Feb. 28, 2024, 8:41 p.m. UTC
We have two new helpers struct_size_with_data() and struct_data_pointer()
that we can utilize in alloc_netdev_mqs() and netdev_priv(). Do it so.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
include/linux/netdevice.h | 3 ++-
net/core/dev.c | 10 +++++-----
2 files changed, 7 insertions(+), 6 deletions(-)
Comments
On Wed, Feb 28, 2024 at 02:41:48PM -0800, Jakub Kicinski wrote: > On Wed, 28 Feb 2024 13:46:10 -0800 Kees Cook wrote: > > I really don't like hiding these trailing allocations from the compiler. > > Why can't something like this be done (totally untested): > > > > > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > > index 118c40258d07..dae6df4fb177 100644 > > --- a/include/linux/netdevice.h > > +++ b/include/linux/netdevice.h > > @@ -2475,6 +2475,8 @@ struct net_device { > > /** @page_pools: page pools created for this netdevice */ > > struct hlist_head page_pools; > > #endif > > + u32 priv_size; > > + u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); > > I like, FWIW, please submit! :) So, I found several cases where struct net_device is included in the middle of another structure, which makes my proposal more awkward. But I also don't understand why it's in the _middle_. Shouldn't it always be at the beginning (with priv stuff following it?) Quick search and examined manually: git grep 'struct net_device [a-z0-9_]*;' struct rtw89_dev struct ath10k etc. Some even have two included (?) But I still like the idea -- Gustavo has been solving these cases with having two structs, e.g.: struct net_device { ...unchanged... }; struct net_device_alloc { struct net_device dev; u32 priv_size; u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); }; And internals can use struct net_device_alloc... -Kees
On 2/28/24 18:01, Kees Cook wrote: > On Wed, Feb 28, 2024 at 02:41:48PM -0800, Jakub Kicinski wrote: >> On Wed, 28 Feb 2024 13:46:10 -0800 Kees Cook wrote: >>> I really don't like hiding these trailing allocations from the compiler. >>> Why can't something like this be done (totally untested): >>> >>> >>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h >>> index 118c40258d07..dae6df4fb177 100644 >>> --- a/include/linux/netdevice.h >>> +++ b/include/linux/netdevice.h >>> @@ -2475,6 +2475,8 @@ struct net_device { >>> /** @page_pools: page pools created for this netdevice */ >>> struct hlist_head page_pools; >>> #endif >>> + u32 priv_size; >>> + u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); >> >> I like, FWIW, please submit! :) > > So, I found several cases where struct net_device is included in the > middle of another structure, which makes my proposal more awkward. But I > also don't understand why it's in the _middle_. Shouldn't it always be > at the beginning (with priv stuff following it?) > Quick search and examined manually: git grep 'struct net_device [a-z0-9_]*;' > > struct rtw89_dev > struct ath10k > etc. > > Some even have two included (?) > > But I still like the idea -- Gustavo has been solving these cases with > having two structs, e.g.: > > struct net_device { > ...unchanged... > }; > > struct net_device_alloc { > struct net_device dev; > u32 priv_size; > u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); > }; > > And internals can use struct net_device_alloc... Yep, we should really consider going with the above, otherwise we would have to do something like the following, to avoid having the flexible-array member nested in the middle of other structs: struct net_device { struct_group_tagged(net_device_hdr, hdr, ... u32 priv_size; ); u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); } We are grouping together the members in `struct net_device`, except the flexible-array member, into a tagged `struct net_device_hdr`. This allows us to exclude the flex array from its inclusion in any other struct that contains `struct net_device` as a member without having to create a completely separate struct definition. And let's take as example `struct hfi1_netdev_rx`, where `struct net_device` is included in the beginning: drivers/infiniband/hw/hfi1/netdev.h: struct hfi1_netdev_rx { - struct net_device rx_napi; + struct net_device_hdr rx_napi; struct hfi1_devdata *dd; struct hfi1_netdev_rxq *rxq; int num_rx_q; int rmt_start; struct xarray dev_tbl; /* count of enabled napi polls */ atomic_t enabled; /* count of netdevs on top */ atomic_t netdevs; }; Of course we would also have to update the code that access `struct net_device` members through `rx_napi` in `struct hfi1_netdev_rx`. I'm currently working on the above solution for all the cases where having two separate structs is not currently feasible. And with that we are looking to enable `-Wflex-array-member-not-at-end` So, if we can prevent this from the beginning it'd be really great. :) -- Gustavo
On Wed, 28 Feb 2024 16:01:49 -0800 Kees Cook wrote: > So, I found several cases where struct net_device is included in the > middle of another structure, which makes my proposal more awkward. But I > also don't understand why it's in the _middle_. Shouldn't it always be > at the beginning (with priv stuff following it?) > Quick search and examined manually: git grep 'struct net_device [a-z0-9_]*;' > > struct rtw89_dev > struct ath10k > etc. Ugh, yes, the (ab)use of NAPI. > Some even have two included (?) And some seem to be cargo-culted from out-of-tree code and are unused :S > But I still like the idea -- Gustavo has been solving these cases with > having two structs, e.g.: > > struct net_device { > ...unchanged... > }; > > struct net_device_alloc { > struct net_device dev; > u32 priv_size; > u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); > }; > > And internals can use struct net_device_alloc... That's... less pretty. I'd rather push the ugly into the questionable users. Make them either allocate the netdev dynamically and store a pointer, or move the netdev to the end of the struct. But yeah, that's a bit of a cleanup :(
On Wed, 28 Feb 2024 18:49:25 -0600 Gustavo A. R. Silva wrote: > struct net_device { > struct_group_tagged(net_device_hdr, hdr, > ... > u32 priv_size; > ); > u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); > } No, no, that's not happening.
On 2/28/24 18:57, Jakub Kicinski wrote: > On Wed, 28 Feb 2024 18:49:25 -0600 Gustavo A. R. Silva wrote: >> struct net_device { >> struct_group_tagged(net_device_hdr, hdr, >> ... >> u32 priv_size; >> ); >> u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); >> } > > No, no, that's not happening. Thanks, one less flex-struct to change. :)
On Wed, 28 Feb 2024 19:03:12 -0600 Gustavo A. R. Silva wrote: > On 2/28/24 18:57, Jakub Kicinski wrote: > > On Wed, 28 Feb 2024 18:49:25 -0600 Gustavo A. R. Silva wrote: > >> struct net_device { > >> struct_group_tagged(net_device_hdr, hdr, > >> ... > >> u32 priv_size; > >> ); > >> u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); > >> } > > > > No, no, that's not happening. > > Thanks, one less flex-struct to change. :) I like the flex struct. I don't like struct group around a 360LoC declaration just to avoid having to fix up a handful of users.
On 2/28/24 19:15, Jakub Kicinski wrote: > On Wed, 28 Feb 2024 19:03:12 -0600 Gustavo A. R. Silva wrote: >> On 2/28/24 18:57, Jakub Kicinski wrote: >>> On Wed, 28 Feb 2024 18:49:25 -0600 Gustavo A. R. Silva wrote: >>>> struct net_device { >>>> struct_group_tagged(net_device_hdr, hdr, >>>> ... >>>> u32 priv_size; >>>> ); >>>> u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); >>>> } >>> >>> No, no, that's not happening. >> >> Thanks, one less flex-struct to change. :) > > I like the flex struct. > I don't like struct group around a 360LoC declaration just to avoid > having to fix up a handful of users. That's what I mean. If we can prevent the flex array ending up in the middle of a struct by any means, then I wouldn't have to change the flex struct. -- Gustavo
On Wed, Feb 28, 2024 at 04:01:49PM -0800, Kees Cook wrote: > On Wed, Feb 28, 2024 at 02:41:48PM -0800, Jakub Kicinski wrote: > > On Wed, 28 Feb 2024 13:46:10 -0800 Kees Cook wrote: .. > But I still like the idea -- Gustavo has been solving these cases with > having two structs, e.g.: > > struct net_device { > ...unchanged... > }; > > struct net_device_alloc { > struct net_device dev; > u32 priv_size; > u8 priv_data[] __counted_by(priv_size) __aligned(NETDEV_ALIGN); > }; > > And internals can use struct net_device_alloc... I just realized that I made same approach in f6d7f050e258 ("spi: Don't use flexible array in struct spi_message definition") 75e308ffc4f0 ("spi: Use struct_size() helper")
On Wed, Feb 28, 2024 at 04:56:09PM -0800, Jakub Kicinski wrote: > On Wed, 28 Feb 2024 16:01:49 -0800 Kees Cook wrote: > > So, I found several cases where struct net_device is included in the > > middle of another structure, which makes my proposal more awkward. But I > > also don't understand why it's in the _middle_. Shouldn't it always be > > at the beginning (with priv stuff following it?) > > Quick search and examined manually: git grep 'struct net_device [a-z0-9_]*;' > > > > struct rtw89_dev > > struct ath10k > > etc. > > Ugh, yes, the (ab)use of NAPI. > > > Some even have two included (?) > > And some seem to be cargo-culted from out-of-tree code and are unused :S Ah, which can I remove? > That's... less pretty. I'd rather push the ugly into the questionable > users. Make them either allocate the netdev dynamically and store > a pointer, or move the netdev to the end of the struct. > > But yeah, that's a bit of a cleanup :( So far, it's not too bad. I'm doing some test builds now. As a further aside, this code: struct net_device *dev; ... struct net_device *p; ... /* ensure 32-byte alignment of whole construct */ alloc_size += NETDEV_ALIGN - 1; p = kvzalloc(alloc_size, GFP_KERNEL_ACCOUNT | __GFP_RETRY_MAYFAIL); ... dev = PTR_ALIGN(p, NETDEV_ALIGN); Really screams for a dynamic-sized (bucketed) kmem_cache_alloc API. Alignment constraints can be described in a regular kmem_cache allocator (rather than this open-coded version). I've been intending to build that for struct msg_msg for a while now, and here's another user. :) -Kees
On Thu, 29 Feb 2024 11:08:58 -0800 Kees Cook wrote: > > And some seem to be cargo-culted from out-of-tree code and are unused :S > > Ah, which can I remove? The one in igc.h does not seem to be referenced by anything in the igc directory. Pretty sure it's unused. > As a further aside, this code: > > struct net_device *dev; > ... > struct net_device *p; > ... > /* ensure 32-byte alignment of whole construct */ > alloc_size += NETDEV_ALIGN - 1; > p = kvzalloc(alloc_size, GFP_KERNEL_ACCOUNT | __GFP_RETRY_MAYFAIL); > ... > dev = PTR_ALIGN(p, NETDEV_ALIGN); > > Really screams for a dynamic-sized (bucketed) kmem_cache_alloc > API. Alignment constraints can be described in a regular kmem_cache > allocator (rather than this open-coded version). I've been intending to > build that for struct msg_msg for a while now, and here's another user. :) TBH I'm not sure why we align it :S NETDEV_ALIGN is 32B so maybe some old cache aligning thing?
On Thu, Feb 29, 2024 at 11:37:06AM -0800, Jakub Kicinski wrote: > On Thu, 29 Feb 2024 11:08:58 -0800 Kees Cook wrote: > > > And some seem to be cargo-culted from out-of-tree code and are unused :S > > > > Ah, which can I remove? > > The one in igc.h does not seem to be referenced by anything in the igc > directory. Pretty sure it's unused. I'll double check. After trying to do a few conversions I really hit stuff I didn't like, so I took a slightly different approach in the patch I sent.
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index c41019f34179..d046dca18854 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -25,6 +25,7 @@ #include <linux/bug.h> #include <linux/delay.h> #include <linux/atomic.h> +#include <linux/overflow.h> #include <linux/prefetch.h> #include <asm/cache.h> #include <asm/byteorder.h> @@ -2668,7 +2669,7 @@ void dev_net_set(struct net_device *dev, struct net *net) */ static inline void *netdev_priv(const struct net_device *dev) { - return (char *)dev + ALIGN(sizeof(struct net_device), NETDEV_ALIGN); + return struct_data_pointer(dev, NETDEV_ALIGN); } /* Set the sysfs physical device reference for the network logical device diff --git a/net/core/dev.c b/net/core/dev.c index 69c3e3613372..80b765bb8ba2 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -10859,12 +10859,12 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name, return NULL; } - alloc_size = sizeof(struct net_device); - if (sizeof_priv) { + if (sizeof_priv) /* ensure 32-byte alignment of private area */ - alloc_size = ALIGN(alloc_size, NETDEV_ALIGN); - alloc_size += sizeof_priv; - } + alloc_size = struct_size_with_data(p, NETDEV_ALIGN, sizeof_priv); + else + alloc_size = sizeof(struct net_device); + /* ensure 32-byte alignment of whole construct */ alloc_size += NETDEV_ALIGN - 1;