[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YUjjHRHWCso1tjeX@bombadil.infradead.org>
Date: Mon, 20 Sep 2021 12:38:05 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Tejun Heo <tj@...nel.org>
Cc: gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
minchan@...nel.org, jeyu@...nel.org, shuah@...nel.org,
rdunlap@...radead.org, rafael@...nel.org, masahiroy@...nel.org,
ndesaulniers@...gle.com, yzaikin@...gle.com, nathan@...nel.org,
ojeda@...nel.org, penguin-kernel@...ove.sakura.ne.jp,
vitor@...saru.org, elver@...gle.com, jarkko@...nel.org,
glider@...gle.com, rf@...nsource.cirrus.com,
stephen@...workplumber.org, David.Laight@...lab.com,
bvanassche@....org, jolsa@...nel.org,
andriy.shevchenko@...ux.intel.com, trishalfonso@...gle.com,
andreyknvl@...il.com, jikos@...nel.org, mbenes@...e.com,
ngupta@...are.org, sergey.senozhatsky.work@...il.com,
reinette.chatre@...el.com, fenghua.yu@...el.com, bp@...en8.de,
x86@...nel.org, hpa@...or.com, lizefan.x@...edance.com,
hannes@...xchg.org, daniel.vetter@...ll.ch, bhelgaas@...gle.com,
kw@...ux.com, dan.j.williams@...el.com, senozhatsky@...omium.org,
hch@....de, joe@...ches.com, hkallweit1@...il.com, axboe@...nel.dk,
jpoimboe@...hat.com, tglx@...utronix.de, keescook@...omium.org,
rostedt@...dmis.org, peterz@...radead.org,
linux-spdx@...r.kernel.org, linux-doc@...r.kernel.org,
linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kselftest@...r.kernel.org, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, copyleft-next@...ts.fedorahosted.org
Subject: Re: [PATCH v7 09/12] sysfs: fix deadlock race with module removal
On Mon, Sep 20, 2021 at 09:22:32AM -1000, Tejun Heo wrote:
> On Mon, Sep 20, 2021 at 12:15:22PM -0700, Luis Chamberlain wrote:
>
> > Right, the reason I mention the alternative is that we technically don't
> > need to use try in this case since during a kernfs op it is implied the
> > module will be pinned, but we have further motivations to use a try
>
> I'm confused. If the module is already pinned, why are we getting an
> extra reference?
Sorry, I meant its pinned implicitly not through an actual refcount. A module
exit can happen then in that case, it just that the sysfs removal will
have to wait until the active reference for the kernfs ops go down.
> Also, I don't understand how this has that much to do
> with preventing ddoses. I mean, it does cut down the duration of one
> operation but the eventual gating is through whoever acquiring the
> initial reference through try_module_get(), which again is the *only*
> way to acquire a fresh reference.
True. I can just leave that out from the commit log. But it is perhaps
an implicit gain here that using try alows module exit to trump use
of an kernfs op. Maybe's that's sufficient to mention.
Luis
Powered by blists - more mailing lists