On Fri, Dec 31, 2021, Chao Peng wrote:
> On Fri, Dec 24, 2021 at 11:53:15AM +0800, Robert Hoo wrote:
> > On Thu, 2021-12-23 at 20:29 +0800, Chao Peng wrote:
> > > From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
> > >
> > > +static void notify_fallocate(struct inode *inode, pgoff_t start,
> > > pgoff_t end)
> > > +{
> > > +#ifdef CONFIG_MEMFD_OPS
> > > + struct shmem_inode_info *info = SHMEM_I(inode);
> > > + const struct memfd_falloc_notifier *notifier;
> > > + void *owner;
> > > + bool ret;
> > > +
> > > + if (!info->falloc_notifier)
> > > + return;
> > > +
> > > + spin_lock(&info->lock);
> > > + notifier = info->falloc_notifier;
> > > + if (!notifier) {
> > > + spin_unlock(&info->lock);
> > > + return;
> > > + }
> > > +
> > > + owner = info->owner;
> > > + ret = notifier->get_owner(owner);
> > > + spin_unlock(&info->lock);
> > > + if (!ret)
> > > + return;
> > > +
> > > + notifier->fallocate(inode, owner, start, end);
> >
> > I see notifier->fallocate(), i.e. memfd_fallocate(), discards
> > kvm_memfd_fallocate_range()'s return value. Should it be checked?
>
> I think we can ignore it, just like how current mmu_notifier does,
> the return value of __kvm_handle_hva_range is discarded in
> kvm_mmu_notifier_invalidate_range_start(). Even when KVM side failed,
> it's not fatal, it should not block the operation in the primary MMU.
If the return value is ignored, it'd be better to have no return value at all so
that it's clear fallocate() will continue on regardless of whether or not the
secondary MMU callback succeeds. E.g. if KVM can't handle the fallocate() for
whatever reason, then knowing that fallocate() will continue on means KVM should
mark the VM as dead so that the broken setup cannot be abused by userspace.
