Re: [PATCH] iio: buffer: Fix wait_queue not being removed

["Nuno Sá" <noname.nuno@gmail.com>]

On Sun, 2026-02-22 at 12:37 +0000, Jonathan Cameron wrote:
> On Sat, 21 Feb 2026 15:27:42 -0600
> David Lechner <dlechner@baylibre.com> wrote:
> 
> > On 2/16/26 7:24 AM, Nuno Sá via B4 Relay wrote:
> > > From: Nuno Sá <nuno.sa@analog.com>
> > > 
> > > In the edge case where the IIO device is unregistered while we're
> > > buffering, we were directly returning an error without removing the wait
> > > queue. Instead, set 'ret' and break out of the loop.
> > > 
> > > Fixes: 9eeee3b0bf19 ("iio: Add output buffer support")
> > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > ---  
> > Reviewed-by: David Lechner <dlechner@baylibre.com>
> > 
> This brings the code inline with the near identical
> flow in the read path.
> 
> It's been a while since I last looked at the locking / tear
> down (what that ->info check is all about).  I'll add actually

Yeah not sure if you remember but I already said this a couple of times. In the buffer
paths I'm not convinced the check we have is enough. Still very open to races AFAICT.
I have it in my list to try and trigger and actual issue/dump on that path so it's not just
theory. Already asked the bot to write some stressor/test code :).

> documenting all the corner cases to the todo list as IIRC
> there are some non obvious ordering constraints.  IIRC,
> in the buffer paths, it is fairly straight forward
> as it's just an optimization to avoid queuing or draining
> data when the device is going down - nothing about the buffers
> themselves involves interacting directly with the hardware.
> 
> Applied to the fixes-togreg branch of iio.git and marked
> for stable.
> 

BTW, I just realized we now have an Assisted-by: tag for getting help from AI. I should
say that this bug was identified by Claude code (when bulding the stressor test app I 
mentioned above :)). So, maybe (or can we Reported by: Claude Code?!!):

Assisted-by: Claude Code

- Nuno Sá