From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock, to protect potential concurrent access to the completion callback during a conversion. Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> --- drivers/iio/adc/exynos_adc.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c index 7d23b6c33284..6a49f8dfab22 100644 --- a/drivers/iio/adc/exynos_adc.c +++ b/drivers/iio/adc/exynos_adc.c @@ -132,6 +132,8 @@ struct exynos_adc { struct completion completion; + struct mutex lock; + u32 value; unsigned int version; @@ -542,7 +544,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, return -EINVAL; } - mutex_lock(&indio_dev->mlock); + mutex_lock(&info->lock); reinit_completion(&info->completion); /* Select the channel to be used and Trigger conversion */ @@ -562,7 +564,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, ret = IIO_VAL_INT; } - mutex_unlock(&indio_dev->mlock); + mutex_unlock(&info->lock); return ret; } @@ -573,7 +575,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) unsigned long timeout; int ret; - mutex_lock(&indio_dev->mlock); + mutex_lock(&info->lock); info->read_ts = true; reinit_completion(&info->completion); @@ -598,7 +600,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) } info->read_ts = false; - mutex_unlock(&indio_dev->mlock); + mutex_unlock(&info->lock); return ret; } @@ -872,6 +874,8 @@ static int exynos_adc_probe(struct platform_device *pdev) indio_dev->channels = exynos_adc_iio_channels; indio_dev->num_channels = info->data->num_channels; + mutex_init(&info->lock); + ret = request_irq(info->irq, exynos_adc_isr, 0, dev_name(&pdev->dev), info); if (ret < 0) { -- 2.25.1
On Wed, Aug 26, 2020 at 04:22:03PM +0300, Alexandru Ardelean wrote: > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > As part of the general cleanup of indio_dev->mlock, this change replaces > it with a local lock, to protect potential concurrent access to the > completion callback during a conversion. I don't know the bigger picture (and no links here for general cleanup) but I assume it is part of wider work and that mlock is unwanted. In such case: Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> If it is part of some bigger work, please put a link to lore.kernel.org under separators ---, so everyone can get the context. Best regards, Krzysztof > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> > --- > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) >
On Thu, Aug 27, 2020 at 9:57 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On Wed, Aug 26, 2020 at 04:22:03PM +0300, Alexandru Ardelean wrote: > > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > > > As part of the general cleanup of indio_dev->mlock, this change replaces > > it with a local lock, to protect potential concurrent access to the > > completion callback during a conversion. > > I don't know the bigger picture (and no links here for general cleanup) > but I assume it is part of wider work and that mlock is unwanted. In > such case: > > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> > > If it is part of some bigger work, please put a link to lore.kernel.org > under separators ---, so everyone can get the context. Will keep that in mind. I am not sure if there is a lore.kernel.org link that's easy to find for a discussion on this topic, maybe I can describe it here and use the link [from this later]. This was something that popped up during reviews we got from Jonathan [or others], saying "please don't use indio_dev->mlock, that is an IIO framework lock, and an IIO driver should not use it". Reasons include [and some may be repeated a bit]: - this could cause a deadlock if the IIO framework holds this lock and an IIO driver also tries to get a hold of this lock - similar to the previous point, this mlock is taken by iio_device_claim_direct_mode() and released by iio_device_release_direct_mode() ; which means that mlock aims to become more of an IIO framework lock, than a general usage lock; - this wasn't policed/reviewed intensely in the older driver [a few years ago], but has become a point in recent reviews; - if we want to develop/enhance the IIO framework, some elements like this need to be taken care of, as more drivers get added and more complexity gets added; - there is an element of fairness [obviously], where someone writing a new IIO driver, takes an older one as example, and gets hit on the review; the person feels they did a good job in mimicking the old driver; their feeling is correct; the IIO framework should provide good references and/or cleanup existing drivers; - same as the previous point, we don't want to keep telling people writing new IIO drivers [and starting out with IIO] to "not use mlock [because it was copied from an old driver]"; it's more/needless review work > > > Best regards, > Krzysztof > > > > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> > > --- > > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > > 1 file changed, 8 insertions(+), 4 deletions(-) > >
On Thu, 27 Aug 2020 11:53:44 +0300 Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > On Thu, Aug 27, 2020 at 9:57 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On Wed, Aug 26, 2020 at 04:22:03PM +0300, Alexandru Ardelean wrote: > > > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > > > > > As part of the general cleanup of indio_dev->mlock, this change replaces > > > it with a local lock, to protect potential concurrent access to the > > > completion callback during a conversion. > > > > I don't know the bigger picture (and no links here for general cleanup) > > but I assume it is part of wider work and that mlock is unwanted. In > > such case: > > > > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> > > > > If it is part of some bigger work, please put a link to lore.kernel.org > > under separators ---, so everyone can get the context. > > Will keep that in mind. > I am not sure if there is a lore.kernel.org link that's easy to find > for a discussion on this topic, maybe I can describe it here and use > the link [from this later]. > > This was something that popped up during reviews we got from Jonathan > [or others], saying "please don't use indio_dev->mlock, that is an IIO > framework lock, and an IIO driver should not use it". Shortest one is the docs for that lock say don't use it directly in a driver :) https://elixir.bootlin.com/linux/latest/source/include/linux/iio/iio.h#L495 > Reasons include [and some may be repeated a bit]: > - this could cause a deadlock if the IIO framework holds this lock and > an IIO driver also tries to get a hold of this lock > - similar to the previous point, this mlock is taken by > iio_device_claim_direct_mode() and released by > iio_device_release_direct_mode() ; which means that mlock aims to > become more of an IIO framework lock, than a general usage lock; > - this wasn't policed/reviewed intensely in the older driver [a few > years ago], but has become a point in recent reviews; > - if we want to develop/enhance the IIO framework, some elements like > this need to be taken care of, as more drivers get added and more > complexity gets added; One side note here is we want to make all this [INTERN] state in struct iio_dev opaque to drivers. It'll take a while as the boundary gets crossed in various drivers. > - there is an element of fairness [obviously], where someone writing a > new IIO driver, takes an older one as example, and gets hit on the > review; the person feels they did a good job in mimicking the old > driver; their feeling is correct; the IIO framework should provide > good references and/or cleanup existing drivers; > - same as the previous point, we don't want to keep telling people > writing new IIO drivers [and starting out with IIO] to "not use mlock > [because it was copied from an old driver]"; it's more/needless review > work Good explanation. Thanks, Jonathan > > > > > > > > Best regards, > > Krzysztof > > > > > > > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> > > > --- > > > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > >
On Wed, 26 Aug 2020 16:22:03 +0300 Alexandru Ardelean <alexandru.ardelean@analog.com> wrote: > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > As part of the general cleanup of indio_dev->mlock, this change replaces > it with a local lock, to protect potential concurrent access to the > completion callback during a conversion. > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Same comment as the other one about needing lock scope to be documented. Otherwise looks good. I thought we only had complicated uses of this left, but clearly not :) Jonathan > --- > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c > index 7d23b6c33284..6a49f8dfab22 100644 > --- a/drivers/iio/adc/exynos_adc.c > +++ b/drivers/iio/adc/exynos_adc.c > @@ -132,6 +132,8 @@ struct exynos_adc { > > struct completion completion; > > + struct mutex lock; > + > u32 value; > unsigned int version; > > @@ -542,7 +544,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, > return -EINVAL; > } > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&info->lock); > reinit_completion(&info->completion); > > /* Select the channel to be used and Trigger conversion */ > @@ -562,7 +564,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, > ret = IIO_VAL_INT; > } > > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&info->lock); > > return ret; > } > @@ -573,7 +575,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) > unsigned long timeout; > int ret; > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&info->lock); > info->read_ts = true; > > reinit_completion(&info->completion); > @@ -598,7 +600,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) > } > > info->read_ts = false; > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&info->lock); > > return ret; > } > @@ -872,6 +874,8 @@ static int exynos_adc_probe(struct platform_device *pdev) > indio_dev->channels = exynos_adc_iio_channels; > indio_dev->num_channels = info->data->num_channels; > > + mutex_init(&info->lock); > + > ret = request_irq(info->irq, exynos_adc_isr, > 0, dev_name(&pdev->dev), info); > if (ret < 0) {
From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock, to protect potential concurrent access to the completion callback during a conversion. This is part of a bigger cleanup. Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/ Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> --- drivers/iio/adc/exynos_adc.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c index 20477b249f2a..99f4404e9fd1 100644 --- a/drivers/iio/adc/exynos_adc.c +++ b/drivers/iio/adc/exynos_adc.c @@ -138,6 +138,16 @@ struct exynos_adc { bool read_ts; u32 ts_x; u32 ts_y; + + /* + * Lock to protect from potential concurrent access to the + * completion callback during a manual conversion. For this driver + * a wait-callback is used to wait for the conversion result, + * so in the meantime no other read request (or conversion start) + * must be performed, otherwise it would interfere with the + * current conversion result. + */ + struct mutex lock; }; struct exynos_adc_data { @@ -542,7 +552,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, return -EINVAL; } - mutex_lock(&indio_dev->mlock); + mutex_lock(&info->lock); reinit_completion(&info->completion); /* Select the channel to be used and Trigger conversion */ @@ -562,7 +572,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, ret = IIO_VAL_INT; } - mutex_unlock(&indio_dev->mlock); + mutex_unlock(&info->lock); return ret; } @@ -573,7 +583,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) unsigned long timeout; int ret; - mutex_lock(&indio_dev->mlock); + mutex_lock(&info->lock); info->read_ts = true; reinit_completion(&info->completion); @@ -598,7 +608,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) } info->read_ts = false; - mutex_unlock(&indio_dev->mlock); + mutex_unlock(&info->lock); return ret; } @@ -868,6 +878,8 @@ static int exynos_adc_probe(struct platform_device *pdev) indio_dev->channels = exynos_adc_iio_channels; indio_dev->num_channels = info->data->num_channels; + mutex_init(&info->lock); + ret = request_irq(info->irq, exynos_adc_isr, 0, dev_name(&pdev->dev), info); if (ret < 0) { -- 2.17.1
On Wed, 16 Sep 2020 12:31:23 +0300 Alexandru Ardelean <alexandru.ardelean@analog.com> wrote: > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > As part of the general cleanup of indio_dev->mlock, this change replaces > it with a local lock, to protect potential concurrent access to the > completion callback during a conversion. > > This is part of a bigger cleanup. > Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/ > > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > drivers/iio/adc/exynos_adc.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c > index 20477b249f2a..99f4404e9fd1 100644 > --- a/drivers/iio/adc/exynos_adc.c > +++ b/drivers/iio/adc/exynos_adc.c > @@ -138,6 +138,16 @@ struct exynos_adc { > bool read_ts; > u32 ts_x; > u32 ts_y; > + > + /* > + * Lock to protect from potential concurrent access to the > + * completion callback during a manual conversion. For this driver > + * a wait-callback is used to wait for the conversion result, > + * so in the meantime no other read request (or conversion start) > + * must be performed, otherwise it would interfere with the > + * current conversion result. > + */ > + struct mutex lock; > }; > > struct exynos_adc_data { > @@ -542,7 +552,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, > return -EINVAL; > } > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&info->lock); > reinit_completion(&info->completion); > > /* Select the channel to be used and Trigger conversion */ > @@ -562,7 +572,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, > ret = IIO_VAL_INT; > } > > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&info->lock); > > return ret; > } > @@ -573,7 +583,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) > unsigned long timeout; > int ret; > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&info->lock); > info->read_ts = true; > > reinit_completion(&info->completion); > @@ -598,7 +608,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) > } > > info->read_ts = false; > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&info->lock); > > return ret; > } > @@ -868,6 +878,8 @@ static int exynos_adc_probe(struct platform_device *pdev) > indio_dev->channels = exynos_adc_iio_channels; > indio_dev->num_channels = info->data->num_channels; > > + mutex_init(&info->lock); > + > ret = request_irq(info->irq, exynos_adc_isr, > 0, dev_name(&pdev->dev), info); > if (ret < 0) {