On Tue, Jun 23 2026, [email protected] wrote: > Pratyush Yadav <[email protected]> writes: > >> On Tue, Jun 23 2026, [email protected] wrote: >> >>> Ackerley Tng <[email protected]> writes: >>> >>>> Tarun Sahu <[email protected]> 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. > > No, Don't agree. > kvm_gmem_get_folios already have the is_frozen check. which blocks the > kvm_gmem_allocate. But not kvm_gmem_punch_hole. Your argument is correct > for kvm_gmem_allocate only. So is_frozen check in fallocate is to > block the punch hole as well. What ackerley said is correct.
Oh, right. Then we do need the check in both places. [...] -- Regards, Pratyush Yadav
