Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 6 Jun 2019 15:56:37 +0100
From:   Jonathan Cameron <jonathan.cameron@huawei.com>
To:     Pavel Machek <pavel@ucw.cz>
CC:     <linux-kernel@vger.kernel.org>,
        Justin Chen <justinpopo6@gmail.com>,
        "Sasha Levin" <sashal@kernel.org>
Subject: Re: [PATCH 4.19 189/276] iio: adc: ti-ads7950: Fix improper use of
 mlock
Message-ID: <20190606155637.00002b4f@huawei.com>
In-Reply-To: <20190606131300.GE27432@amd>
References: <20190530030523.133519668@linuxfoundation.org>
        <20190530030537.017297326@linuxfoundation.org>
        <20190606131300.GE27432@amd>
Organization: Huawei
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 6 Jun 2019 15:13:00 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> (stable removed from cc list)
> 
> > Indio->mlock is used for protecting the different iio device modes.
> > It is currently not being used in this way. Replace the lock with
> > an internal lock specifically used for protecting the SPI transfer
> > buffer.
> > 
> > Signed-off-by: Justin Chen <justinpopo6@gmail.com>
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > ---
> >  drivers/iio/adc/ti-ads7950.c | 19 +++++++++++++++----
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> >   
> 
> > @@ -277,6 +280,7 @@ static irqreturn_t ti_ads7950_trigger_handler(int irq, void *p)
> >  	struct ti_ads7950_state *st = iio_priv(indio_dev);
> >  	int ret;
> >  
> > +	mutex_lock(&st->slock);
> >  	ret = spi_sync(st->spi, &st->ring_msg);
> >  	if (ret < 0)
> >  		goto out;
> > @@ -285,6 +289,7 @@ static irqreturn_t ti_ads7950_trigger_handler(int irq, void *p)
> >  					   iio_get_time_ns(indio_dev));
> >  
> >  out:
> > +	mutex_unlock(&st->slock);
> >  	iio_trigger_notify_done(indio_dev->trig);
> >  
> >  	return IRQ_HANDLED;  
> 
> Does trigger_handler run from interrupt context? Prototype suggests
> so... If so, it can not really take mutexes...

It's an interrupt thread so taking mutexes should be fine.
For this particular case there is no 'top half' provided to
the call to iio_triggered_buffer_setup so nothing runs in interrupt context.

The spi_sync call can sleep anyway so this code can only run where
sleeping is fine.

Thanks,

Jonathan


> 
> Best regards,
> 								Pavel
>