Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp183046imw; Mon, 4 Jul 2022 07:21:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vUaFQ8wJbqKFgu9bTErT0+FOjlyhEbMFL6nUueGixAyFcSG6W5DWIhpnKNsoYroomvrkim X-Received: by 2002:a17:906:99c5:b0:6ff:4c8f:6376 with SMTP id s5-20020a17090699c500b006ff4c8f6376mr29109695ejn.328.1656944477748; Mon, 04 Jul 2022 07:21:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656944477; cv=none; d=google.com; s=arc-20160816; b=KV64x3k4FBSP/lQJaJAjvOHy9unQ0Kbb1sRugxdT4gW+xaSEHZK3nxgvOHqmvJPHm0 VJB4lYa2Kr4fjRbaQAY8oOg8KOJPe6x31ZWlcjQbx5+RsemjkEKs/LAPl+3wfTmdScO9 +XPltr5xOPe03oCZc0HXfdNlSM7VhVZAGK+cFcNsEa75J//JWkeEzTitvq1x45ox7x4l A8qBZdlntjE0n0SmjKNF5rdIza6ZHWQO3CR23TckTg4JiS5ri5G7D1QFOn2AffkDa6EK IhAT2KeQGSlBXMRqKzxVsW2yAjViMJWDW/sc9Qk4qPScVbK2y5QvIXzInpty/OjiciBo o3mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=7GvoSlVN5eJU+HkChfyNeYXQ+WZcPQdrb9YCZm8SCAI=; b=sb6psV3BjJOp897cTNRAomsqOJy6na9M6TcFBDMaw/CFRZashLTTKPh/DrTSK+Dxgb z04MDKtSjDzKR0bVc5f9KuVtmlrgnhf0XSx4YzqIrTN89Ed3WmKSauLd7pXS3dBvdCKF svsiXegk7I5XevkmzmXEkE2ALiHTLm9tnE4Xc3l1ANUSjiX1A2Gk0suHbpOjBzQsYb0u OjPKaAH2A/Dih3OHkCXesY00BWadMjhuqCej8c57TXkKdBnRFF99pVaA8qhRtssZyMH2 IMNdY+rVy00Wd/Ltcw1idoSMh1WghXz4NrALoJgoDoTfJcZ5Mu/Ylf1VgVfluFH09/nf 43TA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ef14-20020a05640228ce00b0043a6d0eed24si1807233edb.249.2022.07.04.07.20.52; Mon, 04 Jul 2022 07:21:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234592AbiGDOI0 (ORCPT + 99 others); Mon, 4 Jul 2022 10:08:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234507AbiGDOIW (ORCPT ); Mon, 4 Jul 2022 10:08:22 -0400 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FDA6184 for ; Mon, 4 Jul 2022 07:08:19 -0700 (PDT) Received: from fsav113.sakura.ne.jp (fsav113.sakura.ne.jp [27.133.134.240]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 264E7v25049441; Mon, 4 Jul 2022 23:07:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav113.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav113.sakura.ne.jp); Mon, 04 Jul 2022 23:07:57 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav113.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 264E7vm9049438 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Jul 2022 23:07:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <951dd1a9-2b48-fb0c-9ee2-aac2b8170c2c@I-love.SAKURA.ne.jp> Date: Mon, 4 Jul 2022 23:07:54 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] char: misc: make misc_open() and misc_register() killable Content-Language: en-US To: Wedson Almeida Filho Cc: Greg KH , "Rafael J. Wysocki" , Len Brown , Pavel Machek , arnd@arndb.de, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org References: <000000000000d9ff3a05bb37069e@google.com> <72e74af9-f1b6-e383-a2c3-6ee8a0aea5e0@I-love.SAKURA.ne.jp> <100f445e-9fa8-4f37-76aa-8359f0008c59@I-love.SAKURA.ne.jp> <01a93294-e323-b9ca-7e95-a33d4b89dc47@I-love.SAKURA.ne.jp> <19598d43-de61-c663-25e8-17b6f5d5ef80@I-love.SAKURA.ne.jp> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/07/04 22:57, Wedson Almeida Filho wrote: > On Mon, Jul 04, 2022 at 10:48:32PM +0900, Tetsuo Handa wrote: >> On 2022/07/04 21:59, Wedson Almeida Filho wrote: >>>> @@ -139,6 +139,10 @@ static int misc_open(struct inode *inode, struct file *file) >>>> >>>> err = 0; >>>> replace_fops(file, new_fops); >>>> + if (iter->unlocked_open && file->f_op->open) { >>>> + mutex_unlock(&misc_mtx); >>>> + return file->f_op->open(inode, file); >>>> + } >>> >>> One of the invariants of miscdev is that once misc_deregister() returns, >>> no new calls to f_op->open() are made. (Although, of course, you can >>> still have open files but that's a whole different problem.) >> >> The point of this change is that file->f_op after mutex_unlock(&misc_mtx) is >> from new_fops which is guaranteed to hold a ref on "struct file_operations" >> via new_fops = fops_get("struct miscdevice"->fops). >> That is, a module ref remains valid even after mutex_unlock(&misc_mtx). >> >> And as with major_names_lock case quoted below, this change assumes that >> misc_deregister() is called from module's __exit function, and fops_get() >> is preventing the module owning new_fops from calling __exit function. > > Your assumption is not sound. misc_deregister() can be (and is) > legitimately called from other places, for example, a driver's remove() > callback. In fact, when I grep for misc_deregister(), the second > instance is such a case. OK, the frequency of calling misc_deregister() can be much higher than unregister_blkdev(), which means that misc_mtx is more prone to trigger hung task warnings. I'm more inclined to avoid sleeping with misc_mtx held.