linux-kernel - Re: [PATCH v4 3/3] iio: adc: ltc2497: reorder struct members to fix memory holes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250816115348.1fba0a7b@jic23-huawei>
Date: Sat, 16 Aug 2025 11:53:48 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Yusuf Alper Bilgin <y.alperbilgin@...il.com>, Lars-Peter Clausen
 <lars@...afoo.de>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>, David Lechner
 <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy
 Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Liam
 Beguin <liambeguin@...il.com>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 3/3] iio: adc: ltc2497: reorder struct members to fix
 memory holes

On Fri, 15 Aug 2025 12:02:04 +0200
Yusuf Alper Bilgin <y.alperbilgin@...il.com> wrote:

> Reorder members in the `ltc2497_chip_info` and `ltc2497core_driverdata`
> structs to eliminate memory holes identified by the `pahole` tool.
> 
> Confirm via the `bloat-o-meter` that this change has no significant
> impact on the final code size:
> 
> | Object File     | Total Size Change |
> |-----------------|-------------------|
> | ltc2497-core.o  | 0 (0.00%)         |
> | ltc2497.o       | +2 (+0.10%)       |
> | ltc2496.o       | 0 (0.00%)         |
> 
> Signed-off-by: Yusuf Alper Bilgin <y.alperbilgin@...il.com>

whilst I know Andy is a fan of this stuff, I'm not convinced it is worth
the churn in this particular case. 

The driverdata is allocated via iio_priv() so has a bunch of additional
alignment rules applied and is on the end of another larger allocation.
I suspect that completely hides the advantages in closing the holes up.

The chip_info one is a bit more convincing as that's static const stuff and
maybe it ends up packing a little better.

Anyhow, let us see what Andy thinks.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/ltc2497.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/ltc2497.h b/drivers/iio/adc/ltc2497.h
> index dfe2d5c30017adeb3f17e57fc5bf1e0e792ff30f..48e9f74870ab489b5df6e69a39446610c6a72b93 100644
> --- a/drivers/iio/adc/ltc2497.h
> +++ b/drivers/iio/adc/ltc2497.h
> @@ -5,8 +5,8 @@
>  #define LTC2497_CONVERSION_TIME_MS	150ULL
>  
>  struct ltc2497_chip_info {
> -	u32 resolution;
>  	const char *name;
> +	u32 resolution;
>  	/*
>  	 * Represents the datasheet constant from the temperature formula:
>  	 * T_Kelvin = (DATAOUT * Vref) / temp_scale, where Vref is in Volts.
> @@ -20,15 +20,15 @@ struct ltc2497_chip_info {
>  };
>  
>  struct ltc2497core_driverdata {
> -	struct regulator *ref;
> -	ktime_t	time_prev;
>  	/* lock to protect against multiple access to the device */
>  	struct mutex lock;
> +	struct regulator *ref;
> +	ktime_t	time_prev;
>  	const struct ltc2497_chip_info	*chip_info;
> -	u8 addr_prev;
>  	int (*result_and_measure)(struct ltc2497core_driverdata *ddata,
>  				  u8 address, int *val);
>  	enum iio_chan_type chan_type_prev;
> +	u8 addr_prev;
>  };
>  
>  int ltc2497core_probe(struct device *dev, struct iio_dev *indio_dev);
>