Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5043002pxv; Wed, 28 Jul 2021 01:30:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzp+awVJ3+OmM1g8RIkUD5mJyi8iPPJo6F7cQdHihXJcloEniQ+ggsbzQirXJUa3DoCBJd3 X-Received: by 2002:a50:fd17:: with SMTP id i23mr33040246eds.270.1627461046431; Wed, 28 Jul 2021 01:30:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627461046; cv=none; d=google.com; s=arc-20160816; b=fsPN5M4Zb18SS8UzT5HWonCoTKG7Q+3PVHVAmUAWtZEed3NazIlAbD2t/0VNeBwB6K 2NxpShE5KFQ7BUTl4kRP0bP1qI/C1QXhQZh/Jkgoteys+6vXFfs3RtG34VvSpBaAQ+yN j7tR8i5SFhQQc1VDMreS6TF7+xgFSjd7ZgbeItXszbBhs01NH/jX+iap7KW4irhD0wch aMfMQ7TL2cdba7aLx4B1rafEHOX2zYvERMt4XC5+c4XM6QYJWjnTX+y8ncpHVLgYl2DI V3g4GkiXUpZ0aLYTNKGSjBjpI2DUI+xE9cfolDNM8IWVaQ5XPDGD6F1rgMlqwbWxTgnE zPzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:accept-language:in-reply-to:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=do39f0PrmUMBT5M/DxtMxnNBHk00SNvgg/txmTynwy4=; b=bewYfQc9BfsdrF0FdlgF7XcKFq/+HhJ2kG+zvn0zeH2QNcS9AUmaVWtCJrwez5/QGi rTs/WYZ1guvKmf7KhMfbkYw7LIB1uQQoygWIxurkFclUBd3txOvhqIibovvlFEEgP8O2 NdYRFhyTmujsbLSnCAmWXW3FhkBSw6lnoO+0cV4ZLCJ0xsg2EaJeE9WEzq8SJ7xjxPLc IBbQJfwile6W7dRRjsyoEdunSLd3NC6xcffX4eDW4TRFqC8uQH2S7X21nMXoMQgcNfiW HSYenxydG7lHu3mlcR8qWKhbJA8RLAcsT2B5X4FXf/5tGwGYOKE/b7WwPiyqxKNslw3l Vv+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=aculab.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mp17si5115683ejc.449.2021.07.28.01.30.23; Wed, 28 Jul 2021 01:30:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=aculab.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235230AbhG1I2T convert rfc822-to-8bit (ORCPT + 99 others); Wed, 28 Jul 2021 04:28:19 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:31080 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235215AbhG1I2S (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-kernel@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)