Re: [PATCH] iio: core: fix uninitialized data in debugfs
Jonathan Cameron <[email protected]>
| Newsgroups | org.kernel.vger.kernel-janitors,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260526192141.542015a9@jic23-huawei> |
On Mon, 25 May 2026 15:08:14 -0500 Maxwell Doose <[email protected]> wrote: > On Mon, May 25, 2026 at 11:13 AM Dan Carpenter <[email protected]> wrote: > > > > On Mon, May 25, 2026 at 08:17:28AM -0500, Maxwell Doose wrote: > > > Hi Dan, > > > > > > On Mon, May 25, 2026 at 2:19 AM Dan Carpenter <[email protected]> wrote: > > > > > > > > If *ppos is non-zero then simple_write_to_buffer() will not initialize > > > > the start of buf[]. Non zero values for *ppos aren't going to work > > > > anyway. Test for them at the start of the function and return -EINVAL. > > > > > > > > Fixes: 6d5dd486c715 ("iio: core: make use of simple_write_to_buffer()") > > > > Signed-off-by: Dan Carpenter <[email protected]> > > > > --- > > > > The original copy_from_user() code was better: > > > > https://staticthinking.wordpress.com/2026/05/23/simple_write_to_buffer-is-complicated/ > > > > --- > > > > drivers/iio/industrialio-core.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > Codewise looks good but often times people will prefer > > > > > > if (*ppos || count >= sizeof(buf)) > > > > > > over > > > > > > if (*ppos != 0 || count >= sizeof(buf)) > > > > In this context, I feel like either is acceptable since zero > > represents the number zero. I have a blog about that which I have > > been trying to promote. #SEO > > > > https://staticthinking.wordpress.com/2024/02/20/when-to-use-0/ > > > > Interesting article, and I do agree that either is appropriate, just > wanted to give you a heads up in case Jonathan or Andy ask you to > change it. > > best regards, > max > Applied to the fixes-togreg branch of iio.git and marked for stable. Thanks, Jonathan > > > > > > > > Regardless, > > > > > > Reviewed-by: Maxwell Doose <[email protected]> > > > > > > > Thanks. And you're other comments with regards to -EINVAL and > > -ENOSPC are obviously correct. > > > > regards, > > dan carpenter > >