Hello, On Mon, Sep 20, 2021 at 12:15:22PM -0700, Luis Chamberlain wrote: > > I find this explanation odd because there's no real equivalent to locking > > the module (as opposed to try locking) > > Actually there is, __module_get() but I suspect some of these users are > probably incorrect and should be be moved to try. The documentation __module_get() is just getting an extra ref when the caller already has one (or more). It can't be used to freshly acquire a new reference. There is no equivalence between the relationship between try_module_get() and __module_get() and the one between spin_trylock() and spin_lock(). > 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? 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. Thanks. -- tejun