Thread (11 messages) 11 messages, 4 authors, 2021-09-21

Re: [PATCH v7 09/12] sysfs: fix deadlock race with module removal

From: Luis Chamberlain <mcgrof@kernel.org>
Date: 2021-09-21 01:42:25
Also in: cgroups, linux-doc, linux-fsdevel, linux-kselftest, lkml

Possibly related (same subject, not in this thread)

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:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help