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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ