From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Muchun Song <smuchun@gmail.com>,
gregkh@linuxfoundation.org, rafael@kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] driver core: Fix use-after-free and double free on glue directory
Date: Thu, 25 Apr 2019 19:24:39 +1000 [thread overview]
Message-ID: <24b0fff3775147c04b006282727d94fea7f408b4.camel@kernel.crashing.org> (raw)
In-Reply-To: <20190423143258.96706-1-smuchun@gmail.com>
On Tue, 2019-04-23 at 22:32 +0800, Muchun Song wrote:
> There is a race condition between removing glue directory and adding a new
> device under the glue directory. It can be reproduced in following test:
>
.../...
> In order to avoid this happening, we we should not call kobject_del() on
> path2 when the reference count of glue_dir is greater than 1. So we add a
> conditional statement to fix it.
Good catch ! However I'm not completely happy about the fix you
propose.
I find relying on the object count for such decisions rather fragile as
it could be taken temporarily for other reasons, couldn't it ? In which
case we would just fail...
Ideally, the looking up of the glue dir and creation of its child
should be protected by the same lock instance (the gdp_mutex in that
case).
That might require a bit of shuffling around though.
Greg, thoughts ? This whole gluedir business is annoyingly racy still.
My gut feeling is that the "right fix" is to ensure the lookup of the
glue dir and creation of the child object(s) are done under a single
instance of gdp_mutex so we never see a stale "empty" but still
poentially used glue dir around.
This should also be true when creating such gluedir in the first place
in fact, though that race is a lot harder to hit.
Cheers,
Ben.
next prev parent reply other threads:[~2019-04-25 9:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 14:32 [PATCH] driver core: Fix use-after-free and double free on glue directory Muchun Song
2019-04-25 9:24 ` Benjamin Herrenschmidt [this message]
2019-04-25 15:44 ` Muchun Song
2019-04-28 10:10 ` Benjamin Herrenschmidt
2019-04-28 14:49 ` Muchun Song
2019-05-02 6:25 ` Benjamin Herrenschmidt
2019-05-04 14:47 ` Muchun Song
2019-05-04 15:34 ` Greg KH
2019-05-09 14:38 ` Gaurav Kohli
2019-05-09 23:22 ` Benjamin Herrenschmidt
2019-05-10 3:31 ` Gaurav Kohli
2019-05-14 10:56 ` Mukesh Ojha
2019-05-14 10:59 ` Prateek Sood
2019-05-14 11:51 ` Muchun Song
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=24b0fff3775147c04b006282727d94fea7f408b4.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=smuchun@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.