Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2383108pxb; Mon, 20 Sep 2021 20:54:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXKODYosirq+fhm/iAU9OcPZtbQLjqWB4r+3bFDe2844NAoUUVJ/MK5k8VFlewCQvcxPLm X-Received: by 2002:a17:906:c52:: with SMTP id t18mr32276393ejf.148.1632196484020; Mon, 20 Sep 2021 20:54:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632196484; cv=none; d=google.com; s=arc-20160816; b=NRF8vLR+kjje3aw+Bx2IL7/kPJ2QpMvpOrxbgkAsJCKRZJmk71a5J7F1d9+GzQfJVV cQSiF4N1aTh4Nfj/eNbb6X/oFS1Fcr4P+RBW1JLlqPRQfQ2OmygZl/e/aOpLtzJqzMmg v5cQ7gfIWH/oXmRUVoVIhNx3ylT6criXgKWHB/5tet8ZXWN2Oo44qUQQfCqFq7ecZbt+ Wyo4Mjrij+iRKx+GU+pZyTuTcDqklDvuu9tq4FcmnxHr2MYhAnhjaPfdwTUpdXxYukVz 9QY2u3WuLt4Uu9iQ7OMo0NWbkG6AXhquakt+p1ijzJ4gYhPycx5qqnj9Cq+nb6ymaNMf 0erQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=qVmGn1sB2+Ujqg7/u2BgWKG/M74nLAjBwZQeoBTm6k4=; b=VhUpfQTpKt9taleghIJT0WVijIjexs1Ewn+ZmGFhgcN3E3HFTxWMTFxT9rkPh5X6Vo kB/7JXcs/aed5KjKCkAf/x8IPVBbW0DxE8It2ZGNnF/vi2RVhragDJsKr+6oqihZ45Mz XcLfwxUnAC8qYiZ4mJQCOTaEXU4CeIWa/jptt4gv2xP7xhgpy8t+foedrLm4X8DXxtLX vlB6sb/Ss2TgGadhdt2nyL1tCVxr/P22OMBf7TXKmy2zD4n3UO8QOUrS8iInruiK0TKJ uU/8j8meUWOjE1vIC3lIB9VQHfa72/2fM50Va4W6IFb9RQFiEP7SPuBuryJoYLumKuBG 2XiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=n2OSSolk; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hq41si10209854ejc.471.2021.09.20.20.54.20; Mon, 20 Sep 2021 20:54:44 -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; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=n2OSSolk; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233255AbhIUBl6 (ORCPT + 99 others); Mon, 20 Sep 2021 21:41:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232048AbhIUBjK (ORCPT ); Mon, 20 Sep 2021 21:39:10 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BC88C125F90; Mon, 20 Sep 2021 12:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=qVmGn1sB2+Ujqg7/u2BgWKG/M74nLAjBwZQeoBTm6k4=; b=n2OSSolklt7gOYko3iITzFkPyC 0CFZmnl1pIhaRTm5YGVOzTbvRlCC/5cbJo6Ol5dXncFos6LOkeVEHLM2n+RzZEn05VnTKrq3zRWzU XDWlcRZQv+COitTH6USEtWmqcFGeK1vFJZ3+qDzVy3ZT5JivVC2bgCRk+JDE2V/ndiijQRC9gq9TM wAdJ6bsCsa+zWJT6BzVz7DVLWlV3w9BDPq9VkZFJbjaXUJupVY1vq3XYUHtOJ2Zie/nuGNE/RNHOI I95WQELiKoXkadSIaUtm+tDhfcClRPWgG9P9yXMv0rjhNcG8v2yzd/k9dv1zwPaZV0rcYjNrJrQTT wax8de8w==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSP77-002wrK-SH; Mon, 20 Sep 2021 19:38:05 +0000 Date: Mon, 20 Sep 2021 12:38:05 -0700 From: Luis Chamberlain To: Tejun Heo Cc: gregkh@linuxfoundation.org, akpm@linux-foundation.org, minchan@kernel.org, jeyu@kernel.org, shuah@kernel.org, rdunlap@infradead.org, rafael@kernel.org, masahiroy@kernel.org, ndesaulniers@google.com, yzaikin@google.com, nathan@kernel.org, ojeda@kernel.org, penguin-kernel@i-love.sakura.ne.jp, vitor@massaru.org, elver@google.com, jarkko@kernel.org, glider@google.com, rf@opensource.cirrus.com, stephen@networkplumber.org, David.Laight@aculab.com, bvanassche@acm.org, jolsa@kernel.org, andriy.shevchenko@linux.intel.com, trishalfonso@google.com, andreyknvl@gmail.com, jikos@kernel.org, mbenes@suse.com, ngupta@vflare.org, sergey.senozhatsky.work@gmail.com, reinette.chatre@intel.com, fenghua.yu@intel.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, lizefan.x@bytedance.com, hannes@cmpxchg.org, daniel.vetter@ffwll.ch, bhelgaas@google.com, kw@linux.com, dan.j.williams@intel.com, senozhatsky@chromium.org, hch@lst.de, joe@perches.com, hkallweit1@gmail.com, axboe@kernel.dk, jpoimboe@redhat.com, tglx@linutronix.de, keescook@chromium.org, rostedt@goodmis.org, peterz@infradead.org, linux-spdx@vger.kernel.org, linux-doc@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, copyleft-next@lists.fedorahosted.org Subject: Re: [PATCH v7 09/12] sysfs: fix deadlock race with module removal Message-ID: References: <20210918050430.3671227-1-mcgrof@kernel.org> <20210918050430.3671227-10-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 20, 2021 at 09:22:32AM -1000, Tejun Heo wrote: > On Mon, Sep 20, 2021 at 12:15:22PM -0700, Luis Chamberlain wrote: > > > Right, the reason I mention the alternative is that we technically don't > > need to use try in this case since during a kernfs op it is implied the > > module will be pinned, but we have further motivations to use a try > > I'm confused. If the module is already pinned, why are we getting an > extra reference? Sorry, I meant its pinned implicitly not through an actual refcount. A module exit can happen then in that case, it just that the sysfs removal will have to wait until the active reference for the kernfs ops go down. > Also, I don't understand how this has that much to do > with preventing ddoses. I mean, it does cut down the duration of one > operation but the eventual gating is through whoever acquiring the > initial reference through try_module_get(), which again is the *only* > way to acquire a fresh reference. True. I can just leave that out from the commit log. But it is perhaps an implicit gain here that using try alows module exit to trump use of an kernfs op. Maybe's that's sufficient to mention. Luis