From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Joel Stanley <joel@jms.id.au>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] drivers: core: Don't try to use a dead glue_dir
Date: Sat, 7 Jul 2018 18:48:38 +0200 [thread overview]
Message-ID: <20180707164838.GC16279@kroah.com> (raw)
In-Reply-To: <CA+55aFwg+j60ZFi7t7kVXbobCT4XHoiZP_w6+Cbm+AeU1ytfNQ@mail.gmail.com>
On Sat, Jun 30, 2018 at 12:45:21PM -0700, Linus Torvalds wrote:
> On Thu, Jun 28, 2018 at 7:21 PM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > Under some circumstances (such as when using kobject debugging)
> > a gluedir whose kref is 0 might remain in the class kset for
> > a long time. The reason is that we don't actively remove glue
> > dirs when they become empty, but instead rely on the implicit
> > removal done by kobject_release(), which can happen some amount
> > of time after the last kobject_put().
> >
> > Using such a dead object is a bad idea and will lead to warnings
> > and crashes.
>
> So with the other patch in mind, here's my comments on this one. Pick
> one of two scenarios:
>
> (a) it's obviously correct.
>
> We obviously can *not* take an object with a zero refcount,
> because it is already been scheduled for kobject_cleanup(), and
> incrementing the refcount is simply fundamentally wrong, because
> incrementing the refcount won't unschedule the deletion of the object.
>
> (b) the patch is wrong, and our "kobject_get()" should cancel the
> kobject_cleanup() instead.
>
> There are problems with both of the above cases.
>
> The "patch is obviously correct" case leads to another issue: why
> would kobject_get() _ever_ succeed on an object wioth a zero refcount?
> IOW, why do we have kobject_get() vs kobject_get_unless_zero() in the
> first place? It is *never* ok to get an kobject with a zero refcount
> because of the above "it's already scheduled for deletion" issue.
>
> The (b) case sounds nice, and would actually fix the problem that
> patch 2/2 was tryihng to address, and would make
> CONFIG_DEBUG_KOBJECT_RELEASE work.
>
> HOWEVER. It's completely untenable in reality - it's a nightmare from
> a locking standpoint, because kref_put() literally depends not on
> locking, but on the exclusive "went to zero".
>
> So I think (b) is practically not acceptable. Which means that (a) is
> the right reaction, and "kobject_get()" on an object with a zero
> refcount is _always_ wrong.
>
> But that says that "yes, the patch is obviously correct", but it also
> says "the patch should be pointless, because kobject_get() should just
> _always_ have the semantics of "kobject_get_unless_zero()", and the
> latter shouldn't even exist.
>
> Greg? When would it possibly be valid to do "kobject_get()" on a zero
> refcount object? I don't see it. But this is all very much your code.
No, kobject_get() should never happen on a 0 refcount object. That
being said, the code does allow it, so if things are messed up, it will
happen. I think that change happened when the switch to refcount_t
occured, before then we would WARN_ON() if that ever happened. I should
go fix that up, and restore that old behavior, so that syzbot starts
complaining loudly when stuff like that hits.
So I hate using kobject_get_unless_zero(), and resisted ever adding it
to the tree as it shows a bad locking/tree situation as you point out
here. But for some reason, the block developers seemed to insist they
needed it, and so it is in the tree for them. I don't want it to spread
if at all possible, which makes me want to reject this patch as this
should be "a case that can never be hit".
thanks,
greg k-h
next prev parent reply other threads:[~2018-07-07 16:48 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 [this message]
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
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=20180707164838.GC16279@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=benh@kernel.crashing.org \
--cc=ebiederm@xmission.com \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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).