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:	Tue, 17 Apr 2007 09:26:15 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Greg KH <greg@...ah.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Tejun Heo <htejun@...il.com>,
	Markus Rechberger <markus.rechberger@....com>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Swen Schillig <swen@...t.ibm.com>
Subject: Re: [linux-usb-devel] How should an exit routine wait for release()
 callbacks?

On Mon, 16 Apr 2007 15:12:47 -0700,
Greg KH <greg@...ah.com> wrote:

> Ah, just found this original thread, now Cornelia's patches make more
> sense...

I would have included a pointer, but couldn't access marc yesterday
evening, sorry...

> 
> On Fri, Apr 13, 2007 at 11:24:58AM -0400, Alan Stern wrote:
> > Tejun, it just occurred to me that you would be interested in this email 
> > thread.  Just to bring you up to speed, here's the original question:
> > 
> > > I've got a module which registers a struct device.  (It represents a
> > > virtual device, not a real one, but that doesn't matter.)
> 
> Wait, that's the issue right there.
> 
> Don't do that.
> 
> devices should be created by busses or the platform core, which owns the
> release function for them.  Individual drivers should not create
> devices.

There are drivers that do it, for a variety of reasons.

> 
> Hm, but then, how would you ever unload a bus, as the same issue might
> be there too...

Exactly :) This would imply busses/subsystems could never be unloadable
modules.

> 
> Any specific code in the kernel you can point to that has this issue
> today?

zfcp comes to mind. They register some units in zfcp_aux.c, which don't
have anything to do with the bus the zfcp adapter is on (the ccw bus).
Currently, that is "solved" by disallowing zfcp module unloading.
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ