Message-ID: <20241030203050.5cdf3450@jic23-huawei>
Date: Wed, 30 Oct 2024 20:30:50 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Matteo Martelli <matteomartelli3@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, Lars-Peter Clausen
 <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>,
 Alisa-Dariana Roman <alisa.roman@...log.com>, Christian Eggers
 <ceggers@...i.de>, Peter Rosin <peda@...ntia.se>, Paul Cercueil
 <paul@...pouillou.net>, Sebastian Reichel <sre@...nel.org>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mips@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v5 2/5] iio: consumers: copy/release available info from
 producer to fix race

On Wed, 30 Oct 2024 19:23:21 +0100
Matteo Martelli <matteomartelli3@...il.com> wrote:

> 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?
Mostly the lack of desire to have to copy for the 95% of cases where it's
not needed and that it prevents any optimization like you mention.

Jonathan
> 
> 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

Powered by blists - more mailing lists