[PATCH 0/4] KVM: VFIO: use mutex guards to simplify control flow

[PATCH 0/4] KVM: VFIO: use mutex guards to simplify control flow

[Carlos López]

Replace several uses of mutex_lock() / mutex_unlock() pairs with mutex
guards, allowing removal of all gotos in virt/kvm/vfio.c.

In this series I also include a small refactor that allows greatly
simplifying kvm_vfio_file_del(), and skipping an unnecessary call to
kvm_vfio_update_coherency() if the list of files managed by the KVM
VFIO device does not change.

Carlos López (4):
  KVM: VFIO: clean up control flow in kvm_vfio_file_add()
  KVM: VFIO: use mutex guard in kvm_vfio_file_set_spapr_tce()
  KVM: VFIO: deduplicate file release logic
  KVM: VFIO: update coherency only if file was deleted

 virt/kvm/vfio.c | 97 ++++++++++++++++++-------------------------------
 1 file changed, 35 insertions(+), 62 deletions(-)


base-commit: d2ea4ff1ce50787a98a3900b3fb1636f3620b7cf
-- 
2.51.0

[PATCH 1/4] KVM: VFIO: clean up control flow in kvm_vfio_file_add()

[Carlos López]

The struct file that this function fgets() is always passed to fput()
before returning, so use automatic cleanup via __free() to avoid several
jumps to the end of the function. Similarly, use a mutex guard to
completely remove the need to use gotos.

Signed-off-by: Carlos López <clopez@suse.de>
---
 virt/kvm/vfio.c | 29 +++++++++--------------------
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 9f9acb66cc1e..2c91bad3333b 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -144,33 +144,26 @@ static int kvm_vfio_file_add(struct kvm_device *dev, unsigned int fd)
 {
 	struct kvm_vfio *kv = dev->private;
 	struct kvm_vfio_file *kvf;
-	struct file *filp;
-	int ret = 0;
+	struct file *filp __free(fput) = NULL;
 
 	filp = fget(fd);
 	if (!filp)
 		return -EBADF;
 
 	/* Ensure the FD is a vfio FD. */
-	if (!kvm_vfio_file_is_valid(filp)) {
-		ret = -EINVAL;
-		goto out_fput;
-	}
+	if (!kvm_vfio_file_is_valid(filp))
+		return -EINVAL;
 
-	mutex_lock(&kv->lock);
+	guard(mutex)(&kv->lock);
 
 	list_for_each_entry(kvf, &kv->file_list, node) {
-		if (kvf->file == filp) {
-			ret = -EEXIST;
-			goto out_unlock;
-		}
+		if (kvf->file == filp)
+			return -EEXIST;
 	}
 
 	kvf = kzalloc_obj(*kvf, GFP_KERNEL_ACCOUNT);
-	if (!kvf) {
-		ret = -ENOMEM;
-		goto out_unlock;
-	}
+	if (!kvf)
+		return -ENOMEM;
 
 	kvf->file = get_file(filp);
 	list_add_tail(&kvf->node, &kv->file_list);
@@ -178,11 +171,7 @@ static int kvm_vfio_file_add(struct kvm_device *dev, unsigned int fd)
 	kvm_vfio_file_set_kvm(kvf->file, dev->kvm);
 	kvm_vfio_update_coherency(dev);
 
-out_unlock:
-	mutex_unlock(&kv->lock);
-out_fput:
-	fput(filp);
-	return ret;
+	return 0;
 }
 
 static int kvm_vfio_file_del(struct kvm_device *dev, unsigned int fd)
-- 
2.51.0

[PATCH 2/4] KVM: VFIO: use mutex guard in kvm_vfio_file_set_spapr_tce()

[Carlos López]

Use a mutex guard to hold a lock for the entirety of the function, which
removes the need for a goto (whose label even has a misleading name
since 8152f8201088 ("fdget(), more trivial conversions"))

Signed-off-by: Carlos López <clopez@suse.de>
---
 virt/kvm/vfio.c | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 2c91bad3333b..02d373f66cba 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -225,9 +225,7 @@ static int kvm_vfio_file_set_spapr_tce(struct kvm_device *dev,
 	if (fd_empty(f))
 		return -EBADF;
 
-	ret = -ENOENT;
-
-	mutex_lock(&kv->lock);
+	guard(mutex)(&kv->lock);
 
 	list_for_each_entry(kvf, &kv->file_list, node) {
 		if (kvf->file != fd_file(f))
@@ -235,20 +233,15 @@ static int kvm_vfio_file_set_spapr_tce(struct kvm_device *dev,
 
 		if (!kvf->iommu_group) {
 			kvf->iommu_group = kvm_vfio_file_iommu_group(kvf->file);
-			if (WARN_ON_ONCE(!kvf->iommu_group)) {
-				ret = -EIO;
-				goto err_fdput;
-			}
+			if (WARN_ON_ONCE(!kvf->iommu_group))
+				return -EIO;
 		}
 
-		ret = kvm_spapr_tce_attach_iommu_group(dev->kvm, param.tablefd,
-						       kvf->iommu_group);
-		break;
+		return kvm_spapr_tce_attach_iommu_group(dev->kvm, param.tablefd,
+							kvf->iommu_group);
 	}
 
-err_fdput:
-	mutex_unlock(&kv->lock);
-	return ret;
+	return -ENOENT;
 }
 #endif
 
-- 
2.51.0

[PATCH 3/4] KVM: VFIO: deduplicate file release logic

[Carlos López]

There are two callsites which destroy files in kv->file_list: the
function servicing KVM_DEV_VFIO_FILE_DEL, and the relase of the whole
KVM VFIO device. The process involves several steps, so move all those
into a single function, removing duplicate code.

Signed-off-by: Carlos López <clopez@suse.de>
---
 virt/kvm/vfio.c | 39 ++++++++++++++++++---------------------
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 02d373f66cba..e1c88c0b82d9 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -174,6 +174,17 @@ static int kvm_vfio_file_add(struct kvm_device *dev, unsigned int fd)
 	return 0;
 }
 
+static void kvm_vfio_file_free(struct kvm_device *dev, struct kvm_vfio_file *kvf)
+{
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+	kvm_spapr_tce_release_vfio_group(dev->kvm, kvf);
+#endif
+	kvm_vfio_file_set_kvm(kvf->file, NULL);
+	fput(kvf->file);
+	list_del(&kvf->node);
+	kfree(kvf);
+}
+
 static int kvm_vfio_file_del(struct kvm_device *dev, unsigned int fd)
 {
 	struct kvm_vfio *kv = dev->private;
@@ -189,18 +200,11 @@ static int kvm_vfio_file_del(struct kvm_device *dev, unsigned int fd)
 	mutex_lock(&kv->lock);
 
 	list_for_each_entry(kvf, &kv->file_list, node) {
-		if (kvf->file != fd_file(f))
-			continue;
-
-		list_del(&kvf->node);
-#ifdef CONFIG_SPAPR_TCE_IOMMU
-		kvm_spapr_tce_release_vfio_group(dev->kvm, kvf);
-#endif
-		kvm_vfio_file_set_kvm(kvf->file, NULL);
-		fput(kvf->file);
-		kfree(kvf);
-		ret = 0;
-		break;
+		if (kvf->file == fd_file(f)) {
+			kvm_vfio_file_free(dev, kvf);
+			ret = 0;
+			break;
+		}
 	}
 
 	kvm_vfio_update_coherency(dev);
@@ -308,15 +312,8 @@ static void kvm_vfio_release(struct kvm_device *dev)
 	struct kvm_vfio *kv = dev->private;
 	struct kvm_vfio_file *kvf, *tmp;
 
-	list_for_each_entry_safe(kvf, tmp, &kv->file_list, node) {
-#ifdef CONFIG_SPAPR_TCE_IOMMU
-		kvm_spapr_tce_release_vfio_group(dev->kvm, kvf);
-#endif
-		kvm_vfio_file_set_kvm(kvf->file, NULL);
-		fput(kvf->file);
-		list_del(&kvf->node);
-		kfree(kvf);
-	}
+	list_for_each_entry_safe(kvf, tmp, &kv->file_list, node)
+		kvm_vfio_file_free(dev, kvf);
 
 	kvm_vfio_update_coherency(dev);
 
-- 
2.51.0

[PATCH 4/4] KVM: VFIO: update coherency only if file was deleted

[Carlos López]

When servicing a KVM_DEV_VFIO_FILE_DEL request, if a file is removed
from kv->file_list, kv->noncoherent needs to be updated, in case we
can revert to using coherent DMA. However, if we found no candidate
to remove, there is no need to re-scan the list, so do it only if a
matching file was found.

To simplify the control flow, use a mutex guard so that we can return
early from within the search loop if the maching file is found.

Signed-off-by: Carlos López <clopez@suse.de>
---
 virt/kvm/vfio.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index e1c88c0b82d9..47a3b8d82735 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -190,27 +190,21 @@ static int kvm_vfio_file_del(struct kvm_device *dev, unsigned int fd)
 	struct kvm_vfio *kv = dev->private;
 	struct kvm_vfio_file *kvf;
 	CLASS(fd, f)(fd);
-	int ret;
 
 	if (fd_empty(f))
 		return -EBADF;
 
-	ret = -ENOENT;
-
-	mutex_lock(&kv->lock);
+	guard(mutex)(&kv->lock);
 
 	list_for_each_entry(kvf, &kv->file_list, node) {
 		if (kvf->file == fd_file(f)) {
 			kvm_vfio_file_free(dev, kvf);
-			ret = 0;
-			break;
+			kvm_vfio_update_coherency(dev);
+			return 0;
 		}
 	}
 
-	kvm_vfio_update_coherency(dev);
-
-	mutex_unlock(&kv->lock);
-	return ret;
+	return -ENOENT;
 }
 
 #ifdef CONFIG_SPAPR_TCE_IOMMU
-- 
2.51.0

Re: [PATCH 0/4] KVM: VFIO: use mutex guards to simplify control flow

[Alex Williamson]

On Fri, 13 Mar 2026 13:20:38 +0100
Carlos López <clopez@suse.de> wrote:

> Replace several uses of mutex_lock() / mutex_unlock() pairs with mutex
> guards, allowing removal of all gotos in virt/kvm/vfio.c.
> 
> In this series I also include a small refactor that allows greatly
> simplifying kvm_vfio_file_del(), and skipping an unnecessary call to
> kvm_vfio_update_coherency() if the list of files managed by the KVM
> VFIO device does not change.
> 
> Carlos López (4):
>   KVM: VFIO: clean up control flow in kvm_vfio_file_add()
>   KVM: VFIO: use mutex guard in kvm_vfio_file_set_spapr_tce()
>   KVM: VFIO: deduplicate file release logic
>   KVM: VFIO: update coherency only if file was deleted
> 
>  virt/kvm/vfio.c | 97 ++++++++++++++++++-------------------------------
>  1 file changed, 35 insertions(+), 62 deletions(-)
> 
> 
> base-commit: d2ea4ff1ce50787a98a3900b3fb1636f3620b7cf

Series looks good to me.  This is nicely isolated, so I assume Paolo
will take it through the KVM tree, but I can also take it through vfio
if preferred.

Reviewed-by: Alex Williamson <alex@shazbot.org>

Thanks,
Alex

Re: [PATCH 0/4] KVM: VFIO: use mutex guards to simplify control flow

[Sean Christopherson]

On Wed, Mar 18, 2026, Alex Williamson wrote:
> On Fri, 13 Mar 2026 13:20:38 +0100
> Carlos López <clopez@suse.de> wrote:
> 
> > Replace several uses of mutex_lock() / mutex_unlock() pairs with mutex
> > guards, allowing removal of all gotos in virt/kvm/vfio.c.
> > 
> > In this series I also include a small refactor that allows greatly
> > simplifying kvm_vfio_file_del(), and skipping an unnecessary call to
> > kvm_vfio_update_coherency() if the list of files managed by the KVM
> > VFIO device does not change.
> > 
> > Carlos López (4):
> >   KVM: VFIO: clean up control flow in kvm_vfio_file_add()
> >   KVM: VFIO: use mutex guard in kvm_vfio_file_set_spapr_tce()
> >   KVM: VFIO: deduplicate file release logic
> >   KVM: VFIO: update coherency only if file was deleted
> > 
> >  virt/kvm/vfio.c | 97 ++++++++++++++++++-------------------------------
> >  1 file changed, 35 insertions(+), 62 deletions(-)
> > 
> > 
> > base-commit: d2ea4ff1ce50787a98a3900b3fb1636f3620b7cf
> 
> Series looks good to me.  This is nicely isolated, so I assume Paolo
> will take it through the KVM tree, but I can also take it through vfio
> if preferred.

I'll grab it for 7.2, probably around 7.1-rc2.