From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04378C4338F for ; Wed, 28 Jul 2021 08:28:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D486360FE4 for ; Wed, 28 Jul 2021 08:28:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235286AbhG1I2T convert rfc822-to-8bit (ORCPT ); Wed, 28 Jul 2021 04:28:19 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:20133 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234495AbhG1I2S (ORCPT ); Wed, 28 Jul 2021 04:28:18 -0400 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-11-xmCxCxZxO7ayZHiHESiNOw-1; Wed, 28 Jul 2021 09:28:14 +0100 X-MC-Unique: xmCxCxZxO7ayZHiHESiNOw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 28 Jul 2021 09:28:11 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.023; Wed, 28 Jul 2021 09:28:11 +0100 From: David Laight To: 'Luis Chamberlain' , "gregkh@linuxfoundation.org" CC: "tj@kernel.org" , "shuah@kernel.org" , "akpm@linux-foundation.org" , "rafael@kernel.org" , "davem@davemloft.net" , "kuba@kernel.org" , "ast@kernel.org" , "andriin@fb.com" , "daniel@iogearbox.net" , "atenart@kernel.org" , "alobakin@pm.me" , "weiwan@google.com" , "ap420073@gmail.com" , "jeyu@kernel.org" , "ngupta@vflare.org" , "sergey.senozhatsky.work@gmail.com" , "minchan@kernel.org" , "axboe@kernel.dk" , "mbenes@suse.com" , "jpoimboe@redhat.com" , "tglx@linutronix.de" , "keescook@chromium.org" , "jikos@kernel.org" , "rostedt@goodmis.org" , "peterz@infradead.org" , "linux-block@vger.kernel.org" , "netdev@vger.kernel.org" , Douglas Gilbert , "Hannes Reinecke" , "linux-kselftest@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] kernel/module: add documentation for try_module_get() Thread-Topic: [PATCH] kernel/module: add documentation for try_module_get() Thread-Index: AQHXf0eaxD6lEmY4bU6QViNa8xuU1KtSAuiAgAVRuyeAALu/4A== Date: Wed, 28 Jul 2021 08:28:11 +0000 Message-ID: <6054c136290346d581e276abbb2e3ff1@AcuMS.aculab.com> References: <20210722221905.1718213-1-mcgrof@kernel.org> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org ... > 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)