linux-kernel - Re: [PATCH 1/3] staging: vme: add functions for bridge module refcounting

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]

Message-ID: <20110829184012.GA19793@flamenco.cs.columbia.edu>
Date:	Mon, 29 Aug 2011 14:40:12 -0400
From:	"Emilio G. Cota" <cota@...ap.org>
To:	Greg KH <greg@...ah.com>
Cc:	Manohar Vanga <manohar.vanga@...n.ch>, gregkh@...e.de,
	martyn.welch@...com, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] staging: vme: add functions for bridge module
 refcounting

On Mon, Aug 29, 2011 at 10:51:04 -0700, Greg KH wrote:
> On Mon, Aug 29, 2011 at 11:02:48AM +0200, Manohar Vanga wrote:
> > This patch adds functions that allow for reference counting
> > bridge modules. The patch introduces the functions
> > 'vme_bridge_get()' and 'vme_bridge_put()'.
> > 
> > The functions are automatically called during .probe and .remove
> > for drivers.
> > 
> > This patch is based on the changes introduced by Emilio G. Cota
> > in the patch:
> > 
> >     https://lkml.org/lkml/2010/10/25/492
> 
> Generally do not try to couple a module reference count with a device
> count, you are locking code, not data, and we really don't want to lock
> code anymore now that we properly handle device reference counts.

(snip)

> > diff --git a/drivers/staging/vme/vme_bridge.h b/drivers/staging/vme/vme_bridge.h
> > index 8959670..ef751a4 100644
> > --- a/drivers/staging/vme/vme_bridge.h
> > +++ b/drivers/staging/vme/vme_bridge.h
> > @@ -113,6 +113,7 @@ struct vme_bridge {
> >  	struct device *parent;	/* Parent device (eg. pdev->dev for PCI) */
> >  	void *driver_priv;	/* Private pointer for the bridge driver */
> >  	struct list_head bus_list; /* list of VME buses */
> > +	struct module *owner;	/* module that owns the bridge */
> 
> Why?  When you register the device for this bridge, you should properly
> handle the module reference counting in the vme core for any open sysfs
> files.
> 
> Other than that, you shouldn't care about the module reference at all,
> right?
> 
> What am I missing here?  What is this solving?
> 
> confused,

AFAIK currently a vme bridge driver can be freely removed with rmmod
even if it has devices under it. The patch avoids this by increasing
the refcount of the bridge module every time a device is registered
under it.

What's the appropriate thing to do when rmmod tries to remove a bridge
module? Shall we remove each bridge and all the child devices, or just
refuse to remove a bridge when it has child devices? Manohar implements
the latter, although incrementing the refcount of the module is admittedly
coarse. He said he'd later change this to implement the refcounting on
each bridge device (and not module).

Hope this helps, thanks for looking at it.

		Emilio

--
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/