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 07396C433F5 for ; Tue, 22 Mar 2022 22:41:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C6BC6B007B; Tue, 22 Mar 2022 18:41:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 875B46B007D; Tue, 22 Mar 2022 18:41:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7166B6B0085; Tue, 22 Mar 2022 18:41:41 -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 6352D6B007B for ; Tue, 22 Mar 2022 18:41:41 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 13EC560F77 for ; Tue, 22 Mar 2022 22:41:41 +0000 (UTC) X-FDA: 79273495602.11.04F9F72 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf15.hostedemail.com (Postfix) with ESMTP id D48F7A0026 for ; Tue, 22 Mar 2022 22:41:40 +0000 (UTC) Received: by mail-oi1-f169.google.com with SMTP id 12so20994020oix.12 for ; Tue, 22 Mar 2022 15:41:40 -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=HEQg0eIGwGGy7PpGy1QT39r4icNZYKU8XYDsqIK8MEo=; b=WjQK6LWvSPRm4oItSaTP3KQWI2i/rktQSvBtG3YzMucSkLebD5GyAAqfr2RF29lgH6 lnQZfU9WmXhNtv+HhMJERNhMgeag63HgqJHrJuxeYkal7DosSOc6CNC6sX6dGtW5BFmH AI5GjeFHP71CYLdk2rkR4/MH41xzQGTx8jfjXKuRXOaz8rXHgP0/vyhkIQPPWCIeFrtE GmOOUOS+OjXpzfPhY8pw20xglFIVfvt+y0hUlsYxHmw9ZyGjt8GjguvPTn1Wgh1ZvzE5 XJkP59kXnt9Nk5dR2XjZX3ACO7s5K12INhPWBTUHSnCxxQIzrgvCX2TSd9aXIOJ2w1On BkdQ== 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=HEQg0eIGwGGy7PpGy1QT39r4icNZYKU8XYDsqIK8MEo=; b=lI6LJ2UiN/oypTbVHVnkGI5azl4aGrdgp2LvAb7pH1jS9tD+zPmXGWnvLeJkL9vDQ3 v1Dtao2na82P+1fehze61zbDDpQ5TB2ZK0mWGM9H4TCQCGJurMvFMY2mUR9Efle9cQ2y LUTt6nzdv2tlrUWeV1YVP/zF4GKEgJVbZFn50tgTWgfM7jO2mBc6eYG1RrF5eo6cShxi rBtQg5YWM+xIbg6wJAkLD5z9decOXwoVIQXwiigIEjZJDg/gRDLSOvWjG5777SXb7fMh BI+xYme44pLlMIEuCK2WCA5z3IkxJwuwafIfmzil1h3IREEcFk3VdaB9DPXxDKEe29Pt bXHQ== X-Gm-Message-State: AOAM5300+F0ciHiw2FmfnIqzu6H2H0903ZMD3M+wg0T7pt0VTUTbtKZT k8nL65d6U7GComP5M836+tHEdhvzLnibrMPEMIY= X-Google-Smtp-Source: ABdhPJyfMifeHdylVS0avluM+oj2A3TiLGM84y54zrr0W4JsEY0sapqA5cP/gfy6DMSaBH0ObCzwbgGlRMVEiIJi36g= X-Received: by 2002:a05:6808:23c1:b0:2da:30fd:34d9 with SMTP id bq1-20020a05680823c100b002da30fd34d9mr3282226oib.203.1647988900195; Tue, 22 Mar 2022 15:41:40 -0700 (PDT) MIME-Version: 1.0 References: <20220319001635.4097742-1-khazhy@google.com> <20220321112310.vpr7oxro2xkz5llh@quack3.lan> <20220321145111.qz3bngofoi5r5cmh@quack3.lan> In-Reply-To: <20220321145111.qz3bngofoi5r5cmh@quack3.lan> From: Amir Goldstein Date: Wed, 23 Mar 2022 00:41:28 +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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D48F7A0026 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WjQK6LWv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of amir73il@gmail.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=amir73il@gmail.com X-Stat-Signature: psrn1ymt8fgmj1xzcor9649s31qwo6my X-HE-Tag: 1647988900-99027 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000014, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > > > So the cleanest solution I currently see is > > > to come up with helpers like "fsnotify_lock_group() & > > > fsnotify_unlock_group()" which will lock/unlock mark_mutex and also do > > > memalloc_nofs_save / restore magic. > > > > > > > Sounds good. Won't this cause a regression - more failures to setup new mark > > under memory pressure? > > Well, yes, the chances of hitting ENOMEM under heavy memory pressure are > higher. But I don't think that much memory is consumed by connectors or > marks that the reduced chances for direct reclaim would really > substantially matter for the system as a whole. > > > Should we maintain a flag in the group FSNOTIFY_GROUP_SHRINKABLE? > > and set NOFS state only in that case, so at least we don't cause regression > > for existing applications? > > So that's a possibility I've left in my sleeve ;). We could do it but then > we'd also have to tell lockdep that there are two kinds of mark_mutex locks > so that it does not complain about possible reclaim deadlocks. Doable but > at this point I didn't consider it worth it unless someone comes with a bug > report from a real user scenario. Are you sure about that? Note that fsnotify_destroy_mark() and friends already use lockdep class SINGLE_DEPTH_NESTING, so I think the lockdep annotation already assumes that deadlock from direct reclaim cannot happen and it is that assumption that was nearly broken by evictable inode marks. IIUC that means that we only need to wrap the fanotify allocations with GFP_NOFS (technically only after the first evictable mark)? Thanks, Amir.