From: Greg KH <greg@kroah.com>
To: dtor_core@ameritech.net
Cc: Tejun Heo <tj@home-tj.org>, 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 16:40:53 -0800 [thread overview]
Message-ID: <20041110004052.GB8672@kroah.com> (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:
> > Or maybe just adding a @write_lock argument to bus_for_each_*()
> > functions or create a new function named __bus_for_each_*() which
> > takes additional @write_lock argument.
> >
> > However, I don't really think the get_bus/put_bus() calls are
> > necessary there. Unless the caller already has a reference to the
> > bus, we're in trouble anyway. get_bus() cannot synchronize with the
> > last put_bus(), we need outer synchronization to protect that
> > (individual bus drivers are expected to perform the synchronization).
> >
>
> Yes I think you are right.
>
> > One thing that bothers me is all the "if (kobject_get(x))" codes.
> > Currently, it doesn't seem to do anything other than checking if x is
> > NULL or not and incrementing the reference count. i.e. the return
> > value only represents if x is NULL or not. I find the codes
> > misleading. It seems like above statement can synchronize get() and
> > the last put() which isn't true. I don't how how the using xchg in
> > kref went, but with preemtion turned on, I don't see how it's gonna
> > change the situation.
> >
>
> I agree it is somewhat misleading. And even if _get would synchronize
> with _put taht wouldmean that the caller does not have a valid reference
> and the kernel will crash there next time callers uses the object in
> question.
>
> I think we just have lay down the rules that one needs to get a reference
> to an object in the following cases:
> - object creation (first reference)
> - linking some other object to the object in question. Every link to the
> object should increase reference count.
> - before passing object to another thread of execution to guarantee that
> the object will live long enough for both threads.
The rules are defined. See my OLS 2004 paper on krefs for details.
thanks,
greg k-h
next prev parent reply other threads:[~2004-11-10 0:52 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
2004-11-09 1:43 ` Dmitry Torokhov
2004-11-10 7:13 ` Tejun Heo
2004-11-10 0:40 ` Greg KH [this message]
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=20041110004052.GB8672@kroah.com \
--to=greg@kroah.com \
--cc=dtor_core@ameritech.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@home-tj.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