linux-kernel - Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for 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: <Pine.LNX.4.44L0.0704171159360.20368-100000@iolanthe.rowland.org>
Date:	Tue, 17 Apr 2007 12:08:46 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
cc:	Rusty Russell <rusty@...tcorp.com.au>, Greg KH <greg@...ah.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tejun Heo <htejun@...il.com>
Subject: Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for refcounting.

On Tue, 17 Apr 2007, Cornelia Huck wrote:

> On Tue, 17 Apr 2007 12:53:10 +1000,
> Rusty Russell <rusty@...tcorp.com.au> wrote:
> 
> > On Mon, 2007-04-16 at 15:53 -0400, Alan Stern wrote:
> > > The fundamental rule is that whenever you hand out a pointer to a routine
> > > living in a module, the receiver has to increment the module's refcount.  
> > > But the driver core violates this rule all over the place.
> > 
> > Hi Alan,
> > 
> > 	Your rule is overly simplistic, unfortunately.  You have two choices:
> > take a reference count, *or* ensure that the reference will go away when
> > the module's cleanup routine is called.  Network drivers are a classic
> > example of the latter.
> 
> Hm, but that's exactly the problem we face here. There is no race-free
> way (at least, nobody could think about one yet) to make sure all
> references are freed at exit time and simultaneously to make sure that
> the release functions have finished before the module has been deleted.

More specifically, there _is_ no way in general to ensure that a reference
will go away when the module's cleanup routine is called, unless you are
very careful not to pass that reference on to _anybody_.  The driver core
certainly can't do this; it passes a device reference to anyone who
creates a child of that device (the parent pointer) -- and it can't 
guarantee that every one of its clients will drop their references when 
their exit routines run.

I'm not so sure I fully believe that network drivers can do what Rusty
says, at least not in every circumstance.  There simply are too many
possible ways for references to linger on after you thought they were all
gone.  For example, what happens when the user has mounted a filesystem on
a USB drive running via USB-over-TCP though a network interface?

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/