Quoting Andy Shevchenko (2024-10-30 15:47:50)
> On Mon, Oct 21, 2024 at 02:54:15PM +0200, Matteo Martelli wrote:
> > Consumers need to call the producer's read_avail_release_resource()
> > callback after reading producer's available info. To avoid a race
> > condition with the producer unregistration, change inkern
> > iio_channel_read_avail() so that it copies the available info from the
> > producer and immediately calls its release callback with info_exists
> > locked.
> >
> > Also, modify the users of iio_read_avail_channel_raw() and
> > iio_read_avail_channel_attribute() to free the copied available buffers
> > after calling these functions. To let users free the copied buffer with
> > a cleanup pattern, also add a iio_read_avail_channel_attr_retvals()
> > consumer helper that is equivalent to iio_read_avail_channel_attribute()
> > but stores the available values in the returned variable.
>
> ...
>
> > +static void dpot_dac_read_avail_release_res(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + const int *vals, long mask)
> > +{
> > + kfree(vals);
> > +}
> > +
> > static int dpot_dac_write_raw(struct iio_dev *indio_dev,
> > struct iio_chan_spec const *chan,
> > int val, int val2, long mask)
> > @@ -125,6 +132,7 @@ static int dpot_dac_write_raw(struct iio_dev *indio_dev,
> > static const struct iio_info dpot_dac_info = {
> > .read_raw = dpot_dac_read_raw,
> > .read_avail = dpot_dac_read_avail,
> > + .read_avail_release_resource = dpot_dac_read_avail_release_res,
> > .write_raw = dpot_dac_write_raw,
> > };
>
> I have a problem with this approach. The issue is that we allocate
> memory in one place and must clear it in another. This is not well
> designed thingy in my opinion. I was thinking a bit of the solution and
> at least these two comes to my mind:
>
> 1) having a special callback for .read_avail_with_copy (choose better
> name) that will dump the data to the intermediate buffer and clean it
> after all;
>
> 2) introduce a new type (or bit there), like IIO_AVAIL_LIST_ALLOC.
Could you elaborate more about these potential solutions? Maybe with some
usage examples?
If I get it correctly, in both cases you are suggesting to pass ownership
of the vals buffer to the caller, iio_read_channel_info_avail() in this
case, so that it would take care of freeing the buffer after calling
iio_format_after_*(). We considered this approach during an initial
discussion with Jonathan (see read_avail_ext() in [1]), where he suggested
to let the driver keep the release control through a callback for two
reasons:
1) Apparently it's a bad pattern to pass the buffer ownership to the core,
maybe Jonathan can elaborate why? The risk I can think of is that the driver
could still keep the buffer copy in its private data after giving it away,
resulting in fact in a double ownership. However I think it would be clear
enough in this case that the copy should be handled by the caller, or maybe
not?
2) Some driver might want to avoid allocating a new copy of a big table if
the race does not occur (e.g. with additional checks on buffer access
code) and thus wouldn't call a free() in the release callback.
>
> In any case it looks fragile and not scalable. I propose to drop this
> and think again.
I see your concerns, I am open to reconsider this in case we come up with
better solution after addressing the points above.
> Yes, yes, I'm fully aware about the problem you are trying to solve and
> agree on the report, I think this solution is not good enough.
>
> --
> With Best Regards,
> Andy Shevchenko
>
[1]: https://lore.kernel.org/linux-iio/20240729211100.0d602d6e@jic23-huawei/
Best regards,
Matteo Martelli
