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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76BFBC61DA4 for ; Fri, 3 Feb 2023 17:45:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14CC66B0071; Fri, 3 Feb 2023 12:45:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FD506B0074; Fri, 3 Feb 2023 12:45:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2DE56B0078; Fri, 3 Feb 2023 12:45:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E11D86B0071 for ; Fri, 3 Feb 2023 12:45:55 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B5FE9805A8 for ; Fri, 3 Feb 2023 17:45:54 +0000 (UTC) X-FDA: 80426708628.23.B12864E Received: from out-229.mta0.migadu.com (out-229.mta0.migadu.com [91.218.175.229]) by imf06.hostedemail.com (Postfix) with ESMTP id 776D2180020 for ; Fri, 3 Feb 2023 17:45:52 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=O7RvhPr6; spf=pass (imf06.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.229 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675446352; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=If6qMCH+MeO2e7BB/5ZAKXFEX/HC4bkB0xMZK67fLA8=; b=3LVdhYxPfqcNSN3Oco/y3o40zReLNBFWttcie+pJmH+rJrlHM0bBJONASkN86vhnveld5G fzttNIjUuCwvBHeapH7Nialum9HGwSd4iARx8T7raD/w8M5/SBHhWg/kI4t/NRU3tJVuL4 HORCwO+rr8C1T7LhD2qeKAcVtkQ4trU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=O7RvhPr6; spf=pass (imf06.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.229 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675446352; a=rsa-sha256; cv=none; b=uQ1OpivxsntUzz2BrfBtAy6m0KUuXtuEiiYGiI2sHfm0qekO9I/MSKhDbi59qQOLzEJEMG tGlKa+JALV/GnOjwzdvejTs6TpPR6GKetOfeXiqAgqWcmhfQV0n3aAx05/b3Y0yi6kkaWf RGmSWtgsztrSusXhp+as150jNL+MhTg= Date: Fri, 3 Feb 2023 09:45:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1675446351; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=If6qMCH+MeO2e7BB/5ZAKXFEX/HC4bkB0xMZK67fLA8=; b=O7RvhPr6/35tirAqMZ5Lt0K+gb9yokE+lCl/n5MKZWLzZwvcP/mayCFCB9G1VDZmkP2wGk 8Mo1nOL4/oxPII9d6kWT/1gbFgBZwAxuirBs9tZ8u6sNu4x73iMT2RvjGAfTMcIJ55Crqm aTcn4yvLVHM4JisnOgpagP9Lj5RJnbY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Qi Zheng Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: shrinkers: fix deadlock in shrinker debugfs Message-ID: References: <20230202105612.64641-1-zhengqi.arch@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230202105612.64641-1-zhengqi.arch@bytedance.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 776D2180020 X-Stat-Signature: r3ubctf8bgr1rnosswm4p38pmex3isxc X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675446352-512272 X-HE-Meta: U2FsdGVkX1/drzEhn39agSHWKv408uMtc2GVRJ5a36lvRSj1m7vR5hkYdxPjNv/W2JXUU5+UQ9luI/7vblFix8x/Er2mm+I5c9tkTHeGq2g+IxjL45fZJe4FAlBcwLNGLj1cL5jTULnk7NfT6vtRzMU0XNZWPs1gEUH/KCtWR2k2u23bwUeAddHjEEwlV3vTsEVUC9X9gUIoMwHYr2D8IEXo/0VAkZJi6KM8d/OD9QTM+UHihJHOyBES6Y2be2DbkdqSGXfCkMkJ88G2J15S2VlrBpd3jD5ZYKrsP2M9tRxTUNNJH9qfxqkUvHc82pwgGE+kHrqyRLeZU4T+4xjQNFLgXsk+QyQvke8f2VLxIlzZ/8KxNucusys8pS5zbFYrt+3jq2TdnxjAPlnva3tsAOrkB17ywzrw9rygt3vNtXs0TWa//riThKtC9ozD/cGcgCXa4pM91zLb2eTr9Yio73RRR5hDxzEt8x+ddLpaEiaANbEa3lv+jPaMV40VOXw+Iw8WOKo94AKs2VKEmBjVKzMQe5FLpdTur8WQhhYKLKFT/IaYf5u38WmlaWChIoeEZT3OKw+xfn7uaCBkFKnflUSSGXijNEFPkdBJMrKlo1DV8lmnIRgWSHE7OYs1QptAWuVbs2Ar6trD0f5W5XKrUxCACx1ar7w1QDBqJ/BQ7vVZvpLqbm0CE4y+0CH6+/ZkHHc3H7QamWpLfAt3s+nMaf091wMsL8IxVDVla5FrEYYXqi+l2Pjgj1VePVzHRibasXjB6DrgNPAocvXoYuy5icWlywMBp3UpvQwlsk2A+No7f+lcGiqU/RAwB3bWwy4kk/398uoB7l7kyxZsYlyVDRSqZVbJXduc451NQgw+gNu7lB33EdeCGCfBrXj5VMVwd4BY/3RA3+LF5BVh1gzJlY9eeimq6ekCzX/xf+V6IHg81M8NfazoSFmWrE1u9smX+yTur1JJYtDLxS5EpP/ vbVh5jfv 33P5pZVGcAeb3BYW0h8mKKZj9eoc10ZN3MTlsgYOdYVYOBW5mAcr/DBY5mU1LTsXdFvEC5KoxUJIcFV8hWRQL8XR3+SKspVr/ndgpHaQn7A/Iz43Gs4FKsLDaa9JJWs6a40VaQQEvsVMx3M0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 02, 2023 at 06:56:12PM +0800, Qi Zheng wrote: > The debugfs_remove_recursive() is invoked by unregister_shrinker(), > which is holding the write lock of shrinker_rwsem. It will waits > for the handler of debugfs file complete. The handler also needs > to hold the read lock of shrinker_rwsem to do something. So it > may cause the following deadlock: > > CPU0 CPU1 > > debugfs_file_get() > shrinker_debugfs_count_show()/shrinker_debugfs_scan_write() > > unregister_shrinker() > --> down_write(&shrinker_rwsem); > debugfs_remove_recursive() > // wait for (A) > --> wait_for_completion(); > > // wait for (B) > --> down_read_killable(&shrinker_rwsem) > debugfs_file_put() -- (A) > > up_write() -- (B) > > The down_read_killable() can be killed, so that the above deadlock > can be recovered. But it still requires an extra kill action, > otherwise it will block all subsequent shrinker-related operations, > so it's better to fix it. Oh, indeed, great catch! With Andrew's fixup: Reviewed-by: Roman Gushchin Thank you!