linux-kernel - RE: [PATCH] kernel/module: add documentation for try_module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6054c136290346d581e276abbb2e3ff1@AcuMS.aculab.com>
Date:   Wed, 28 Jul 2021 08:28:11 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Luis Chamberlain' <mcgrof@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "tj@...nel.org" <tj@...nel.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "andriin@...com" <andriin@...com>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "atenart@...nel.org" <atenart@...nel.org>,
        "alobakin@...me" <alobakin@...me>,
        "weiwan@...gle.com" <weiwan@...gle.com>,
        "ap420073@...il.com" <ap420073@...il.com>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "ngupta@...are.org" <ngupta@...are.org>,
        "sergey.senozhatsky.work@...il.com" 
        <sergey.senozhatsky.work@...il.com>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "mbenes@...e.com" <mbenes@...e.com>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "jikos@...nel.org" <jikos@...nel.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Douglas Gilbert <dgilbert@...erlog.com>,
        "Hannes Reinecke" <hare@...e.de>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] kernel/module: add documentation for try_module_get()

...
> sysfs files are safe to use try_module_get() because once they are
> active a removal of the file cannot happen, and so removal will wait.

I doubt it.

If the module_remove() function removes sysfs nodes then (something
like) this has to happen.

1) rmmod (or similar) tries to remove the module.
2) The reference count is zero so the remove is allowed.
3) Something tries to access a sysfs node in the module.
3a) If sysfs knew the nodes were in a module it could use
    try_module_get() to ensure the module wasn't being unloaded.
    Failure would cause the sysfs access to fail.
    But I'm not sure it does, and in any case it doesn't help.
3b) The sysfs thread calls into the module code and waits on a mutex.
3c) The rmmod thread gets around to calling into sysfs to remove the nodes.

At this point we hit the standard 'deregistering a callback' issue.
Exactly the same issue affects removal of per-device sysfs node
from a driver's .remove function.

Typically this is solved by making the deregister routing sleep
until all the callbacks have completed.

So this would require functions like SYSFS_REMOVE_GROUP() and
hwmon_device_unregister() to be allowed to sleep and not be
called with any locks (of any kind) held that the callback
functions acquire.

The module reference count is irrelevant.

	David

    

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)