drivers/iio/buffer/industrialio-hw-consumer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
was using list_for_each_entry() to iterate through buffers while calling
iio_buffer_put() which can free the current buffer if refcount drops to 0.
The list_for_each_entry() loop macro then evaluates buf->head.next to
continue iteration, accessing the freed buffer.
Fix this by using list_for_each_entry_safe().
Closes:https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/iio/buffer/industrialio-hw-consumer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
index 24d7df603760..7406efefc123 100644
--- a/drivers/iio/buffer/industrialio-hw-consumer.c
+++ b/drivers/iio/buffer/industrialio-hw-consumer.c
@@ -85,7 +85,7 @@ static struct hw_consumer_buffer *iio_hw_consumer_get_buffer(
*/
struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev)
{
- struct hw_consumer_buffer *buf;
+ struct hw_consumer_buffer *buf, *n;
struct iio_hw_consumer *hwc;
struct iio_channel *chan;
int ret;
@@ -116,7 +116,7 @@ struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev)
return hwc;
err_put_buffers:
- list_for_each_entry(buf, &hwc->buffers, head)
+ list_for_each_entry_safe(buf, n, &hwc->buffers, head)
iio_buffer_put(&buf->buffer);
iio_channel_release_all(hwc->channels);
err_free_hwc:
---
base-commit: 7080e32d3f09d8688c4a87d81bdcc71f7f606b16
change-id: 20260428-iio-buf-4c8559020a54
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
On Tue, Apr 28, 2026 at 10:53:25PM +0800, Felix Gu wrote:
> In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
> was using list_for_each_entry() to iterate through buffers while calling
> iio_buffer_put() which can free the current buffer if refcount drops to 0.
> The list_for_each_entry() loop macro then evaluates buf->head.next to
> continue iteration, accessing the freed buffer.
>
> Fix this by using list_for_each_entry_safe().
>
> Closes:https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
Format is wrong, missing space.
>
Tag block should have no blank lines.
> Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
I am also wondering should we put Reported-by with the reference to AI somehow?
Jonathan, others, what are your opinions?
...
> - struct hw_consumer_buffer *buf;
> + struct hw_consumer_buffer *buf, *n;
Please, name it rather *tmp.
> {
--
With Best Regards,
Andy Shevchenko
On Tue, 28 Apr 2026 18:59:28 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Apr 28, 2026 at 10:53:25PM +0800, Felix Gu wrote:
> > In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
> > was using list_for_each_entry() to iterate through buffers while calling
> > iio_buffer_put() which can free the current buffer if refcount drops to 0.
> > The list_for_each_entry() loop macro then evaluates buf->head.next to
> > continue iteration, accessing the freed buffer.
> >
> > Fix this by using list_for_each_entry_safe().
> >
> > Closes:https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
>
> Format is wrong, missing space.
>
> >
>
> Tag block should have no blank lines.
>
> > Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
> > Signed-off-by: Felix Gu <ustc.gu@gmail.com>
>
> I am also wondering should we put Reported-by with the reference to AI somehow?
> Jonathan, others, what are your opinions?
Would be nice to do so for these - things noticed whilst reviewing a patch
type reports.
Roman (+CC), any suggestions on how to do this?
>
> ...
>
> > - struct hw_consumer_buffer *buf;
> > + struct hw_consumer_buffer *buf, *n;
>
> Please, name it rather *tmp.
>
> > {
>
> On Apr 28, 2026, at 11:26 AM, Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Tue, 28 Apr 2026 18:59:28 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
>>> On Tue, Apr 28, 2026 at 10:53:25PM +0800, Felix Gu wrote:
>>> In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code
>>> was using list_for_each_entry() to iterate through buffers while calling
>>> iio_buffer_put() which can free the current buffer if refcount drops to 0.
>>> The list_for_each_entry() loop macro then evaluates buf->head.next to
>>> continue iteration, accessing the freed buffer.
>>>
>>> Fix this by using list_for_each_entry_safe().
>>>
>>> Closes:https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com
>>
>> Format is wrong, missing space.
>>
>>>
>>
>> Tag block should have no blank lines.
>>
>>> Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support")
>>> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
>>
>> I am also wondering should we put Reported-by with the reference to AI somehow?
>> Jonathan, others, what are your opinions?
>
> Would be nice to do so for these - things noticed whilst reviewing a patch
> type reports.
>
> Roman (+CC), any suggestions on how to do this?
I appreciate when people are recognizing Sashiko, but I don’t have any strong preference.
Many engineers are using it locally before sending patches upstream, so we’ll never know
it anyway. But Reported-by/Assisted-by tags are appreciated when appropriate.
On Tue, Apr 28, 2026 at 11:34:22AM -0700, Roman Gushchin wrote: > > On Apr 28, 2026, at 11:26 AM, Jonathan Cameron <jic23@kernel.org> wrote: > > On Tue, 28 Apr 2026 18:59:28 +0300 > > Andy Shevchenko <andriy.shevchenko@intel.com> wrote: ... > >> I am also wondering should we put Reported-by with the reference to AI somehow? > >> Jonathan, others, what are your opinions? > > > > Would be nice to do so for these - things noticed whilst reviewing a patch > > type reports. > > > > Roman (+CC), any suggestions on how to do this? > > I appreciate when people are recognizing Sashiko, but I don’t have any strong > preference. Many engineers are using it locally before sending patches > upstream, so we’ll never know it anyway. But Reported-by/Assisted-by tags are > appreciated when appropriate. The problem is what to put to Reported-by as an email. For example LKP bot or syzbot have dedicated emails for that. What about Sashiko? P.S. An offtopic, how can I be email notified on the reviews done by Sashiko against my patches sent to Linux kernel project (mailing lists)? If you can add me as andy@kernel.org, I appreciate that! -- With Best Regards, Andy Shevchenko
Andy Shevchenko <andriy.shevchenko@intel.com> writes: > On Tue, Apr 28, 2026 at 11:34:22AM -0700, Roman Gushchin wrote: >> > On Apr 28, 2026, at 11:26 AM, Jonathan Cameron <jic23@kernel.org> wrote: >> > On Tue, 28 Apr 2026 18:59:28 +0300 >> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote: > > ... > >> >> I am also wondering should we put Reported-by with the reference to AI somehow? >> >> Jonathan, others, what are your opinions? >> > >> > Would be nice to do so for these - things noticed whilst reviewing a patch >> > type reports. >> > >> > Roman (+CC), any suggestions on how to do this? >> >> I appreciate when people are recognizing Sashiko, but I don’t have any strong >> preference. Many engineers are using it locally before sending patches >> upstream, so we’ll never know it anyway. But Reported-by/Assisted-by tags are >> appreciated when appropriate. > > The problem is what to put to Reported-by as an email. For example LKP bot or > syzbot have dedicated emails for that. What about Sashiko? We have sashiko-bot@kernel.org ! > > P.S. > An offtopic, how can I be email notified on the reviews done by Sashiko against > my patches sent to Linux kernel project (mailing lists)? If you can add me > as andy@kernel.org, I appreciate that! I don't have a personal opt-in at the moment, it's configurable per mailing list. The current configuration is here: https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml I generally rely on the consensus decision by corresponding maintainers. Thanks!
On Wed, Apr 29, 2026 at 05:00:08PM +0000, Roman Gushchin wrote: > Andy Shevchenko <andriy.shevchenko@intel.com> writes: > > On Tue, Apr 28, 2026 at 11:34:22AM -0700, Roman Gushchin wrote: > >> > On Apr 28, 2026, at 11:26 AM, Jonathan Cameron <jic23@kernel.org> wrote: > >> > On Tue, 28 Apr 2026 18:59:28 +0300 > >> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote: ... > >> >> I am also wondering should we put Reported-by with the reference to AI somehow? > >> >> Jonathan, others, what are your opinions? > >> > > >> > Would be nice to do so for these - things noticed whilst reviewing a patch > >> > type reports. > >> > > >> > Roman (+CC), any suggestions on how to do this? > >> > >> I appreciate when people are recognizing Sashiko, but I don’t have any strong > >> preference. Many engineers are using it locally before sending patches > >> upstream, so we’ll never know it anyway. But Reported-by/Assisted-by tags are > >> appreciated when appropriate. > > > > The problem is what to put to Reported-by as an email. For example LKP bot or > > syzbot have dedicated emails for that. What about Sashiko? > > We have sashiko-bot@kernel.org ! Good to know, thanks. > > P.S. > > An offtopic, how can I be email notified on the reviews done by Sashiko against > > my patches sent to Linux kernel project (mailing lists)? If you can add me > > as andy@kernel.org, I appreciate that! > > I don't have a personal opt-in at the moment, Whenever it appears (I hope to see it rather sooner) put me first in the list to be Cc'ed! > it's configurable per > mailing list. The current configuration is here: > https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml > > I generally rely on the consensus decision by corresponding maintainers. Noted, thanks for clarification. -- With Best Regards, Andy Shevchenko
On Tue, Apr 28, 2026 at 06:59:28PM +0300, Andy Shevchenko wrote: > On Tue, Apr 28, 2026 at 10:53:25PM +0800, Felix Gu wrote: ... > > - struct hw_consumer_buffer *buf; > > + struct hw_consumer_buffer *buf, *n; > > Please, name it rather *tmp. Or *next. The point is that most of the one-letter variables are kinda reserved either for integers (like loop variables, local size or number holders, or some char * pointers). -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.