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 18AB9C433F5 for ; Sun, 27 Mar 2022 18:15:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2406F8D0001; Sun, 27 Mar 2022 14:15:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F18A6B0073; Sun, 27 Mar 2022 14:15:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 092898D0001; Sun, 27 Mar 2022 14:15:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id EB5CC6B0071 for ; Sun, 27 Mar 2022 14:15:12 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BB82AAD3 for ; Sun, 27 Mar 2022 18:15:12 +0000 (UTC) X-FDA: 79290968064.09.DEBF9DB Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf17.hostedemail.com (Postfix) with ESMTP id EDBDC4003D for ; Sun, 27 Mar 2022 18:15:11 +0000 (UTC) Received: by mail-qt1-f180.google.com with SMTP id d15so10616530qty.8 for ; Sun, 27 Mar 2022 11:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xzh21Ro6IEaZ5p55vH/LLx6bOR50txHPSwPIloDfM0c=; b=S2QLdptwVR+e1f9C7KEJNO12yiHPDUOmfaVLlI+rGVxqgvPQtkrifHShz5Xi4eUFtt OIgwb02KOVVGhUAr8NcvxTdGXiCLfbe9cRPP74UUm6Shta48y3A4Ga5lKVFjEcnd/72z A3bR3+f6wLftmUAUJEubJrBlukd+BIRQ9CWOynwfWsKDtZ9zHVb7aBuaitTSyVL9aVrO d7uzOkuDGypU1WXlDT53cnwUQt20s9tEsmZOBbwaaQn9JlitQzlFVZohvRV6N0KoxAQA wUY4IdI7tfF2eRjoNGcasmBSrN8TGN9imUH/sVHtQebzm5NEgOYc9DpvCUNe/EbIgQpP 8UsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xzh21Ro6IEaZ5p55vH/LLx6bOR50txHPSwPIloDfM0c=; b=jzvaajQv3wV3h9IgXrIDOOWmnGJakwU2LJrIbpnBdj0Av01pdA5MUl7zQMnE3rz8qI /e9PGgNOEFCnCNE0+XKDn8/vGaPQdzE/z2VCy/1c6NgyKyiEBhfBC78SoruS8uTRh5sv aZfKhhOwjAacMtkKgmaGWKJeqWOK+15eUyfKFzy/kOYMm9WFh79taZTtNqr2TVcCOh1u u12LCu7a49P7Mz0OVuHARPlUPsw2jrSHOq1G3NOoUDfGcV3Nb2pfjj13l4n+fM3+zNVW NTCZ32rjl6pJoirL/nBKuL47E90VAn6NuK++9vZ4i0/oogCMLB149cc6jVz8yH/7t+iy Kbog== X-Gm-Message-State: AOAM530G7pJ4xYNP10q/fWzPj59UIfEY4Z7WeItlWJgYis4gqoIMdhmq APeG5LirlWgAh73OPVVVX3TJEaSdtCfexHSV5Wg= X-Google-Smtp-Source: ABdhPJwgOksmRTAiMobQcjPhf6FYRXAJCcSbk0siks775H89KdKS2FPWFtS1oUoPN/QNWkg13Hju07LL9sse0UzroAE= X-Received: by 2002:a05:622a:18a4:b0:2e1:e7a5:98ba with SMTP id v36-20020a05622a18a400b002e1e7a598bamr18587078qtc.424.1648404911251; Sun, 27 Mar 2022 11:15:11 -0700 (PDT) MIME-Version: 1.0 References: <20220321145111.qz3bngofoi5r5cmh@quack3.lan> <20220323104129.k4djfxtjwdgoz3ci@quack3.lan> <20220323134851.px6s4i6iiaj4zlju@quack3.lan> <20220323142835.epitipiq7zc55vgb@quack3.lan> <20220325092911.fnttlyrvw7qzggc7@quack3.lan> In-Reply-To: <20220325092911.fnttlyrvw7qzggc7@quack3.lan> From: Amir Goldstein Date: Sun, 27 Mar 2022 21:14:59 +0300 Message-ID: Subject: Re: [PATCH RFC] nfsd: avoid recursive locking through fsnotify To: Jan Kara Cc: "khazhy@google.com" , "linux-mm@kvack.org" , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=S2QLdptw; spf=pass (imf17.hostedemail.com: domain of amir73il@gmail.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EDBDC4003D X-Stat-Signature: z4tc9mqnm435x3fktajgptpukyqn6c4q X-HE-Tag: 1648404911-860330 X-Bogosity: Ham, tests=bogofilter, spamicity=0.003236, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > > I think I might have misunderstood you and you meant that the > > SINGLE_DEPTH_NESTING subcalls should be eliminated and then > > we are left with two lock classes. > > Correct? > > Yeah, at least at this point I don't see a good reason for using > SINGLE_DEPTH_NESTING lockdep annotation. In my opinion it has just a > potential of silencing reports of real locking problems. So removing it and > seeing what complains would be IMO a way to go. > Agreed. In fact, the reason it was added is based on a misunderstanding of mutex_lock_nested(): Commit 6960b0d909cd ("fsnotify: change locking order") changed some of the mark_mutex locks in direct reclaim path to use: mutex_lock_nested(&group->mark_mutex, SINGLE_DEPTH_NESTING); This change is explained: "...It uses nested locking to avoid deadlock in case we do the final iput() on an inode which still holds marks and thus would take the mutex again when calling fsnotify_inode_delete() in destroy_inode()." Pushed the fix along with conversion of all backends to fsnotify_group_lock() to fan_evictable branch, which I am still testing. It's worth noting that I found dnotify to be not fs reclaim safe, because dnotify_flush() is called from any filp_close() (problem is explained in the commit message), which contradicts my earlier argument that legacy backends "must be deadlock safe or we would have gotten deadlock reports by now". So yeh, eventually, we may set all legacy backends NOFS, but I would like to try and exempt inotify and audit for now to reduce the chance of regressions. Thanks, Amir.