All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Felipe Balbi <balbi@ti.com>, linux-iio@vger.kernel.org
Subject: Re: [PATCH 1/2] iio: adc: ti_am335x_adc: do not free the kfifo twice
Date: Sat, 09 Nov 2013 12:34:21 +0000	[thread overview]
Message-ID: <527E2BCD.7090904@kernel.org> (raw)
In-Reply-To: <52690979.9070304@kernel.org>

On 10/24/13 12:50, Jonathan Cameron wrote:
> On 10/24/13 11:44, Lars-Peter Clausen wrote:
>> On 10/24/2013 12:34 PM, Sebastian Andrzej Siewior wrote:
>>> On 10/24/2013 11:41 AM, Lars-Peter Clausen wrote:
>>>> The driver seems to be missing the iio_buffer_attach() call. Something like
>>>> this should fix the problem:
>>>>
>>>> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
>>>> index ef54d8a..bf9c89c 100644
>>>> --- a/drivers/iio/adc/ti_am335x_adc.c
>>>> +++ b/drivers/iio/adc/ti_am335x_adc.c
>>>> @@ -229,12 +229,15 @@ static int tiadc_iio_buffered_hardware_setup(struct
>>>> iio_dev *indio_dev,
>>>>  	unsigned long flags,
>>>>  	const struct iio_buffer_setup_ops *setup_ops)
>>>>  {
>>>> +	struct iio_buffer *buffer;
>>>>  	int ret;
>>>>
>>>> -	indio_dev->buffer = iio_kfifo_allocate(indio_dev);
>>>> -	if (!indio_dev->buffer)
>>>> +	buffer = iio_kfifo_allocate(indio_dev);
>>>> +	if (!buffer)
>>>>  		return -ENOMEM;
>>>>
>>>> +	iio_device_attach_buffer(indio_dev, buffer);
>>>> +
>>>>  	ret = request_threaded_irq(irq,	pollfunc_th, pollfunc_bh,
>>>>  				flags, indio_dev->name, indio_dev);
>>>>  	if (ret)
>>>
>>> Yep, that works, thanks.
>>>
>>> Shouldn't the two
>>>
>>>          tiadc_iio_buffered_hardware_remove(indio_dev);
>>>          tiadc_channels_remove(indio_dev);
>>>
>>> in tiadc_remove() be reversed in their call order? The second alter is
>>> accessing the buffer which is released by the former one.
>>>
>>
>> As far as I can see tiadc_channels_remove() only does a
>> kfree(indio_dev->channels), so it does not access the buffer at all.
> Certainly seems to be true...
>>
>>> btw: is all this ref counting really required? I mean I would assume
>>> allocate buffer in one place (at probe time) release it remove time
>>> should be enough.
>>
>> It is required. Userspace may still be reading from the buffer when the
>> driver frees it. So we need proper refcounting here.
> 
> Lars, can you do a clean version of the above with a reported-by from Sebastian
> then Sebastian can you ack (if you are happy with it of course!)
> 
Lars, I've turned the above into a coherent patch and applied it to the fixes-togreg
branch.  I've added your Signed-off-by: Shout if you would prefer not.

Also a reported by for Sebastian.

I didn't want this patch to fall through the cracks given it's been around a while now.

Jonathan

> Thanks,
> 
> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2013-11-09 11:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23 17:44 [PATCH 1/2] iio: adc: ti_am335x_adc: do not free the kfifo twice Lars-Peter Clausen
2013-10-24 10:13 ` Jonathan Cameron
2013-10-24  9:25   ` Sebastian Andrzej Siewior
2013-10-24  9:41     ` Lars-Peter Clausen
2013-10-24 10:34       ` Sebastian Andrzej Siewior
2013-10-24 10:44         ` Lars-Peter Clausen
2013-10-24 10:51           ` Sebastian Andrzej Siewior
2013-10-24 11:50           ` Jonathan Cameron
2013-11-09 12:34             ` Jonathan Cameron [this message]
2013-11-10  9:37               ` Lars-Peter Clausen
2013-11-10 11:31                 ` Jonathan Cameron
  -- strict thread matches above, loose matches on Subject: below --
2013-10-23 17:00 Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527E2BCD.7090904@kernel.org \
    --to=jic23@kernel.org \
    --cc=balbi@ti.com \
    --cc=bigeasy@linutronix.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.