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

Andy Shevchenko <[email protected]>
Newsgroups org.kernel.vger.kernel-janitors,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel
Organization Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo
Message-ID <[email protected]>
On Thu, Jun 04, 2026 at 10:45:36AM +0300, Dan Carpenter wrote:
> On Thu, Jun 04, 2026 at 10:30:34AM +0300, Andy Shevchenko wrote:
> > On Tue, May 26, 2026 at 07:19:46PM +0100, Jonathan Cameron wrote:
> > > On Mon, 25 May 2026 08:20:31 -0500
> > > Maxwell Doose <[email protected]> wrote:
> > > > On Mon, May 25, 2026 at 2:17 AM Dan Carpenter <[email protected]> wrote:
> > > > >
> > > > > If the *ppos value is non-zero then simple_write_to_buffer() will not
> > > > > initialize the start of the buf[] buffer.  Non-zero ppos values aren't
> > > > > going to work at all.  Check for that at the start of the function and
> > > > > return -EINVAL.
> > > > 
> > > > Commit message is incorrect, it looks like you're returning -ENOSPC here...
> > > Tweaked and applied to the fixes-togreg branch of iio.git + marked for stable.
> > 
> > I was stumbled over these patches by Dan. Since the file_operations for the code
> > in question do not define .llseek, the seek is not supported and will return
> > -ESPIPE. I'm not sure why we have these patches to begin with. Dan, can you
> > elaborate on the case where the *ppos is not 0, please?

> The simple_write_to_buffer() will update *ppos so partial writes are
> supported in that way.

Can you show the step-by-step scenario? I'm still fail to see how it may be happen.
Is it somewhere inside the kernel loop? Which VFS function(s) is responsible for
that in such a case?

-- 
With Best Regards,
Andy Shevchenko
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.