[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6E21E5352C11B742B20C142EB499E0481E95C6@TK5EX14MBXC128.redmond.corp.microsoft.com>
Date: Mon, 9 May 2011 14:56:52 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: Christoph Hellwig <hch@...radead.org>
CC: Greg KH <greg@...ah.com>, "gregkh@...e.de" <gregkh@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>
Subject: RE: various vmbus review comments
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@...radead.org]
> Sent: Monday, May 09, 2011 10:34 AM
> To: KY Srinivasan
> Cc: Greg KH; gregkh@...e.de; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; virtualization@...ts.osdl.org
> Subject: Re: various vmbus review comments
>
> On Fri, May 06, 2011 at 01:10:38PM +0000, KY Srinivasan wrote:
> > I audited the block and the net drivers. As part of their exit routine,
> > they invoke vmbus_child_driver_unregister() after properly cleaning
> > up all the devices they are managing. Do you still see an issue with
> > regards to module reference counting.
>
> Which is not the correct thing to do as explained in my last round
> of reviews. Take a look at the PCI code - the functional driver only
> does a foo_untegister_driver (which maps almost directly to
> driver_unregister), which then causes the device core to unbind the
> devices. The function driver must never call device_unregister
> directly as the device continues to exist even if no driver is bound to
> it.
I will address this. Greg had a concern about module reference counting
and looking at the current code, it did not appear to be an issue. The
change you are suggesting will not affect the vmbus core which is what I want
to focus on. I will however, fix this issue in the current round of patches I will
send out this week.
Regards,
K. Y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists