linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier
Date: Sat, 30 Jun 2018 19:18:58 -0700	[thread overview]
Message-ID: <CA+55aFwwzF-PeS02x-9FFSQdPpJgmaEtC8KNfG_U_DTbSXz+-g@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFyS1bdmETHUYEejecOcG5MAjGCAbkr-M5iphJYfrj2oLA@mail.gmail.com>

On Sat, Jun 30, 2018 at 7:07 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Those locks won't protect kobj races in _general_ (ie there is no
> locking between two totally unrelated buses), but they *should*
> serialize the case of a device being added within one class. No?

Side note: there had *better* be some locking whenever there is a way
to find an object, because otherwise you have a fundamental lifetime
problem: one thread finding the object at the same time another thread
frees it for the last time. Even the "unless_zero()" won't fix it,
because the final free will release the underlying object itself, so
the "zero" state is ephemeral.

That locking might be just RCU during lookup, and rcu-delaying the
release, of course.  I think that's all the sysfs code needs, for
example, since that's what lookup uses.

And for any other embedded kobj cases, where you can reach the object
using some random subsystem pointers, there had better be other
locking in place for that pointer lookup vs the last removal.

kobject itself doesn't provide that locking, it only provides the
reference counting. But that's partly why it really has to disallow
any kobject_get() of a zero object, because it means that the
tear-down has been started, but the tear-down itself may not have had
time to get the lock yet (ie kobject_release() may be just about to
call the t->release() function).

But maybe I'm missing something subtle.

               Linus

  reply	other threads:[~2018-07-01  2:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c40fe912fe008b1b531a3867e8784ed79d68023e.camel@kernel.crashing.org>
     [not found] ` <CA+55aFxR0qg0yY-NWnH0DDruVWw8qRqp8=CRLq13p=TyxosJKw@mail.gmail.com>
2018-06-29  2:21   ` [PATCH 1/2] drivers: core: Don't try to use a dead glue_dir Benjamin Herrenschmidt
2018-06-30 19:45     ` Linus Torvalds
2018-07-07 16:48       ` Greg Kroah-Hartman
2018-07-09 23:44         ` Benjamin Herrenschmidt
2018-07-10 14:55           ` Greg Kroah-Hartman
2018-07-10 23:32             ` Benjamin Herrenschmidt
2018-07-10 23:55               ` Linus Torvalds
2018-07-11  0:07                 ` Benjamin Herrenschmidt
2018-07-21  7:53           ` Greg Kroah-Hartman
2018-07-23  0:35             ` Benjamin Herrenschmidt
2018-07-07 16:51     ` Greg Kroah-Hartman
2018-07-09 23:50       ` Benjamin Herrenschmidt
2018-06-29  2:21   ` [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier Benjamin Herrenschmidt
2018-06-29 13:56     ` Linus Torvalds
2018-06-29 13:57       ` Linus Torvalds
2018-06-30  1:04       ` Benjamin Herrenschmidt
2018-06-30  3:51         ` Benjamin Herrenschmidt
     [not found]   ` <edc7b03b9550ddcf1291ebf5a6dafd24f4455c23.camel@kernel.crashing.org>
     [not found]     ` <CA+55aFxS7OVEN5XrxceC5ibz780mhn-qRa50w1gVFjsz2JjMbw@mail.gmail.com>
     [not found]       ` <7eb06b499f2be366cf68c6b6588b16c603e6a567.camel@kernel.crashing.org>
2018-07-01  2:07         ` Linus Torvalds
2018-07-01  2:18           ` Linus Torvalds [this message]
2018-07-01  3:49             ` Benjamin Herrenschmidt
2018-07-01  3:42           ` Benjamin Herrenschmidt
2018-07-01  3:57             ` Linus Torvalds
2018-07-01  7:16               ` Benjamin Herrenschmidt
2018-07-01 17:04                 ` Linus Torvalds
2018-07-01 23:36                   ` Benjamin Herrenschmidt
2018-07-02 10:23                     ` Benjamin Herrenschmidt
2018-07-02 19:24                       ` Linus Torvalds
2018-07-03  0:57                         ` Benjamin Herrenschmidt
2018-07-03  2:15                           ` Linus Torvalds
2018-07-03  2:26                             ` Linus Torvalds
2018-07-03  2:39                               ` Benjamin Herrenschmidt
2018-07-03  5:22                                 ` Benjamin Herrenschmidt
2018-07-03 15:46                                   ` Tejun Heo
2018-07-04  1:10                                     ` Benjamin Herrenschmidt
     [not found]                                   ` <CA+55aFzKmzC-2_6+RsRRu9KfK_r=UGgLN2Q0hSNBV=ScGR7=8g@mail.gmail.com>
     [not found]                                     ` <6e3ca577f8dd5f3621d1054447d3f928a73dfcf9.camel@kernel.crashing.org>
     [not found]                                       ` <CA+55aFy+ZSu5cPzk887N-ZgXqvTB=Bp1JQYMWT1SZY81MqLH6Q@mail.gmail.com>
     [not found]                                         ` <1bc873980e7f63291fbe19dbc7e1607b8e126241.camel@kernel.crashing.org>
     [not found]                                           ` <20180707164241.GB16279@kroah.com>
     [not found]                                             ` <CA+55aFx-UX8nxewRFFWdBgYfPqfipnxaqJuJCUni9h4JvhoPFw@mail.gmail.com>
2018-07-10  0:29                                               ` [PATCH v2 " Benjamin Herrenschmidt
2018-07-10  0:33                                                 ` Linus Torvalds
2018-07-10  1:37                                                   ` Benjamin Herrenschmidt
2018-07-10 14:55                                                 ` Greg Kroah-Hartman
2018-07-10 23:31                                                   ` Benjamin Herrenschmidt
2018-07-03  2:37                             ` [PATCH " Benjamin Herrenschmidt
2018-07-02 10:22                   ` Benjamin Herrenschmidt
2018-07-01  3:52       ` Benjamin Herrenschmidt

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=CA+55aFwwzF-PeS02x-9FFSQdPpJgmaEtC8KNfG_U_DTbSXz+-g@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel@jms.id.au \
    --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;
as well as URLs for NNTP newsgroup(s).