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] [day] [month] [year] [list]

Date:	Thu, 19 Apr 2007 10:46:41 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Cornelia Huck <cornelia.huck@...ibm.com>, 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 Wed, 2007-04-18 at 11:20 -0400, Alan Stern wrote:
> On Wed, 18 Apr 2007, Rusty Russell wrote:
> 
> > Hi Alan,
> > 
> > 	Your assertion is correct.  I haven't studied the driver core, so I
> > might be off-base here, but you'll note that if the module references
> > the core kmalloc'ed object rather than the other way around it can be
> > done safely.  The core can also reference the module, but it must be
> > able to live without it once it's gone (eg. by returning -ENOENT).
> 
> "Live without it once it's gone..."  Do you mean once the object is gone 
> or once the module is gone?  The core in general has no way to know when 
> the module is gone; all it knows about is the object.  The trouble arises 
> when the module is gone (whether the core knows it or not) but the object 
> is still present.

Hi Alan,

	I meant that the module is gone: it has told the object (via
unregister_xxx) that it's gone.

> > A really poor example is below:
...
> The example is fine as far as it goes, but it assumes that all
> interactions with the underlying r->foo object can be done under a
> spinlock.  Of course this isn't true in general.

There are certainly other ways of doing it, such as a mutex, a refcnt &
completion (for function pointers), or disabling preemption across the
access and using stop_machine().  Of course, these add complexity.

This is the reason that I've always disliked module removal.  We have a
lot of code to deal with it and it has awkward semantics (unless --wait
is used).  OTOH, I'm not a fan of the network approach, either: I feel
that bringing up an interface should bump the refcnt of the module which
implements that interface.  Currently taking out e1000 will just kill my
eth0.

Cheers,
Rusty.







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