From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.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: Wed, 11 Jul 2018 10:07:14 +1000 [thread overview]
Message-ID: <12f49dfa50ea32039194d5e91861ebef8c9b0565.camel@kernel.crashing.org> (raw)
In-Reply-To: <CA+55aFwWq1pMzKbkgTN9f9srSHubq+tKKPHwZazqt8ODD3btNQ@mail.gmail.com>
On Tue, 2018-07-10 at 16:55 -0700, Linus Torvalds wrote:
> On Tue, Jul 10, 2018 at 4:32 PM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > > I like that fix, which should make this patch obsolete, right?
> >
> > Yes, for that specific issue, but Linus seemed to think patch 1 was the
> > "right thing to do" regardless...
>
> I would definitely prefer either a kobject_get_unless_zero() or a
> warning if it is ever zero.
>
> The fact that right now it silently can do known bad things, and then
> causes odd corruption _later_, is not good.
Maybe we should make the existing warning in refcount unconditional ?
This is whe warning that allowed me to pull that string with the
gluedirs and fix what ended up very weird crashes caused by the
resulting use-after-free. So it's definitely valuable.
As for whether we should generalize kobject_get_unless_zero() vs avoid
using it alltogether, this is a debate for you to have with Greg ;-)
He seems to think nothing should ever try to get a zeroed object (which
I tend to agree with, it's close to my opinion that visibility and
lifetime should be disconnected).
That being said, there are existing constructs such as the "late
removal from sysfs from kobject_release" that mean that zero-reference
objects *can* still be visible, via either sysfs or ksets, as far as I
can tell.
So it's a bit of a mess... but if we chose to go Greg's way we should
probably put a WARN'ing in kobject_release() for late-removal from
sysfs since this exposes 0-ref objects to outside visibility.
Cheers,
Ben.
next prev parent reply other threads:[~2018-07-11 0:10 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 ` 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 [this message]
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=12f49dfa50ea32039194d5e91861ebef8c9b0565.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--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
all inboxes | Powered by JetHome®