From: Sean Christopherson <seanjc@google.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH gmem FIXUP] kvm: guestmem: do not use a file system
Date: Mon, 9 Oct 2023 07:32:48 -0700 [thread overview]
Message-ID: <ZSQO4fHaAxDkbGyz@google.com> (raw)
In-Reply-To: <20231009022248.GD800259@ZenIV>
On Mon, Oct 09, 2023, Al Viro wrote:
> On Thu, Sep 28, 2023 at 07:22:16PM -0700, Sean Christopherson wrote:
> > On Thu, 28 Sep 2023 14:06:51 -0400, Paolo Bonzini wrote:
> > > Use a run-of-the-mill anonymous inode, there is nothing useful
> > > being provided by kvm_gmem_fs.
> > >
> > >
> >
> > Applied to kvm-x86 guest_memfd, thanks!
> >
> > [1/1] kvm: guestmem: do not use a file system
> > https://github.com/kvm-x86/linux/commit/0f7e60a5f42a
>
> Please, revert; this is completely broken. anon_inode_getfile()
> yields a file with the same ->f_inode every time it is called.
>
> Again, ->f_inode of those things is shared to hell and back,
> very much by design. You can't modify its ->i_op or anything
> other field, for that matter. No information can be stored
> in that thing - you are only allowed to use the object you've
> passed via 'priv' argument.
Yeah, we found that out the hard way. Is using the "secure" variant to get a
per-file inode a sane approach, or is that abuse that's going to bite us too?
/*
* Use the so called "secure" variant, which creates a unique inode
* instead of reusing a single inode. Each guest_memfd instance needs
* its own inode to track the size, flags, etc.
*/
file = anon_inode_getfile_secure(anon_name, &kvm_gmem_fops, gmem,
O_RDWR, NULL);
next prev parent reply other threads:[~2023-10-09 14:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 18:06 [PATCH gmem FIXUP] kvm: guestmem: do not use a file system Paolo Bonzini
2023-09-29 2:22 ` Sean Christopherson
2023-10-09 2:22 ` Al Viro
2023-10-09 2:35 ` Al Viro
2023-10-09 14:32 ` Sean Christopherson [this message]
2023-10-09 20:06 ` Al Viro
2023-10-09 20:20 ` Sean Christopherson
2023-10-09 20:40 ` Al Viro
2023-10-09 21:26 ` Sean Christopherson
2023-10-10 0:09 ` Al Viro
2023-10-10 0:27 ` Sean Christopherson
2023-10-10 0:37 ` Al Viro
2023-10-10 23:30 ` Sean Christopherson
2023-10-11 15:06 ` Xu Yilun
2023-10-11 17:57 ` Paolo Bonzini
2023-10-13 16:55 ` Sean Christopherson
2023-10-16 15:19 ` Paolo Bonzini
2023-10-09 2:16 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZSQO4fHaAxDkbGyz@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.