mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@home-tj.org>
To: dtor_core@ameritech.net
Cc: Greg KH <greg@kroah.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2.6.10-rc1 2/5] driver-model: bus_recan_devices() locking fix
Date: Tue, 9 Nov 2004 10:27:22 +0900	[thread overview]
Message-ID: <20041109012722.GA20689@home-tj.org> (raw)
In-Reply-To: <d120d50004110508333c183cc1@mail.gmail.com>

On Fri, Nov 05, 2004 at 11:33:37AM -0500, Dmitry Torokhov wrote:
> On Fri, 5 Nov 2004 15:14:39 +0900, Tejun Heo <tj@home-tj.org> wrote:
>
> >  Another problem I've encountered regarding kobject refcounting is
> > that currently each sysfs attr carries its owner and gets the owning
> > module when the attr is accessed.  However, there are attributes which
> > are provided not by the module which implements whatever the kobject
> > represents but by upper-level module or the kernel builtins.  So, it's
> > possible to unload a module while it's kobject is still alive by
> > holding on to such attributes, and, when the attribute is closed,
> > panic occurs, of course (release callback is unloaded already).
> > 
> 
> I actually spent quite few days thinking about this problem and here
> is what I come up with:
> 
> You have bus core module that provides generic release function for
> devices on the bus. When object is registered you bump up module
> count for the core module.
> You also have modues that provide devices. At device unregister time
> they do all device-specific cleanup, but leave attributes (and memory)
> handled by core modules intact. This allows to unload device module
> safely at any time and then when reference to the last generic attribute
> is dropped the generic cleanup finally removes last traces of the device.

 Are you suggesting splitting every bus implementation into two
separate modules?  Otherwise, we will have to move kobj field of every
bus-specific device structure to the head (to use the common release
function).  Either way, it can be done, but it just seems another
twist added to the already twisted refcounting.  Moreoever, not only
the devices are problematic, refcounting in class devices and block
device hierarchy seems broken too.

> <skip>
> > 
> > We can do one of
> > 
> > 1. add unload_sem to all driver-model structures.
> >        -> I believe this defeats the purpose of try_module_get()
> >        stuff.  We wouldn't know when the module will unload.
> > 
> 
> As Al Viro pointed out "rmmod module < /sys/bus/devices/xxxx/attr"
> will deadlock the kernel with this scheme.
> 
> > 2. get the owner field correct for all attributes.
> >        -> This will be a chore.  We'll need to allocate separate
> >        attr structures for each kobject for all the generic attrs.
> > 
> > 3. remove the owner field from the attribute structure and add an
> >    owner to kobject and make sysfs ops to hold the owner of the
> >    respective kobject.
> >        -> I think this is the best and most consistent solution.  As
> >        we already assume that module which implements a child kobject
> >        should depend upon the module which implements its parent, all
> >        attr module reference counting will be correct by using the
> >        kobject's owner.
> > 
> > So, I'm currently working on solution #3.
> > 
> 
> I think this is an overkill and will inflate every kobject out there,
> unless you will find a hole in my scheme...

 But all attrs will be deflated and it just seems the right thing to
do(tm).

-- 
tejun


  reply	other threads:[~2004-11-09  1:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-04  7:01 [PATCH 2.6.10-rc1 0/5] driver-model: misc bug fixes Tejun Heo
2004-11-04  7:02 ` [PATCH 2.6.10-rc1 1/5] driver-model: comment fix in bus.c Tejun Heo
2004-11-04 18:35   ` Greg KH
2004-11-04  7:02 ` [PATCH 2.6.10-rc1 2/5] driver-model: bus_recan_devices() locking fix Tejun Heo
2004-11-04 18:58   ` Greg KH
2004-11-04 19:12     ` Dmitry Torokhov
2004-11-05  6:14       ` Tejun Heo
2004-11-05 16:33         ` Dmitry Torokhov
2004-11-09  1:27           ` Tejun Heo [this message]
2004-11-09  1:43             ` Dmitry Torokhov
2004-11-10  7:13               ` Tejun Heo
2004-11-10  0:40           ` Greg KH
2004-11-10  4:17             ` Dmitry Torokhov
2004-11-16  5:52               ` Greg KH
2004-11-04  7:03 ` [PATCH 2.6.10-rc1 3/5] driver-model: sysfs_release() dangling pointer reference fix Tejun Heo
2004-11-04 18:59   ` Greg KH
2004-11-04  7:04 ` [PATCH 2.6.10-rc1 4/5] driver-model: kobject_add() error path reference counting fix Tejun Heo
2004-11-04 19:00   ` Greg KH
2004-11-04  7:05 ` [PATCH 2.6.10-rc1 5/5] driver-model: device_add() " Tejun Heo
2004-11-04 20:07   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041109012722.GA20689@home-tj.org \
    --to=tj@home-tj.org \
    --cc=dtor_core@ameritech.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®