Received-SPF: pass (google.com: domain of linux-kernel+bounces-85595-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 28 Feb 2024 19:24:34 +0000
From: Matthew Wilcox <willy@infradead.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yosry Ahmed <yosryahmed@google.com>,
	Sean Christopherson <seanjc@google.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	michael.roth@amd.com, isaku.yamahata@intel.com,
	thomas.lendacky@amd.com
Subject: Re: [PATCH 17/21] filemap: add FGP_CREAT_ONLY
Message-ID: <Zd-Icopo09aUmOvT@casper.infradead.org>
References: <20240227232100.478238-1-pbonzini@redhat.com>
 <20240227232100.478238-18-pbonzini@redhat.com>
 <Zd6W-aLnovAI1FL3@google.com>
 <CAJD7tkapC6es9qjaOf=SmE9XYUdbh_fAperjSe9hy=_iqdB0wQ@mail.gmail.com>
 <Zd8x3w2mwyAufKvm@casper.infradead.org>
 <CABgObfZ9LFDrtLkMaT5LVwy0Z2QMk6SqJ104+D=w7o9i0gEu+g@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABgObfZ9LFDrtLkMaT5LVwy0Z2QMk6SqJ104+D=w7o9i0gEu+g@mail.gmail.com>

On Wed, Feb 28, 2024 at 02:28:45PM +0100, Paolo Bonzini wrote:
> Since you're here: KVM would like to add a ioctl to encrypt and
> install a page into guest_memfd, in preparation for launching an
> encrypted guest. For this API we want to rule out the possibility of
> overwriting a page that is already in the guest_memfd's filemap,
> therefore this API would pass FGP_CREAT_ONLY|FGP_CREAT
> into__filemap_get_folio. Do you think this is bogus...

Would it work to start out by either asserting the memfd is empty of
pages, or by evicting any existing pages?  Both those seem nicer than
starting, realising you've got some unencrypted memory and aborting.

> > This looks bogus to me, and if it's not bogus, it's incomplete.
> 
> ... or if not, what incompleteness can you spot?

The part where we race another caller passing FGP_CREAT_ONLY and one gets
an EEXIST back from filemap_add_folio().  Maybe that's not something
that can happen in your use case, but it's at least semantics that
need documenting.