linux-kernel - Re: [RFC PATCH 0/9] fuse: API for Checkpoint/Restore

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d20393b4-017e-19f1-b49a-452a6f3acdc8@ddn.com>
Date:   Mon, 6 Mar 2023 21:05:05 +0000
From:   Bernd Schubert <bschubert@....com>
To:     Miklos Szeredi <miklos@...redi.hu>,
        Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
CC:     "mszeredi@...hat.com" <mszeredi@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Amir Goldstein <amir73il@...il.com>,
        Stéphane Graber <stgraber@...ntu.com>,
        Seth Forshee <sforshee@...nel.org>,
        Christian Brauner <brauner@...nel.org>,
        Andrei Vagin <avagin@...il.com>,
        Pavel Tikhomirov <ptikhomirov@...tuozzo.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "criu@...nvz.org" <criu@...nvz.org>,
        "flyingpeng@...cent.com" <flyingpeng@...cent.com>
Subject: Re: [RFC PATCH 0/9] fuse: API for Checkpoint/Restore



On 3/6/23 20:18, Miklos Szeredi wrote:
> On Mon, 6 Mar 2023 at 17:44, Aleksandr Mikhalitsyn
> <aleksandr.mikhalitsyn@...onical.com> wrote:
>>
>> On Mon, Mar 6, 2023 at 5:15 PM Miklos Szeredi <miklos@...redi.hu> wrote:
> 
>>> Apparently all of the added mechanisms (REINIT, BM_REVAL, conn_gen)
>>> are crash recovery related, and not useful for C/R.  Why is this being
>>> advertised as a precursor for CRIU support?
>>
>> It's because I'm doing this with CRIU in mind too, I think it's a good
>> way to make a universal interface
>> which can address not only the recovery case but also the C/R, cause
>> in some sense it's a close problem.
> 
> That's what I'm wondering about...
> 
> Crash recovery is about restoring (or at least regenerating) state in
> the userspace server.
> 
> In CRIU restoring the state of the userspace server is a solved
> problem, the issue is restoring state in the kernel part of fuse.  In
> a sense it's the exact opposite problem that crash recovery is doing.
> 
>> But of course, Checkpoint/Restore is a way more trickier. But before
>> doing all the work with CRIU PoC,
>> I wanted to consult with you and folks if there are any serious
>> objections to this interface/feature or, conversely,
>> if there is someone else who is interested in it.
>>
>> Now about interfaces REINIT, BM_REVAL.
>>
>> I think it will be useful for CRIU case, but probably I need to extend
>> it a little bit, as I mentioned earlier in the cover letter:
>>>> * "fake" daemon has to reply to FUSE_INIT request from the kernel and initialize fuse connection somehow.
>>>> This setup can be not consistent with the original daemon (protocol version, daemon capabilities/settings
>>>> like no_open, no_flush, readahead, and so on).
>>
>> So, after the "fake" demon has done its job during CRIU restore, we
>> need to replace it with the actual demon from
>> the dumpee tree and performing REINIT looks like a sanner way.
> 
> I don't get it.  How does REINIT help with switching to the real daemon?

The way I read the patches, the new daemon sends FUSE_INIT to advertise 
all of its features.