linux-kernel - RE: various vmbus review comments

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 May 2011 17:34:55 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Greg KH <greg@...ah.com>
CC:	"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: Greg KH [mailto:greg@...ah.com]
> Sent: Friday, May 06, 2011 11:00 AM
> To: KY Srinivasan
> Cc: 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:
> > > No, I am referring to the module reference counting of the bus drivers
> > > that register with the vmbus core.  You aren't doing that at all, and
> > > you probably need to make sure that this isn't needed.  That is
> > > concentrating on the vmbus driver.
> >
> > 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.
> 
> I will look again, the next time I review the vmbus code.

Thank you.

> 
> > > > I will also address your comment on static initialization hv_driver instances
> > > > as part of other driver cleanup.
> > >
> > > No, please do this now as it will show how to properly interact with the
> > > vmbus core code in the correct manner.  Hopefully that will be correct,
> > > but I have a feeling that it will show you some places in the API that
> > > need to be changed...
> >
> > As opposed to run-time initialization of fields such as probe, etc; I have
> > initialized them statically. For instance, in the blkvsc driver:
> >
> > /* The one and only one */
> > static  struct storvsc_driver blkvsc_drv = {
> >         .base.probe =  blkvsc_probe,
> >         .base.remove =  blkvsc_remove,
> >         .base.shutdown = blkvsc_shutdown,
> > };
> >
> > Is this what you had in mind.
> 
> Close.  The format is correct.
> 
> But what's with that ".base." crud?  That shows that something is wrong
> as no USB or PCI or any other bus driver has to mess with a ".base"
> subpointer in a driver structure.
> 
> See, I told you that when you converted to use this format the problems
> would pop out at you :)
> 
> Please fix that.

I will. I am incrementally cleaning up the drivers, I will cleanup the ".base" 
crud as part of additional cleanup that I will do.

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/