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 56AC5C433EF for ; Wed, 23 Mar 2022 15:47:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A66826B0072; Wed, 23 Mar 2022 11:47:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A17BD6B0073; Wed, 23 Mar 2022 11:47:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DD9B6B0074; Wed, 23 Mar 2022 11:47:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0214.hostedemail.com [216.40.44.214]) by kanga.kvack.org (Postfix) with ESMTP id 7E3C86B0072 for ; Wed, 23 Mar 2022 11:47:09 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3255E18288A36 for ; Wed, 23 Mar 2022 15:47:09 +0000 (UTC) X-FDA: 79276079778.22.3B22903 Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by imf15.hostedemail.com (Postfix) with ESMTP id A976EA0031 for ; Wed, 23 Mar 2022 15:47:08 +0000 (UTC) Received: by mail-oi1-f177.google.com with SMTP id e189so2015839oia.8 for ; Wed, 23 Mar 2022 08:47:08 -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=B0ZfOEGucAEYJU64kilp/BJv2UxyExEyaxEs/s4tJVc=; b=McfOI6NVTS79eqz5CyeXfr9SBfkIqJhEa0udr5opLjk61INr3bGTaUeTPo+G1Txkxk 2jkpvhuxb+AwfrOb4IMMq+QTijC/1N2jeGMRVJx6eg7U8/PrpFrRY1NoUBAAVzSVjAmr FUWmjVkZnaViCt/6RTg1+omM7HqaeT2mquSC5HZ9EeOEw22Dif2bn2ukj1IkIU7jF5mi sRzoUsFzLvshNdKCfviPmwmWK6+lhE01X6dSfhA2wbn7fSWxGhJwe5W8g0jHEzLeXOvc ust5mKhKAryQqaabg93eQVUepbgPQytLijANRgPi9T156n8UaRweOHU5LOUq9mPscv7q BRzg== 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=B0ZfOEGucAEYJU64kilp/BJv2UxyExEyaxEs/s4tJVc=; b=PtBLrJy4dtY/aZNs69zVH67TxP6MJysCeRkQZnptQ2rbNSqw0hUvrsHwqnMevY0X5+ T6WscOVLTpd5t9jAaYgplsjW8gGNCILNFtDrMQ+33fypi6ZkggCvbpBg3pH4/JVhaTEu 5GjVmQ54dY5bqtWNJxYuaIwpxI0Dk0GyTanqwQFPZxYeBispgSu960kpST1hqPHOXiRv sfzSNbCUvTBJm1BhNB9RzVrh9viguzr5UsILzZfihO+caeyu9DUkaeLLNGo+o8aOXvCU YyrYXOLLo2fxvz3fcrYQq4paAcxIhoyCLsjkfRqSjcQ5kT8CUf16f89u0ftGfrtKyK8D kHKA== X-Gm-Message-State: AOAM532Lcbcz2zIsMBqYVpT9L5aw4AfFELdBGmxE0osyI6hzP9rxovPw N+q9iv3Wzh7sYjFpF74TlUdsap3dbkPdajSQkKg= X-Google-Smtp-Source: ABdhPJxEOLGEqeY4vJj2jFkOckWeF8KjTYyMs+8a3W7Gk4rdAtpuroIGtzMOGiJB4PpJhd7zdCvE0dC6Zc3CZxckckI= X-Received: by 2002:a05:6808:23c1:b0:2da:30fd:34d9 with SMTP id bq1-20020a05680823c100b002da30fd34d9mr4899106oib.203.1648050427956; Wed, 23 Mar 2022 08:47:07 -0700 (PDT) MIME-Version: 1.0 References: <20220321112310.vpr7oxro2xkz5llh@quack3.lan> <20220321145111.qz3bngofoi5r5cmh@quack3.lan> <20220323104129.k4djfxtjwdgoz3ci@quack3.lan> <20220323134851.px6s4i6iiaj4zlju@quack3.lan> <20220323142835.epitipiq7zc55vgb@quack3.lan> In-Reply-To: <20220323142835.epitipiq7zc55vgb@quack3.lan> From: Amir Goldstein Date: Wed, 23 Mar 2022 17:46:56 +0200 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" X-Stat-Signature: tk15a3nf68hnffrf88o17qpf1gckj7uq Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=McfOI6NV; spf=pass (imf15.hostedemail.com: domain of amir73il@gmail.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A976EA0031 X-HE-Tag: 1648050428-811360 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 Wed, Mar 23, 2022 at 4:28 PM Jan Kara wrote: > > On Wed 23-03-22 16:00:30, Amir Goldstein wrote: > > > Well, but reclaim from kswapd is always the main and preferred source of > > > memory reclaim. And we will kick kswapd to do work if we are running out of > > > memory. Doing direct filesystem slab reclaim from mark allocation is useful > > > only to throttle possibly aggressive mark allocations to the speed of > > > reclaim (instead of getting ENOMEM). So I'm still not convinced this is a > > > big issue but I certainly won't stop you from implementing more fine > > > grained GFP mode selection and lockdep annotations if you want to go that > > > way :). > > > > Well it was just two lines of code to annotate the fanotify mutex as its own > > class, so I just did that: > > > > https://github.com/amir73il/linux/commit/7b4b6e2c0bd1942cd130e9202c4b187a8fb468c6 > > But this implicitely assumes there isn't any allocation under mark_mutex > anywhere else where it is held. Which is likely true (I didn't check) but > it is kind of fragile. So I was rather imagining we would have per-group > "NOFS" flag and fsnotify_group_lock/unlock() would call > memalloc_nofs_save() based on the flag. And we would use > fsnotify_group_lock/unlock() uniformly across the whole fsnotify codebase. > I see what you mean, but looking at the code it seems quite a bit of churn to go over all the old backends and convert the locks to use wrappers where we "know" those backends are fs reclaim safe (because we did not get reports of deadlocks over the decades they existed). I think I will sleep better with a conversion to three flavors: 1. pflags = fsnotify_group_nofs_lock(fanotify_group); 2. fsnotify_group_lock(dnotify_group) => WARN_ON_ONCE(group->flags & FSNOTIFY_NOFS) mutex_lock(&group->mark_mutex) 3. fsnotify_group_lock_nested(group) => mutex_lock_nested(&group->mark_mutex, SINGLE_DEPTH_NESTING) Thoughts? One more UAPI question. Do you think we should require user to opt-in to NOFS and evictable marks with FAN_SHRINKABLE? If we don't, it will be harder to fix regressions in legacy fanotify workloads if those are reported without breaking the evictable marks UAPI. Thanks, Amir.