From: Pratyush Yadav <pratyush@kernel.org>
To: tarunsahu@google.com
Cc: Ackerley Tng <ackerleytng@google.com>,
Jonathan Corbet <corbet@lwn.net>,
vannapurve@google.com, fvdl@google.com,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Shuah Khan <skhan@linuxfoundation.org>,
sagis@google.com, aneesh.kumar@kernel.org, skhawaja@google.com,
vipinsh@google.com, Pratyush Yadav <pratyush@kernel.org>,
david@redhat.com, dmatlack@google.com, mark.rutland@arm.com,
Paolo Bonzini <pbonzini@redhat.com>,
Mike Rapoport <rppt@kernel.org>,
Alexander Graf <graf@amazon.com>,
seanjc@google.com, axelrasmussen@google.com,
linux-kselftest@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kvm@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v2 06/10] kvm: guest_memfd: Add support for freezing and unfreezing mappings
Date: Tue, 23 Jun 2026 18:14:14 +0200 [thread overview]
Message-ID: <2vxz8q85mdyh.fsf@kernel.org> (raw)
In-Reply-To: <9huztsqtmihs.fsf@tarunix.c.googlers.com> (tarunsahu@google.com's message of "Tue, 23 Jun 2026 14:36:15 +0000")
On Tue, Jun 23 2026, tarunsahu@google.com wrote:
> Ackerley Tng <ackerleytng@google.com> writes:
>
>> Tarun Sahu <tarunsahu@google.com> writes:
>>
>>> static long kvm_gmem_fallocate(struct file *file, int mode, loff_t offset,
>>> loff_t len)
>>> {
>>> + struct inode *inode = file_inode(file);
>>> int ret;
>>> + int idx;
>>>
>>> - if (!(mode & FALLOC_FL_KEEP_SIZE))
>>> - return -EOPNOTSUPP;
>>> + idx = srcu_read_lock(&kvm_gmem_freeze_srcu);
>>> + if (kvm_gmem_is_frozen(inode)) {
>>> + srcu_read_unlock(&kvm_gmem_freeze_srcu, idx);
>>> + return -EPERM;
>>> + }
>>
>> fallocate may eventually go to kvm_gmem_get_folio(), so that would check
>> kvm_gmem_is_frozen() twice. Is this meant to catch the punch hole case?
Yeah, I reckon you can get away with doing this check only in
kvm_gmem_get_folio(). Normally you'd like to fail early, but as of now I
don't see much of a problem. If you drop the check here and fail in
kvm_gmem_get_folio() you'd end up taking and releasing the mapping
invalidate_lock, but this isn't a fast path anyway so I don't think it
should matter much.
I think either way can work just as fine...
>>
>>>
>>> - if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
>>> - return -EOPNOTSUPP;
>>> + if (!(mode & FALLOC_FL_KEEP_SIZE)) {
>>> + ret = -EOPNOTSUPP;
>>> + goto out;
>>> + }
>>>
>>> - if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len))
>>> - return -EINVAL;
>>> + if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) {
>>> + ret = -EOPNOTSUPP;
>>> + goto out;
>>> + }
>>> +
>>> + if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len)) {
>>> + ret = -EINVAL;
>>> + goto out;
>>> + }
>>
>> There's some reordering here. Why not let the validation happen like
>> before, then check kvm_gmem_is_frozen()?
There is no reordering, if I am reading the diff correctly. The diff is
somewhat misleading. The kvm_gmem_is_frozen() call is added at the top
of the function, and then all the later checks are in the same place but
get a goto out (and hence a full body to the if block). So the diff
reads like reordering, but there is none.
It would be very neat if scru had a cleanup.h style scope-based locking
function, but on a quick glance I can't see one.
>
> To align with design. "stop the fallocate call if inode is frozen, No
> need to go further". I dont have strict opinion on this. I am fine with
> taking it across punch hole as well to make it more fine grained. But it
> will no longer claims stop the fallocate call (allocation one is stopped
> in separate path: fault path) , though functionally it does the same
> thing.
>
> WDYT?
>
> ~Tarun
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-06-23 16:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1780676742.git.tarunsahu@google.com>
2026-06-05 17:08 ` [RFC PATCH v2 01/10] liveupdate: luo_file: Add internal APIs for file preservation Tarun Sahu
2026-06-05 17:24 ` sashiko-bot
2026-06-07 0:41 ` tarunsahu
2026-06-07 0:35 ` tarunsahu
2026-06-05 17:08 ` [RFC PATCH v2 02/10] liveupdate: Add LIVEUPDATE_GUEST_MEMFD config option Tarun Sahu
2026-06-05 17:08 ` [RFC PATCH v2 03/10] kvm: Prepare core VM structs and helpers for LUO support Tarun Sahu
2026-06-05 17:21 ` sashiko-bot
2026-06-22 23:59 ` Ackerley Tng
2026-06-23 12:48 ` tarunsahu
2026-06-23 15:33 ` tarunsahu
2026-06-05 17:08 ` [RFC PATCH v2 04/10] kvm: kvm_luo: Allow kvm preservation with LUO Tarun Sahu
2026-06-05 17:26 ` sashiko-bot
2026-06-08 16:13 ` tarunsahu
2026-06-05 17:08 ` [RFC PATCH v2 05/10] kvm: guest_memfd: Move internal definitions and helper to new header Tarun Sahu
2026-06-05 17:08 ` [RFC PATCH v2 06/10] kvm: guest_memfd: Add support for freezing and unfreezing mappings Tarun Sahu
2026-06-05 17:21 ` sashiko-bot
2026-06-08 18:20 ` tarunsahu
2026-06-22 23:54 ` Ackerley Tng
2026-06-23 0:09 ` Sean Christopherson
2026-06-23 14:03 ` tarunsahu
2026-06-23 14:02 ` tarunsahu
2026-06-23 14:36 ` tarunsahu
2026-06-23 16:14 ` Pratyush Yadav [this message]
2026-06-23 20:06 ` tarunsahu
2026-06-05 17:08 ` [RFC PATCH v2 07/10] kvm: guest_memfd_luo: add support for guest_memfd preservation Tarun Sahu
2026-06-05 17:25 ` sashiko-bot
2026-06-08 18:22 ` tarunsahu
2026-06-22 23:27 ` Ackerley Tng
2026-06-23 15:26 ` tarunsahu
2026-06-05 17:08 ` [RFC PATCH v2 08/10] docs: add documentation for guest_memfd preservation via LUO Tarun Sahu
2026-06-05 17:08 ` [RFC PATCH v2 09/10] selftests: kvm: Split ____vm_create() to expose init helpers Tarun Sahu
2026-06-05 17:08 ` [RFC PATCH v2 10/10] selftests: kvm: Add guest_memfd_preservation_test Tarun Sahu
2026-06-05 17:22 ` sashiko-bot
2026-06-08 18:26 ` tarunsahu
2026-06-22 23:01 ` Ackerley Tng
2026-06-23 19:50 ` tarunsahu
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=2vxz8q85mdyh.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=ackerleytng@google.com \
--cc=aneesh.kumar@kernel.org \
--cc=axelrasmussen@google.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=dmatlack@google.com \
--cc=fvdl@google.com \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=rppt@kernel.org \
--cc=sagis@google.com \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
--cc=skhawaja@google.com \
--cc=tarunsahu@google.com \
--cc=vannapurve@google.com \
--cc=vipinsh@google.com \
/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.