Re: [PATCH] iio: backend: fix uninitialized data in debugfs

From: Dan Carpenter

Date: Wed Jun 10 2026 - 08:19:41 EST


On Wed, Jun 10, 2026 at 01:41:49PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 09, 2026 at 09:19:54AM +0300, Dan Carpenter wrote:
> > On Fri, Jun 05, 2026 at 11:28:18AM +0300, Andy Shevchenko wrote:
> > > On Fri, Jun 05, 2026 at 09:12:38AM +0300, Dan Carpenter wrote:
> > > > On Thu, Jun 04, 2026 at 05:55:08PM +0300, Andy Shevchenko wrote:
> > > > > On Thu, Jun 04, 2026 at 01:42:11PM +0300, Dan Carpenter wrote:
> > > > > > On Thu, Jun 04, 2026 at 01:38:50PM +0300, Dan Carpenter wrote:
> > > > > > > 168 ret = sscanf(buf, "%i %i", &back->cached_reg_addr, &val);
> > > > > > > ^^^
> > > > > > > Uninitialized variable.
> > > > > >
> > > > > > s/variable/data/.
> > > > >
> > > > > With what I asked in the previous reply and what you explained there
> > > > > (thanks, btw!) I still think your patches are not fully correct. They
> > > > > will require to atomically write all or nothing. If we want support
> > > > > partial writes we need to go with that differently (reset ppos when
> > > > > we got enough or more than enough data).
> > > >
> > > > Requiring writes to syfs and debugfs be atomic is pretty normal and
> > > > works well in practice. These are very small writes.
> > >
> > > Perhaps. In any case your patch will break existing partial writes, right?
> >
> > partial writes never worked
>
> I don't get this. Does it mean it never worked at all, or in this particular case?
> Also "never worked" means the same issue you pointed out (uninitialised buffer) or
> something else?

I mean in this case. The patch doesn't introduce a regression because
partial writes were already broken.

regards,
dan carpenter