Re: [PATCH 0/7] hwmon: zero-initialization instead of memset

[Manish Baing]

Hi Guenter,
That makes complete sense.
I understand the risks of leaving padding bytes uninitialized now.
Thank you for taking the time to explain the rationale! it is a very
valuable learning experience.

Thanks & Regards
Manish Baing

On Fri, Jun 26, 2026 at 7:29 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> On 6/25/26 09:04, Manish Baing wrote:
> > Hi Guenter,
> >
> > Thank you for catching the struct padding risk. You are completely
> > right—Patch 7 (it87.c) would trigger a KMSAN uninit-value warning due
> > to the kmemdup() copy in platform_device_add_data(). I will drop that
> > patch entirely.
> >
> > I have audited the other six drivers in this series and verified that
> > their variables are never passed to memcmp(), kmemdup(), or hashed, so
> > the = {} initialization is perfectly safe there.
> >
> > While this does not fix an active bug, the goal is to follow a cleanup
> > pattern  recently discussed for the IIO subsystem [1],[2]
> > 1.Better performance: It removes the need for an extra function call.
> > Instead, the compiler clears the memory directly and more efficiently.
> > 2.Safer code: It prevents accidental memory leaks that happen when
> > developers make a typo in the sizeof() calculation.
> >
> > Would you be open to a v2 that includes just the six safe patches to
> > modernize these initializations?
> >
>
> Not really. I would not mind if there was a safe means to initialize
> a data structure without risking holes and without memset(). In the
> absence of that I rather play safe than sorry (and apparently we have
> a different opinion about the definition of "safe").
>
> Guenter
>
> > [1] https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@xxxxxxxxxxxx/
> > [2] https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/
> >
> > Thanks for your time and guidance,
> >
> > Thanks & Regards,
> > Manish
> >
> > On Sun, Jun 7, 2026 at 9:42 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> >>
> >> On 5/30/26 15:13, Manish Baing wrote:
> >>> Hi all,
> >>>
> >>> This patch series cleans up memory initialization across several
> >>> hardware monitoring (hwmon) drivers by replacing explicit memset() calls
> >>> with empty brace initialization (= {}).
> >>>
> >>> Following similar cleanups in the IIO subsystem [1], this series updates
> >>> these drivers to stop using memset() for stack memory initialization.
> >>> As noted in those discussions [2], using empty brace initialization (= {})
> >>> is the preferred approach.
> >>>
> >>> Beyond simple replacements, a few drivers (nct6683, nct6775-platform, it87)
> >>> were using memset() inside a for-loop. To fix this, the variable
> >>> declarationwas moved directly inside the loop and zero-initialized there.
> >>> This safely resets the data on every iteration and makes the code much
> >>> cleaner.
> >>>
> >>> Testing:
> >>> - Compiled all modified files using `make W=1` with no warnings or errors.
> >>>
> >>> [1]: https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@xxxxxxxxxxxx/
> >>> [2]: https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/
> >>
> >> That discussion does not fully address a problem I had seen previously,
> >> where {} did _not_ zero-fill all holes, causing subsequent memcmp()
> >> failures on affected data structures. It took a lot a lot of debugging
> >> to find and fix that problem. Given that, I am not inclined to accept
> >> this series unless someone convinces me that it fixes an actual problem
> >> _and_ that each and every instance of the changes is not used in a
> >> subsequent memcmp().
> >>
> >> Guenter
> >>
> >
>