Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i53a843ae:Fastmail
From:   Nikolaus Rath <Nikolaus@rath.org>
To:     Miklos Szeredi via fuse-devel <fuse-devel@lists.sourceforge.net>
Cc:     Askar Safin <safinaskar@gmail.com>,
        Miklos Szeredi <miklos@szeredi.hu>, linux-pm@vger.kernel.org,
        Bernd Schubert <bernd.schubert@fastmail.fm>,
        linux-kernel@vger.kernel.org, Luis Chamberlain <mcgrof@kernel.org>,
        linux-fsdevel@vger.kernel.org
Subject: Re: [fuse-devel] [PATCH 0/6] vfs: provide automatic kernel freeze /
 resume
References: <CAPnZJGDWUT0D7cT_kWa6W9u8MHwhG8ZbGpn=uY4zYRWJkzZzjA@mail.gmail.com>
        <CAJfpeguZX5pF8-UNsSfJmMhpgeUFT5XyG_rDzMD-4pB+MjkhZA@mail.gmail.com>
Mail-Copies-To: never
Mail-Followup-To: Miklos Szeredi via fuse-devel
        <fuse-devel@lists.sourceforge.net>, Askar Safin
        <safinaskar@gmail.com>, Miklos Szeredi <miklos@szeredi.hu>,
        linux-pm@vger.kernel.org, Bernd Schubert <bernd.schubert@fastmail.fm>,
        linux-kernel@vger.kernel.org, Luis Chamberlain <mcgrof@kernel.org>,
        linux-fsdevel@vger.kernel.org
Date:   Tue, 06 Jun 2023 20:37:29 +0100
In-Reply-To: <CAJfpeguZX5pF8-UNsSfJmMhpgeUFT5XyG_rDzMD-4pB+MjkhZA@mail.gmail.com>
        (Miklos Szeredi via fuse-devel's message of "Tue, 6 Jun 2023 16:37:51
        +0200")
Message-ID: <871qiopekm.fsf@vostro.rath.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Jun 06 2023, Miklos Szeredi via fuse-devel <fuse-devel@lists.sourceforge=
.net> wrote:
> On Sun, 14 May 2023 at 00:04, Askar Safin <safinaskar@gmail.com> wrote:
>>
>> Will this patch fix a long-standing fuse vs suspend bug? (
>> https://bugzilla.kernel.org/show_bug.cgi?id=3D34932 )
>
> No.
>
> The solution to the fuse issue is to freeze processes that initiate
> fuse requests *before* freezing processes that serve fuse requests.
>
> The problem is finding out which is which.  This can be complicated by
> the fact that a process could be both serving requests *and*
> initiating them (even without knowing).
>
> The best idea so far is to let fuse servers set a process flag
> (PF_FREEZE_LATE) that is inherited across fork/clone.

Is that the same as what userspace calls PR_SET_IO_FLUSHER? From
prctl(2):

   PR_SET_IO_FLUSHER (since Linux 5.6)
          If a user process is involved in the block layer or filesystem I/=
O  path,  and
          can allocate memory while processing I/O requests it must set arg=
2 to 1.  This
          will put the process in the IO_FLUSHER state, which allows it  sp=
ecial  treat=E2=80=90
          ment  to make progress when allocating memory. [..]

          The calling process must have the CAP_SYS_RESOURCE capability.[..=
.]

          Examples  of  IO_FLUSHER  applications are FUSE daemons, SCSI dev=
ice emulation
          daemons, and daemons that perform error handling like multipath p=
ath  recovery
          applications.
=20=20=20=20=20=20=20=20=20=20

To me this sounds like it captures the relevant information (process is
involved in filesystem I/O) rather than just a preferred behavior (flush
late) and may thus be a better choice...

Best,
-Nikolaus