linux-kernel - Re: [Patch -mm 0/3] RFC: module unloading vs. release function

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: <Pine.LNX.4.44L0.0704161634460.2795-100000@iolanthe.rowland.org>
Date:	Mon, 16 Apr 2007 17:02:46 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Greg KH <greg@...ah.com>, Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tejun Heo <htejun@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [Patch -mm 0/3] RFC: module unloading vs. release function

On Mon, 16 Apr 2007, Dmitry Torokhov wrote:

> > > What about 4:
> > >
> > >     When registering an [k]object increment refcount of module that
> > > provides ->release() function.
> > >
> > > That would normally require ->release function to be placed on
> > > subsystem level to allow unloading individual devices.

That's what Cornelia is trying to do.  For all release methods, not just 
those on the subsystem level (although that is where most of them sit).

> > But that would also mean that a lot of modules that want to be able to
> > be released whenever they want to today, not be allowed to (network
> > drivers, etc.)
> >
> 
> No, only the core module has to stay. For example, every time you
> register an input device you pin input.ko as it is the module that
> provides ->release() method for input devices. You can freely unload
> psmouse, or hid or your favorite joystick but input has to stay until
> last reference to the input device is dropped. serio and gameport work
> the same way.
> 
> I think the requirement that one is not able to unload a core
> subsystem module untill all users are dropped off is ok - you can't
> unload it anyway until you unload all drivers that reference its
> exported functions and once you unload all the drivers data objects
> will drop off pretty quickly.

The problem is that sometimes devices are owned by modules that aren't
core subsystem modules.  Or the code using a device doesn't depend on the
device's owner module and therefore doesn't pin it.

Alan Stern

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