All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Russell <brian.russell@brocade.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Brian Russell <brussell@brocade.com>
Cc: "Hans J. Koch" <hjk@hansjkoch.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 2/2] uio: Fix uio driver to refcount device
Date: Tue, 24 Mar 2015 12:59:22 +0000	[thread overview]
Message-ID: <55115FAA.50800@brocade.com> (raw)
In-Reply-To: <20150323204145.GA22203@kroah.com>



On 23/03/15 20:41, Greg Kroah-Hartman wrote:
> On Fri, Mar 20, 2015 at 02:54:44PM +0000, Brian Russell wrote:
>> Protect uio driver from its owner being unplugged while there are open fds.
>> Embed struct device in struct uio_device, use refcounting on device, free
>> uio_device on release.
>> info struct passed in uio_register_device can be freed on unregister, so null
>> out the field in uio_unregister_device and check accesses.
> 
> That's really not protecting anything except heavy-handed problems...
> 
> Look at the code:
> 
>> @@ -493,7 +499,7 @@ static unsigned int uio_poll(struct file *filep, poll_table *wait)
>>  	struct uio_listener *listener = filep->private_data;
>>  	struct uio_device *idev = listener->dev;
>>  
>> -	if (!idev->info->irq)
>> +	if (!idev->info || !idev->info->irq)
>>  		return -EIO;
>>  
> 
> Great, you checked the irq value, but what if it changes the very next
> line:
> 
>>  	poll_wait(filep, &idev->wait, wait);
> 
> Or any other line within this function?  Or any other function that you
> try to check the value for in the beginning...
> 
> This really isn't protecting anything "properly", sorry.  Either we
> don't care about it (hint, I don't think we really do), or we need to
> properly lock things and check, and protect, things that way.
> 

The checks for irq value are already there. I added the checks for the
idev->info ptr and deliberately nulled it in uio_unregister_device as
the caller module may free uio_info after unregistering (dpdk's igb_uio
does anyway) and then release will be called later when fds are closed.

So I think I definitely need the check in uio_release. I didn't think
it hurt to return early from poll/read/write if we know the device
has been unregistered?

Thanks,

Brian

> Please do the first one, as the reference count should be all that we
> need to care about here.
> 
> Sorry I missed this on the previous review, just realized it now this
> time around.
> 
> thanks,
> 
> greg k-h
> 

  reply	other threads:[~2015-03-24 12:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 14:54 [PATCH v9 2/2] uio: Fix uio driver to refcount device Brian Russell
2015-03-23 20:41 ` Greg Kroah-Hartman
2015-03-24 12:59   ` Brian Russell [this message]
2015-06-08 19:25     ` Guenter Roeck
2015-06-08 20:07       ` Brian Russell
2015-10-27 20:12         ` Jean-François Dagenais

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=55115FAA.50800@brocade.com \
    --to=brian.russell@brocade.com \
    --cc=brussell@brocade.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hjk@hansjkoch.de \
    --cc=linux-kernel@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.