Linux-HyperV List
 help / color / mirror / Atom feed
* Re: [PPATCH net v3] net: mana: fix use-after-free in add_adev() error path
From: patchwork-bot+netdevbpf @ 2026-03-25  4:10 UTC (permalink / raw)
  To: Guangshuo Li
  Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
	edumazet, kuba, pabeni, ernis, dipayanroy, gargaditya,
	shirazsaleem, kees, leon, linux-hyperv, netdev, linux-kernel,
	stable
In-Reply-To: <20260323165730.945365-1-lgs201920130244@gmail.com>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 24 Mar 2026 00:57:30 +0800 you wrote:
> If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls
> auxiliary_device_uninit(adev).
> 
> The auxiliary device has its release callback set to adev_release(),
> which frees the containing struct mana_adev. Since adev is embedded in
> struct mana_adev, the subsequent fall-through to init_fail and access
> to adev->id may result in a use-after-free.
> 
> [...]

Here is the summary with links:
  - [PPATCH,net,v3] net: mana: fix use-after-free in add_adev() error path
    https://git.kernel.org/netdev/net/c/c4ea7d8907cf

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply

* [PATCH] Drivers: hv: mshv: fix integer overflow in memory region overlap check
From: Junrui Luo @ 2026-03-25  4:05 UTC (permalink / raw)
  To: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
	Mukesh Rathor, Nuno Das Neves, Roman Kisel, Stanislav Kinsburskii
  Cc: Muminul Islam, Praveen K Paladugu, linux-hyperv, linux-kernel,
	Yuhao Jiang, stable, Junrui Luo

mshv_partition_create_region() computes mem->guest_pfn + nr_pages to
check for overlapping regions without verifying u64 wraparound. A
sufficiently large guest_pfn can cause the addition to overflow,
bypassing the overlap check and allowing creation of regions that wrap
around the address space.

Fix by using check_add_overflow() to reject such regions.

Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/hv/mshv_root_main.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index 6f42423f7faa..6ddb315fc2c2 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -1174,11 +1174,16 @@ static int mshv_partition_create_region(struct mshv_partition *partition,
 {
 	struct mshv_mem_region *rg;
 	u64 nr_pages = HVPFN_DOWN(mem->size);
+	u64 new_region_end;
+
+	/* Reject regions whose end address would wrap around */
+	if (check_add_overflow(mem->guest_pfn, nr_pages, &new_region_end))
+		return -EOVERFLOW;
 
 	/* Reject overlapping regions */
 	spin_lock(&partition->pt_mem_regions_lock);
 	hlist_for_each_entry(rg, &partition->pt_mem_regions, hnode) {
-		if (mem->guest_pfn + nr_pages <= rg->start_gfn ||
+		if (new_region_end <= rg->start_gfn ||
 		    rg->start_gfn + rg->nr_pages <= mem->guest_pfn)
 			continue;
 		spin_unlock(&partition->pt_mem_regions_lock);

---
base-commit: c369299895a591d96745d6492d4888259b004a9e
change-id: 20260325-fixes-9a58895aea55

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>


^ permalink raw reply related

* Re: [PATCH 05/12] PCI: use generic driver_override infrastructure
From: Gui-Dong Han @ 2026-03-25  3:08 UTC (permalink / raw)
  To: Danilo Krummrich
  Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
	Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
	Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
	Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
	Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Harald Freudenberger, Holger Dengler, Mark Brown,
	Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
	Alex Williamson, Juergen Gross, Stefano Stabellini,
	Oleksandr Tyshchenko, Christophe Leroy (CS GROUP), linux-kernel,
	driver-core, linuxppc-dev, linux-hyperv, linux-pci,
	platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
	linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
	Wang Jiayue, Yao Zi
In-Reply-To: <20260324005919.2408620-6-dakr@kernel.org>

On Tue, Mar 24, 2026 at 9:00 AM Danilo Krummrich <dakr@kernel.org> wrote:
>
> When a driver is probed through __driver_attach(), the bus' match()
> callback is called without the device lock held, thus accessing the
> driver_override field without a lock, which can cause a UAF.
>
> Fix this by using the driver-core driver_override infrastructure taking
> care of proper locking internally.
>
> Note that calling match() from __driver_attach() without the device lock
> held is intentional. [1]
>
> Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
> Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
> Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>

Tested on QEMU PCI with multiple debug configs enabled. The original
PoCs run cleanly without triggering the issue.

Thanks Danilo.

Tested-by: Gui-Dong Han <hanguidong02@gmail.com>
Reviewed-by: Gui-Dong Han <hanguidong02@gmail.com>

> ---
>  drivers/pci/pci-driver.c           | 11 +++++++----
>  drivers/pci/pci-sysfs.c            | 28 ----------------------------
>  drivers/pci/probe.c                |  1 -
>  drivers/vfio/pci/vfio_pci_core.c   |  5 ++---
>  drivers/xen/xen-pciback/pci_stub.c |  6 ++++--
>  include/linux/pci.h                |  6 ------
>  6 files changed, 13 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index dd9075403987..d10ece0889f0 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -138,9 +138,11 @@ static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
>  {
>         struct pci_dynid *dynid;
>         const struct pci_device_id *found_id = NULL, *ids;
> +       int ret;
>
>         /* When driver_override is set, only bind to the matching driver */
> -       if (dev->driver_override && strcmp(dev->driver_override, drv->name))
> +       ret = device_match_driver_override(&dev->dev, &drv->driver);
> +       if (ret == 0)
>                 return NULL;
>
>         /* Look at the dynamic ids first, before the static ones */
> @@ -164,7 +166,7 @@ static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
>                  * matching.
>                  */
>                 if (found_id->override_only) {
> -                       if (dev->driver_override)
> +                       if (ret > 0)
>                                 return found_id;
>                 } else {
>                         return found_id;
> @@ -172,7 +174,7 @@ static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
>         }
>
>         /* driver_override will always match, send a dummy id */
> -       if (dev->driver_override)
> +       if (ret > 0)
>                 return &pci_device_id_any;
>         return NULL;
>  }
> @@ -452,7 +454,7 @@ static int __pci_device_probe(struct pci_driver *drv, struct pci_dev *pci_dev)
>  static inline bool pci_device_can_probe(struct pci_dev *pdev)
>  {
>         return (!pdev->is_virtfn || pdev->physfn->sriov->drivers_autoprobe ||
> -               pdev->driver_override);
> +               device_has_driver_override(&pdev->dev));
>  }
>  #else
>  static inline bool pci_device_can_probe(struct pci_dev *pdev)
> @@ -1722,6 +1724,7 @@ static const struct cpumask *pci_device_irq_get_affinity(struct device *dev,
>
>  const struct bus_type pci_bus_type = {
>         .name           = "pci",
> +       .driver_override = true,
>         .match          = pci_bus_match,
>         .uevent         = pci_uevent,
>         .probe          = pci_device_probe,
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 16eaaf749ba9..a9006cf4e9c8 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -615,33 +615,6 @@ static ssize_t devspec_show(struct device *dev,
>  static DEVICE_ATTR_RO(devspec);
>  #endif
>
> -static ssize_t driver_override_store(struct device *dev,
> -                                    struct device_attribute *attr,
> -                                    const char *buf, size_t count)
> -{
> -       struct pci_dev *pdev = to_pci_dev(dev);
> -       int ret;
> -
> -       ret = driver_set_override(dev, &pdev->driver_override, buf, count);
> -       if (ret)
> -               return ret;
> -
> -       return count;
> -}
> -
> -static ssize_t driver_override_show(struct device *dev,
> -                                   struct device_attribute *attr, char *buf)
> -{
> -       struct pci_dev *pdev = to_pci_dev(dev);
> -       ssize_t len;
> -
> -       device_lock(dev);
> -       len = sysfs_emit(buf, "%s\n", pdev->driver_override);
> -       device_unlock(dev);
> -       return len;
> -}
> -static DEVICE_ATTR_RW(driver_override);
> -
>  static struct attribute *pci_dev_attrs[] = {
>         &dev_attr_power_state.attr,
>         &dev_attr_resource.attr,
> @@ -669,7 +642,6 @@ static struct attribute *pci_dev_attrs[] = {
>  #ifdef CONFIG_OF
>         &dev_attr_devspec.attr,
>  #endif
> -       &dev_attr_driver_override.attr,
>         &dev_attr_ari_enabled.attr,
>         NULL,
>  };
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..b4707640e102 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2488,7 +2488,6 @@ static void pci_release_dev(struct device *dev)
>         pci_release_of_node(pci_dev);
>         pcibios_release_device(pci_dev);
>         pci_bus_put(pci_dev->bus);
> -       kfree(pci_dev->driver_override);
>         bitmap_free(pci_dev->dma_alias_mask);
>         dev_dbg(dev, "device released\n");
>         kfree(pci_dev);
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index d43745fe4c84..460852f79f29 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -1987,9 +1987,8 @@ static int vfio_pci_bus_notifier(struct notifier_block *nb,
>             pdev->is_virtfn && physfn == vdev->pdev) {
>                 pci_info(vdev->pdev, "Captured SR-IOV VF %s driver_override\n",
>                          pci_name(pdev));
> -               pdev->driver_override = kasprintf(GFP_KERNEL, "%s",
> -                                                 vdev->vdev.ops->name);
> -               WARN_ON(!pdev->driver_override);
> +               WARN_ON(device_set_driver_override(&pdev->dev,
> +                                                  vdev->vdev.ops->name));
>         } else if (action == BUS_NOTIFY_BOUND_DRIVER &&
>                    pdev->is_virtfn && physfn == vdev->pdev) {
>                 struct pci_driver *drv = pci_dev_driver(pdev);
> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
> index e4b27aecbf05..79a2b5dfd694 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -598,6 +598,8 @@ static int pcistub_seize(struct pci_dev *dev,
>         return err;
>  }
>
> +static struct pci_driver xen_pcibk_pci_driver;
> +
>  /* Called when 'bind'. This means we must _NOT_ call pci_reset_function or
>   * other functions that take the sysfs lock. */
>  static int pcistub_probe(struct pci_dev *dev, const struct pci_device_id *id)
> @@ -609,8 +611,8 @@ static int pcistub_probe(struct pci_dev *dev, const struct pci_device_id *id)
>
>         match = pcistub_match(dev);
>
> -       if ((dev->driver_override &&
> -            !strcmp(dev->driver_override, PCISTUB_DRIVER_NAME)) ||
> +       if (device_match_driver_override(&dev->dev,
> +                                        &xen_pcibk_pci_driver.driver) > 0 ||
>             match) {
>
>                 if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 1c270f1d5123..57e9463e4347 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -575,12 +575,6 @@ struct pci_dev {
>         u8              supported_speeds; /* Supported Link Speeds Vector */
>         phys_addr_t     rom;            /* Physical address if not from BAR */
>         size_t          romlen;         /* Length if not from BAR */
> -       /*
> -        * Driver name to force a match.  Do not set directly, because core
> -        * frees it.  Use driver_set_override() to set or clear it.
> -        */
> -       const char      *driver_override;
> -
>         unsigned long   priv_flags;     /* Private flags for the PCI driver */
>
>         /* These methods index pci_reset_fn_methods[] */
> --
> 2.53.0
>

^ permalink raw reply

* [PATCH] mshv: Add tracepoint for GPA intercept handling
From: Stanislav Kinsburskii @ 2026-03-24 23:59 UTC (permalink / raw)
  To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel

Provide visibility into GPA intercept operations for debugging and
performance analysis of Microsoft Hypervisor guest memory management.

Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
---
 drivers/hv/mshv_root_main.c |    6 ++++--
 drivers/hv/mshv_trace.h     |   29 +++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index bb9fe4985e95..d4aab09fba47 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -675,7 +675,7 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
 
 	region = mshv_partition_region_by_gfn_get(p, gfn);
 	if (!region)
-		return false;
+		goto out;
 
 	if (access_type == HV_INTERCEPT_ACCESS_WRITE &&
 	    !(region->hv_map_flags & HV_MAP_GPA_WRITABLE))
@@ -691,7 +691,9 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
 
 put_region:
 	mshv_region_put(region);
-
+out:
+	trace_mshv_handle_gpa_intercept(p->pt_id, vp->vp_index, gfn,
+					access_type, ret);
 	return ret;
 }
 
diff --git a/drivers/hv/mshv_trace.h b/drivers/hv/mshv_trace.h
index ba3b3f575983..6b8fa477fa3b 100644
--- a/drivers/hv/mshv_trace.h
+++ b/drivers/hv/mshv_trace.h
@@ -12,6 +12,7 @@
 #define _MSHV_TRACE_H_
 
 #include <linux/tracepoint.h>
+#include <hyperv/hvhdk.h>
 
 #undef TRACE_INCLUDE_PATH
 #define TRACE_INCLUDE_PATH ../../drivers/hv
@@ -509,6 +510,34 @@ TRACE_EVENT(mshv_vp_wait_for_hv_kick,
 	    )
 );
 
+TRACE_EVENT(mshv_handle_gpa_intercept,
+	    TP_PROTO(u64 partition_id, u32 vp_index, u64 gfn, u8 access_type, bool handled),
+	    TP_ARGS(partition_id, vp_index, gfn, access_type, handled),
+	    TP_STRUCT__entry(
+		    __field(u64, partition_id)
+		    __field(u32, vp_index)
+		    __field(u64, gfn)
+		    __field(u8, access_type)
+		    __field(bool, handled)
+	    ),
+	    TP_fast_assign(
+		    __entry->partition_id = partition_id;
+		    __entry->vp_index = vp_index;
+		    __entry->gfn = gfn;
+		    __entry->access_type = access_type;
+		    __entry->handled = handled;
+	    ),
+	    TP_printk("partition_id=%llu vp_index=%u gfn=0x%llx access_type=%c handled=%d",
+		    __entry->partition_id,
+		    __entry->vp_index,
+		    __entry->gfn,
+		    __entry->access_type == HV_INTERCEPT_ACCESS_READ ? 'R' :
+				    (__entry->access_type == HV_INTERCEPT_ACCESS_WRITE ? 'W' :
+				    (__entry->access_type == HV_INTERCEPT_ACCESS_READ ? 'X' : '?')),
+		    __entry->handled
+	    )
+);
+
 #endif /* _MSHV_TRACE_H_ */
 
 /* This part must be outside protection */



^ permalink raw reply related

* [PATCH] mshv: Fix infinite fault loop on permission-denied GPA intercepts
From: Stanislav Kinsburskii @ 2026-03-24 23:57 UTC (permalink / raw)
  To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel

Prevent infinite fault loops when guests access memory regions without
proper permissions. Currently, mshv_handle_gpa_intercept() attempts to
remap pages for all faults on movable memory regions, regardless of
whether the access type is permitted. When a guest writes to a read-only
region, the remap succeeds but the region remains read-only, causing
immediate re-fault and spinning the vCPU indefinitely.

Validate intercept access type against region permissions before
attempting remaps. Reject writes to non-writable regions and executes to
non-executable regions early, returning false to let the VMM handle the
intercept appropriately.

This also closes a potential DoS vector where malicious guests could
intentionally trigger these fault loops to consume host resources.

Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
---
 drivers/hv/mshv_root_main.c |   15 ++++++++++++---
 include/hyperv/hvgdk_mini.h |    6 ++++++
 include/hyperv/hvhdk.h      |    4 ++--
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index 9b0acd49c129..bb9fe4985e95 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -657,7 +657,7 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
 {
 	struct mshv_partition *p = vp->vp_partition;
 	struct mshv_mem_region *region;
-	bool ret;
+	bool ret = false;
 	u64 gfn;
 #if defined(CONFIG_X86_64)
 	struct hv_x64_memory_intercept_message *msg =
@@ -668,6 +668,8 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
 		(struct hv_arm64_memory_intercept_message *)
 		vp->vp_intercept_msg_page->u.payload;
 #endif
+	enum hv_intercept_access_type access_type =
+		msg->header.intercept_access_type;
 
 	gfn = HVPFN_DOWN(msg->guest_physical_address);
 
@@ -675,12 +677,19 @@ static bool mshv_handle_gpa_intercept(struct mshv_vp *vp)
 	if (!region)
 		return false;
 
+	if (access_type == HV_INTERCEPT_ACCESS_WRITE &&
+	    !(region->hv_map_flags & HV_MAP_GPA_WRITABLE))
+		goto put_region;
+
+	if (access_type == HV_INTERCEPT_ACCESS_EXECUTE &&
+	    !(region->hv_map_flags & HV_MAP_GPA_EXECUTABLE))
+		goto put_region;
+
 	/* Only movable memory ranges are supported for GPA intercepts */
 	if (region->mreg_type == MSHV_REGION_TYPE_MEM_MOVABLE)
 		ret = mshv_region_handle_gfn_fault(region, gfn);
-	else
-		ret = false;
 
+put_region:
 	mshv_region_put(region);
 
 	return ret;
diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
index 056ef7b6b360..98b15539e467 100644
--- a/include/hyperv/hvgdk_mini.h
+++ b/include/hyperv/hvgdk_mini.h
@@ -1532,4 +1532,10 @@ struct hv_mmio_write_input {
 	u8 data[HV_HYPERCALL_MMIO_MAX_DATA_LENGTH];
 } __packed;
 
+enum hv_intercept_access_type {
+	HV_INTERCEPT_ACCESS_READ	= 0,
+	HV_INTERCEPT_ACCESS_WRITE	= 1,
+	HV_INTERCEPT_ACCESS_EXECUTE	= 2
+};
+
 #endif /* _HV_HVGDK_MINI_H */
diff --git a/include/hyperv/hvhdk.h b/include/hyperv/hvhdk.h
index 245f3db53bf1..5e83d3714966 100644
--- a/include/hyperv/hvhdk.h
+++ b/include/hyperv/hvhdk.h
@@ -779,7 +779,7 @@ struct hv_x64_intercept_message_header {
 	u32 vp_index;
 	u8 instruction_length:4;
 	u8 cr8:4; /* Only set for exo partitions */
-	u8 intercept_access_type;
+	u8 intercept_access_type; /* enum hv_intercept_access_type */
 	union hv_x64_vp_execution_state execution_state;
 	struct hv_x64_segment_register cs_segment;
 	u64 rip;
@@ -825,7 +825,7 @@ union hv_arm64_vp_execution_state {
 struct hv_arm64_intercept_message_header {
 	u32 vp_index;
 	u8 instruction_length;
-	u8 intercept_access_type;
+	u8 intercept_access_type; /* enum hv_intercept_access_type */
 	union hv_arm64_vp_execution_state execution_state;
 	u64 pc;
 	u64 cpsr;



^ permalink raw reply related

* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Mark Brown @ 2026-03-24 15:00 UTC (permalink / raw)
  To: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
	Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
	Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
	Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
	Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Harald Freudenberger, Holger Dengler, Michael S. Tsirkin,
	Jason Wang, Xuan Zhuo, Eugenio Pérez, Alex Williamson,
	Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
	Christophe Leroy (CS GROUP), Danilo Krummrich
  Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
	platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
	linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <20260324005919.2408620-1-dakr@kernel.org>

On Tue, 24 Mar 2026 01:59:04 +0100, Danilo Krummrich wrote:
> treewide: Convert buses to use generic driver_override
> 
> This is the follow-up of the driver_override generalization in [1], converting
> the remaining 11 busses and removing the now-unused driver_set_override()
> helper.
> 
> All of them (except AP, which has a different race condition) are prone to the
> potential UAF described in [2], caused by accessing the driver_override field
> from their corresponding match() callback.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.0

Thanks!

[11/12] spi: use generic driver_override infrastructure
        https://git.kernel.org/broonie/spi/c/cc34d77dd487

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark


^ permalink raw reply

* Re: [PATCH 06/12] platform/wmi: use generic driver_override infrastructure
From: Armin Wolf @ 2026-03-24 19:41 UTC (permalink / raw)
  To: Danilo Krummrich, Russell King, Greg Kroah-Hartman,
	Rafael J. Wysocki, Ioana Ciornei, Nipun Gupta, Nikhil Agarwal,
	K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
	Bjorn Helgaas, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
	Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Harald Freudenberger, Holger Dengler, Mark Brown,
	Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
	Alex Williamson, Juergen Gross, Stefano Stabellini,
	Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
  Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
	platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
	linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
	Gui-Dong Han
In-Reply-To: <20260324005919.2408620-7-dakr@kernel.org>

Am 24.03.26 um 01:59 schrieb Danilo Krummrich:

> When a driver is probed through __driver_attach(), the bus' match()
> callback is called without the device lock held, thus accessing the
> driver_override field without a lock, which can cause a UAF.
>
> Fix this by using the driver-core driver_override infrastructure taking
> care of proper locking internally.
>
> Note that calling match() from __driver_attach() without the device lock
> held is intentional. [1]

Reviewed-by: Armin Wolf <W_Armin@gmx.de>

> Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
> Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
> Fixes: 12046f8c77e0 ("platform/x86: wmi: Add driver_override support")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---
>   drivers/platform/wmi/core.c | 36 +++++-------------------------------
>   include/linux/wmi.h         |  4 ----
>   2 files changed, 5 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/platform/wmi/core.c b/drivers/platform/wmi/core.c
> index b8e6b9a421c6..750e3619724e 100644
> --- a/drivers/platform/wmi/core.c
> +++ b/drivers/platform/wmi/core.c
> @@ -842,39 +842,11 @@ static ssize_t expensive_show(struct device *dev,
>   }
>   static DEVICE_ATTR_RO(expensive);
>   
> -static ssize_t driver_override_show(struct device *dev, struct device_attribute *attr,
> -				    char *buf)
> -{
> -	struct wmi_device *wdev = to_wmi_device(dev);
> -	ssize_t ret;
> -
> -	device_lock(dev);
> -	ret = sysfs_emit(buf, "%s\n", wdev->driver_override);
> -	device_unlock(dev);
> -
> -	return ret;
> -}
> -
> -static ssize_t driver_override_store(struct device *dev, struct device_attribute *attr,
> -				     const char *buf, size_t count)
> -{
> -	struct wmi_device *wdev = to_wmi_device(dev);
> -	int ret;
> -
> -	ret = driver_set_override(dev, &wdev->driver_override, buf, count);
> -	if (ret < 0)
> -		return ret;
> -
> -	return count;
> -}
> -static DEVICE_ATTR_RW(driver_override);
> -
>   static struct attribute *wmi_attrs[] = {
>   	&dev_attr_modalias.attr,
>   	&dev_attr_guid.attr,
>   	&dev_attr_instance_count.attr,
>   	&dev_attr_expensive.attr,
> -	&dev_attr_driver_override.attr,
>   	NULL
>   };
>   ATTRIBUTE_GROUPS(wmi);
> @@ -943,7 +915,6 @@ static void wmi_dev_release(struct device *dev)
>   {
>   	struct wmi_block *wblock = dev_to_wblock(dev);
>   
> -	kfree(wblock->dev.driver_override);
>   	kfree(wblock);
>   }
>   
> @@ -952,10 +923,12 @@ static int wmi_dev_match(struct device *dev, const struct device_driver *driver)
>   	const struct wmi_driver *wmi_driver = to_wmi_driver(driver);
>   	struct wmi_block *wblock = dev_to_wblock(dev);
>   	const struct wmi_device_id *id = wmi_driver->id_table;
> +	int ret;
>   
>   	/* When driver_override is set, only bind to the matching driver */
> -	if (wblock->dev.driver_override)
> -		return !strcmp(wblock->dev.driver_override, driver->name);
> +	ret = device_match_driver_override(dev, driver);
> +	if (ret >= 0)
> +		return ret;
>   
>   	if (id == NULL)
>   		return 0;
> @@ -1076,6 +1049,7 @@ static struct class wmi_bus_class = {
>   static const struct bus_type wmi_bus_type = {
>   	.name = "wmi",
>   	.dev_groups = wmi_groups,
> +	.driver_override = true,
>   	.match = wmi_dev_match,
>   	.uevent = wmi_dev_uevent,
>   	.probe = wmi_dev_probe,
> diff --git a/include/linux/wmi.h b/include/linux/wmi.h
> index 75cb0c7cfe57..14fb644e1701 100644
> --- a/include/linux/wmi.h
> +++ b/include/linux/wmi.h
> @@ -18,16 +18,12 @@
>    * struct wmi_device - WMI device structure
>    * @dev: Device associated with this WMI device
>    * @setable: True for devices implementing the Set Control Method
> - * @driver_override: Driver name to force a match; do not set directly,
> - *		     because core frees it; use driver_set_override() to
> - *		     set or clear it.
>    *
>    * This represents WMI devices discovered by the WMI driver core.
>    */
>   struct wmi_device {
>   	struct device dev;
>   	bool setable;
> -	const char *driver_override;
>   };
>   
>   /**

^ permalink raw reply

* [PATCH net,v2] net: mana: Fix RX skb truesize accounting
From: Dipayaan Roy @ 2026-03-24 18:14 UTC (permalink / raw)
  To: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
	kuba, pabeni, leon, longli, kotaranov, horms, shradhagupta,
	ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
	linux-rdma, stephen, jacob.e.keller, dipayanroy

MANA passes rxq->alloc_size to napi_build_skb() for all RX buffers.
It is correct for fragment-backed RX buffers, where alloc_size matches
the actual backing allocation used for each packet buffer. However, in
the non-fragment RX path mana allocates a full page, or a higher-order
page, per RX buffer. In that case alloc_size only reflects the usable
packet area and not the actual backing memory.

This causes napi_build_skb() to underestimate the skb backing allocation
in the single-buffer RX path, so skb->truesize is derived from a value
smaller than the real RX buffer allocation.

Fix this by updating alloc_size in the non-fragment RX path to the
actual backing allocation size before it is passed to napi_build_skb().

Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")
Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
---
Changes in v2:
 - Added maintainers missed in v1.
---
 drivers/net/ethernet/microsoft/mana/mana_en.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index ea71de39f996..884f8e548174 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -766,6 +766,13 @@ static void mana_get_rxbuf_cfg(struct mana_port_context *apc,
 		}
 
 		*frag_count = 1;
+
+		/* In the single-buffer path, napi_build_skb() must see the
+		 * actual backing allocation size so skb->truesize reflects
+		 * the full page (or higher-order page), not just the usable
+		 * packet area.
+		 */
+		*alloc_size = PAGE_SIZE << get_order(*alloc_size);
 		return;
 	}
 
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH v4 05/21] mm: switch the rmap lock held option off in compat layer
From: Lorenzo Stoakes (Oracle) @ 2026-03-24 16:35 UTC (permalink / raw)
  To: Vlastimil Babka (SUSE)
  Cc: Andrew Morton, Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
	Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
	Alexandre Torgue, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
	David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
	Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
	linux-kernel, linux-doc, linux-hyperv, linux-stm32,
	linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
	target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <d5b66671-697f-4a4d-8039-d9c9ac5ad4d7@kernel.org>

On Tue, Mar 24, 2026 at 03:26:28PM +0100, Vlastimil Babka (SUSE) wrote:
> On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> > In the mmap_prepare compatibility layer, we don't need to hold the rmap
> > lock, as we are being called from an .mmap handler.
> >
> > The .mmap_prepare hook, when invoked in the VMA logic, is called prior to
> > the VMA being instantiated, but the completion hook is called after the VMA
> > is linked into the maple tree, meaning rmap walkers can reach it.
> >
> > The mmap hook does not link the VMA into the tree, so this cannot happen.
> >
> > Therefore it's safe to simply disable this in the mmap_prepare
> > compatibility layer.
> >
> > Also update VMA tests code to reflect current compatibility layer state.
> >
> > Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
>
> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>
> a typo fix below, Andrew can fix locally?
>
> > ---
> >  mm/util.c                       |  6 ++++-
> >  tools/testing/vma/include/dup.h | 42 +++++++++++++++++----------------
> >  2 files changed, 27 insertions(+), 21 deletions(-)
> >
> > diff --git a/mm/util.c b/mm/util.c
> > index a2cfa0d77c35..182f0f5cc400 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -1204,6 +1204,7 @@ int compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
> >
> >  		.action.type = MMAP_NOTHING, /* Default */
> >  	};
> > +	struct mmap_action *action = &desc.action;
> >  	int err;
> >
> >  	err = vfs_mmap_prepare(file, &desc);
> > @@ -1214,8 +1215,11 @@ int compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
> >  	if (err)
> >  		return err;
> >
> > +	/* being invoked from .mmmap means we don't have to enforce this. */
>
> 				.mmap

mmmmm map! ;)

Andrew - could you fixup in place? Thanks.

>
> > +	action->hide_from_rmap_until_complete = false;
> > +
> >  	set_vma_from_desc(vma, &desc);
> > -	err = mmap_action_complete(vma, &desc.action);
> > +	err = mmap_action_complete(vma, action);
> >  	if (err) {
> >  		const size_t len = vma_pages(vma) << PAGE_SHIFT;
> >

^ permalink raw reply

* Re: [PATCH net-next v4] net: mana: Expose hardware diagnostic info via debugfs
From: Erni Sri Satya Vennela @ 2026-03-24 16:20 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
	edumazet, pabeni, kotaranov, horms, shradhagupta, shirazsaleem,
	dipayanroy, yury.norov, kees, ssengar, gargaditya, linux-hyperv,
	netdev, linux-kernel, linux-rdma
In-Reply-To: <20260323174444.2717da3d@kernel.org>

On Mon, Mar 23, 2026 at 05:44:44PM -0700, Jakub Kicinski wrote:
> On Thu, 19 Mar 2026 00:09:13 -0700 Erni Sri Satya Vennela wrote:
> > Add debugfs entries to expose hardware configuration and diagnostic
> > information that aids in debugging driver initialization and runtime
> > operations without adding noise to dmesg.
> > 
> > The debugfs directory creation and removal for each PCI device is
> > integrated into mana_gd_setup() and mana_gd_cleanup_device()
> > respectively, so that all callers (probe, remove, suspend, resume,
> > shutdown) share a single code path.
> > 
> > Device-level entries (under /sys/kernel/debug/mana/<slot>/):
> >   - num_msix_usable, max_num_queues: Max resources from hardware
> >   - gdma_protocol_ver, pf_cap_flags1: VF version negotiation results
> >   - num_vports, bm_hostmode: Device configuration
> > 
> > Per-vPort entries (under /sys/kernel/debug/mana/<slot>/vportN/):
> >   - port_handle: Hardware vPort handle
> >   - max_sq, max_rq: Max queues from vPort config
> >   - indir_table_sz: Indirection table size
> >   - steer_rx, steer_rss, steer_update_tab, steer_cqe_coalescing:
> >     Last applied steering configuration parameters
> 
> AI says:
> 
> > @@ -1918,15 +1930,23 @@ static int mana_gd_setup(struct pci_dev *pdev)
> >  	struct gdma_context *gc = pci_get_drvdata(pdev);
> >  	int err;
> >  
> > +	if (gc->is_pf)
> > +		gc->mana_pci_debugfs = debugfs_create_dir("0", mana_debugfs_root);
> > +	else
> > +		gc->mana_pci_debugfs = debugfs_create_dir(pci_slot_name(pdev->slot),
> > +							  mana_debugfs_root);
> 
> If pdev->slot is NULL (which can happen for VFs in environments like generic
> VFIO passthrough or nested KVM), will pci_slot_name(pdev->slot) cause a
> NULL pointer dereference?
> 
> Also, could this naming scheme cause name collisions? If multiple PFs are
> present, they would all try to use "0". Similarly, VFs across different
> PCI domains or buses might share the same physical slot identifier, leading
> to -EEXIST errors. Would it be safer to use the unique PCI BDF via
> pci_name(pdev) instead?
Yes. that is a better way to handle it. I will use pci_name. We can
remove if-else and use only one for both the cases.
> 
> > @@ -3141,6 +3149,24 @@ static int mana_init_port(struct net_device *ndev)
> >  	eth_hw_addr_set(ndev, apc->mac_addr);
> >  	sprintf(vport, "vport%d", port_idx);
> >  	apc->mana_port_debugfs = debugfs_create_dir(vport, gc->mana_pci_debugfs);
> > +
> > +	debugfs_create_u64("port_handle", 0400, apc->mana_port_debugfs,
> > +			   &apc->port_handle);
> 
> When operations like changing the MTU or setting an XDP program trigger a
> detach/attach cycle, mana_detach() invokes mana_cleanup_port_context(),
> which recursively removes the apc->mana_port_debugfs directory.
> During re-attachment, mana_attach() calls mana_init_port(), which
> recreates the directory and the new files added in this patch. However, the
> pre-existing current_speed file (created in mana_probe_port()) is not
> recreated here.
> 
> Does this cause the current_speed file to be permanently lost after a
> detach/attach cycle? Should the creation of current_speed be moved to
> mana_init_port() so it survives the cycle?
Yes that is correct.

Since these issues are pre-existing and not introduced from my patch.
I'll plan to send them as different patch with fixes tag.
> -- 
> pw-bot: cr

^ permalink raw reply

* Re: [PATCH v4 08/21] mm: add vm_ops->mapped hook
From: Vlastimil Babka (SUSE) @ 2026-03-24 15:32 UTC (permalink / raw)
  To: Lorenzo Stoakes (Oracle), Andrew Morton
  Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
	Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
	Alexandre Torgue, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
	David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
	Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
	linux-kernel, linux-doc, linux-hyperv, linux-stm32,
	linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
	target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <4c5e98297eb0aae9565c564e1c296a112702f144.1774045440.git.ljs@kernel.org>

On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Previously, when a driver needed to do something like establish a
> reference count, it could do so in the mmap hook in the knowledge that the
> mapping would succeed.
> 
> With the introduction of f_op->mmap_prepare this is no longer the case, as
> it is invoked prior to actually establishing the mapping.
> 
> mmap_prepare is not appropriate for this kind of thing as it is called
> before any merge might take place, and after which an error might occur
> meaning resources could be leaked.
> 
> To take this into account, introduce a new vm_ops->mapped callback which
> is invoked when the VMA is first mapped (though notably - not when it is
> merged - which is correct and mirrors existing mmap/open/close behaviour).
> 
> We do better that vm_ops->open() here, as this callback can return an
> error, at which point the VMA will be unmapped.
> 
> Note that vm_ops->mapped() is invoked after any mmap action is complete
> (such as I/O remapping).
> 
> We intentionally do not expose the VMA at this point, exposing only the
> fields that could be used, and an output parameter in case the operation
> needs to update the vma->vm_private_data field.
> 
> In order to deal with stacked filesystems which invoke inner filesystem's
> mmap() invocations, add __compat_vma_mapped() and invoke it on vfs_mmap()
> (via compat_vma_mmap()) to ensure that the mapped callback is handled when
> an mmap() caller invokes a nested filesystem's mmap_prepare() callback.
> 
> Update the mmap_prepare documentation to describe the mapped hook and make
> it clear what its intended use is.
> 
> The vm_ops->mapped() call is handled by the mmap complete logic to ensure
> the same code paths are handled by both the compatibility and VMA layers.
> 
> Additionally, update VMA userland test headers to reflect the change.
> 
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>



^ permalink raw reply

* Re: [PATCH v8 09/10] x86/hyperv/vtl: Mark the wakeup mailbox page as private
From: Wei Liu @ 2026-03-24 15:03 UTC (permalink / raw)
  To: Ricardo Neri
  Cc: Wei Liu, x86, Krzysztof Kozlowski, Conor Dooley, Rob Herring,
	K. Y. Srinivasan, Haiyang Zhang, Dexuan Cui, Michael Kelley,
	Rafael J. Wysocki, Saurabh Sengar, Chris Oo, Kirill A. Shutemov,
	linux-hyperv, devicetree, linux-acpi, linux-kernel, Ricardo Neri,
	Yunhong Jiang
In-Reply-To: <20260320230147.GA31320@ranerica-svr.sc.intel.com>

On Fri, Mar 20, 2026 at 04:01:47PM -0700, Ricardo Neri wrote:
> On Mon, Mar 09, 2026 at 05:57:33PM +0000, Wei Liu wrote:
> > Dexuan, are you happy with the patch? You can also delegate to Saurabh
> > if you think it's more appropriate. Thanks!
> 
> Hi Wei,
> 
> I just realized you replied to an older version of the patch. Here is the
> most recent version:
> 
> https://lore.kernel.org/all/20260304-rneri-wakeup-mailbox-v9-9-a5c6845e6251@linux.intel.com/
> 
> The whole series:
> 
> https://lore.kernel.org/all/20260304-rneri-wakeup-mailbox-v9-0-a5c6845e6251@linux.intel.com/
> 

No worries. I saw the new series after that reply.

Wei

> Thanks and BR,
> Ricardo
> 
> 

^ permalink raw reply

* Re: [PATCH v4 07/21] mm: have mmap_action_complete() handle the rmap lock and unmap
From: Vlastimil Babka (SUSE) @ 2026-03-24 14:38 UTC (permalink / raw)
  To: Lorenzo Stoakes (Oracle), Andrew Morton
  Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
	Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
	Alexandre Torgue, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
	David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
	Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
	linux-kernel, linux-doc, linux-hyperv, linux-stm32,
	linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
	target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <8d1ee8ebd3542d006a47e8382fb80cf5b57ecf10.1774045440.git.ljs@kernel.org>

On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Rather than have the callers handle this both the rmap lock release and
> unmapping the VMA on error, handle it within the mmap_action_complete()
> logic where it makes sense to, being careful not to unlock twice.
> 
> This simplifies the logic and makes it harder to make mistake with this,
> while retaining correct behaviour with regard to avoiding deadlocks.
> 
> Also replace the call_action_complete() function with a direct invocation
> of mmap_action_complete() as the abstraction is no longer required.
> 
> Also update the VMA tests to reflect this change.
> 
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

Nice simplification.

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>


^ permalink raw reply

* Re: [PATCH v4 06/21] mm/vma: remove superfluous map->hold_file_rmap_lock
From: Vlastimil Babka (SUSE) @ 2026-03-24 14:31 UTC (permalink / raw)
  To: Lorenzo Stoakes (Oracle), Andrew Morton
  Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
	Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
	Alexandre Torgue, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
	David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
	Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
	linux-kernel, linux-doc, linux-hyperv, linux-stm32,
	linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
	target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <42c3fbb701e361a17193ecda0d2dabcc326288a5.1774045440.git.ljs@kernel.org>

On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> We don't need to reference this field, it's confusing as it duplicates
> mmap_action->hide_from_rmap_until_complete, so thread the mmap_action
> through to __mmap_new_vma() instead and use the same field consistently.
> 
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>


^ permalink raw reply

* Re: [PATCH v4 05/21] mm: switch the rmap lock held option off in compat layer
From: Vlastimil Babka (SUSE) @ 2026-03-24 14:26 UTC (permalink / raw)
  To: Lorenzo Stoakes (Oracle), Andrew Morton
  Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
	Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
	Alexandre Torgue, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
	David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
	Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
	linux-kernel, linux-doc, linux-hyperv, linux-stm32,
	linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
	target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <dda74230d26a1fcd79a3efab61fa4101dd1cac64.1774045440.git.ljs@kernel.org>

On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> In the mmap_prepare compatibility layer, we don't need to hold the rmap
> lock, as we are being called from an .mmap handler.
> 
> The .mmap_prepare hook, when invoked in the VMA logic, is called prior to
> the VMA being instantiated, but the completion hook is called after the VMA
> is linked into the maple tree, meaning rmap walkers can reach it.
> 
> The mmap hook does not link the VMA into the tree, so this cannot happen.
> 
> Therefore it's safe to simply disable this in the mmap_prepare
> compatibility layer.
> 
> Also update VMA tests code to reflect current compatibility layer state.
> 
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>

a typo fix below, Andrew can fix locally?

> ---
>  mm/util.c                       |  6 ++++-
>  tools/testing/vma/include/dup.h | 42 +++++++++++++++++----------------
>  2 files changed, 27 insertions(+), 21 deletions(-)
> 
> diff --git a/mm/util.c b/mm/util.c
> index a2cfa0d77c35..182f0f5cc400 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -1204,6 +1204,7 @@ int compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
> 
>  		.action.type = MMAP_NOTHING, /* Default */
>  	};
> +	struct mmap_action *action = &desc.action;
>  	int err;
> 
>  	err = vfs_mmap_prepare(file, &desc);
> @@ -1214,8 +1215,11 @@ int compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
>  	if (err)
>  		return err;
> 
> +	/* being invoked from .mmmap means we don't have to enforce this. */

				.mmap

> +	action->hide_from_rmap_until_complete = false;
> +
>  	set_vma_from_desc(vma, &desc);
> -	err = mmap_action_complete(vma, &desc.action);
> +	err = mmap_action_complete(vma, action);
>  	if (err) {
>  		const size_t len = vma_pages(vma) << PAGE_SHIFT;
> 

^ permalink raw reply

* Re: [PATCH 10/12] s390/ap: use generic driver_override infrastructure
From: Holger Dengler @ 2026-03-24 12:58 UTC (permalink / raw)
  To: Danilo Krummrich, Russell King, Greg Kroah-Hartman,
	Rafael J. Wysocki, Ioana Ciornei, Nipun Gupta, Nikhil Agarwal,
	K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
	Bjorn Helgaas, Armin Wolf, Bjorn Andersson, Mathieu Poirier,
	Vineeth Vijayan, Peter Oberparleiter, Heiko Carstens,
	Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
	Sven Schnelle, Harald Freudenberger, Mark Brown,
	Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
	Alex Williamson, Juergen Gross, Stefano Stabellini,
	Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
  Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
	platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
	linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <20260324005919.2408620-11-dakr@kernel.org>

On 24/03/2026 01:59, Danilo Krummrich wrote:
> When the AP masks are updated via apmask_store() or aqmask_store(),
> ap_bus_revise_bindings() is called after ap_attr_mutex has been
> released.
> 
> This calls __ap_revise_reserved(), which accesses the driver_override
> field without holding any lock, racing against a concurrent
> driver_override_store() that may free the old string, resulting in a
> potential UAF.
> 
> Fix this by using the driver-core driver_override infrastructure, which
> protects all accesses with an internal spinlock.
> 
> Note that unlike most other buses, the AP bus does not check
> driver_override in its match() callback; the override is checked in
> ap_device_probe() and __ap_revise_reserved() instead.
> 
> Also note that we do not enable the driver_override feature of struct
> bus_type, as AP - in contrast to most other buses - passes "" to
> sysfs_emit() when the driver_override pointer is NULL. Thus, printing
> "\n" instead of "(null)\n".
> 
> Additionally, AP has a custom counter that is modified in the
> corresponding custom driver_override_store().
> 
> Fixes: d38a87d7c064 ("s390/ap: Support driver_override for AP queue devices")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>

Tested-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>

-- 
Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
dengler@linux.ibm.com


^ permalink raw reply

* Re: [PATCH 10/12] s390/ap: use generic driver_override infrastructure
From: Harald Freudenberger @ 2026-03-24 12:41 UTC (permalink / raw)
  To: Danilo Krummrich
  Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
	Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
	Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
	Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
	Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Holger Dengler, Mark Brown, Michael S. Tsirkin, Jason Wang,
	Xuan Zhuo, Eugenio Pérez, Alex Williamson, Juergen Gross,
	Stefano Stabellini, Oleksandr Tyshchenko,
	Christophe Leroy (CS GROUP), linux-kernel, driver-core,
	linuxppc-dev, linux-hyperv, linux-pci, platform-driver-x86,
	linux-arm-msm, linux-remoteproc, linux-s390, linux-spi,
	virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <20260324005919.2408620-11-dakr@kernel.org>

On 2026-03-24 01:59, Danilo Krummrich wrote:
> When the AP masks are updated via apmask_store() or aqmask_store(),
> ap_bus_revise_bindings() is called after ap_attr_mutex has been
> released.
> 
> This calls __ap_revise_reserved(), which accesses the driver_override
> field without holding any lock, racing against a concurrent
> driver_override_store() that may free the old string, resulting in a
> potential UAF.
> 
> Fix this by using the driver-core driver_override infrastructure, which
> protects all accesses with an internal spinlock.
> 
> Note that unlike most other buses, the AP bus does not check
> driver_override in its match() callback; the override is checked in
> ap_device_probe() and __ap_revise_reserved() instead.
> 
> Also note that we do not enable the driver_override feature of struct
> bus_type, as AP - in contrast to most other buses - passes "" to
> sysfs_emit() when the driver_override pointer is NULL. Thus, printing
> "\n" instead of "(null)\n".
> 
> Additionally, AP has a custom counter that is modified in the
> corresponding custom driver_override_store().
> 
> Fixes: d38a87d7c064 ("s390/ap: Support driver_override for AP queue 
> devices")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---
>  drivers/s390/crypto/ap_bus.c   | 34 +++++++++++++++++-----------------
>  drivers/s390/crypto/ap_bus.h   |  1 -
>  drivers/s390/crypto/ap_queue.c | 24 ++++++------------------
>  3 files changed, 23 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/s390/crypto/ap_bus.c 
> b/drivers/s390/crypto/ap_bus.c
> index d652df96a507..f24e27add721 100644
> --- a/drivers/s390/crypto/ap_bus.c
> +++ b/drivers/s390/crypto/ap_bus.c
> @@ -859,25 +859,24 @@ static int
> __ap_queue_devices_with_id_unregister(struct device *dev, void *data)
> 
>  static int __ap_revise_reserved(struct device *dev, void *dummy)
>  {
> -	int rc, card, queue, devres, drvres;
> +	int rc, card, queue, devres, drvres, ovrd;
> 
>  	if (is_queue_dev(dev)) {
>  		struct ap_driver *ap_drv = to_ap_drv(dev->driver);
>  		struct ap_queue *aq = to_ap_queue(dev);
> -		struct ap_device *ap_dev = &aq->ap_dev;
> 
>  		card = AP_QID_CARD(aq->qid);
>  		queue = AP_QID_QUEUE(aq->qid);
> 
> -		if (ap_dev->driver_override) {
> -			if (strcmp(ap_dev->driver_override,
> -				   ap_drv->driver.name)) {
> -				pr_debug("reprobing queue=%02x.%04x\n", card, queue);
> -				rc = device_reprobe(dev);
> -				if (rc) {
> -					AP_DBF_WARN("%s reprobing queue=%02x.%04x failed\n",
> -						    __func__, card, queue);
> -				}
> +		ovrd = device_match_driver_override(dev, &ap_drv->driver);
> +		if (ovrd > 0) {
> +			/* override set and matches, nothing to do */
> +		} else if (ovrd == 0) {
> +			pr_debug("reprobing queue=%02x.%04x\n", card, queue);
> +			rc = device_reprobe(dev);
> +			if (rc) {
> +				AP_DBF_WARN("%s reprobing queue=%02x.%04x failed\n",
> +					    __func__, card, queue);
>  			}
>  		} else {
>  			mutex_lock(&ap_attr_mutex);
> @@ -928,7 +927,7 @@ int ap_owned_by_def_drv(int card, int queue)
>  	if (aq) {
>  		const struct device_driver *drv = aq->ap_dev.device.driver;
>  		const struct ap_driver *ap_drv = to_ap_drv(drv);
> -		bool override = !!aq->ap_dev.driver_override;
> +		bool override = device_has_driver_override(&aq->ap_dev.device);
> 
>  		if (override && drv && ap_drv->flags & AP_DRIVER_FLAG_DEFAULT)
>  			rc = 1;
> @@ -977,7 +976,7 @@ static int ap_device_probe(struct device *dev)
>  {
>  	struct ap_device *ap_dev = to_ap_dev(dev);
>  	struct ap_driver *ap_drv = to_ap_drv(dev->driver);
> -	int card, queue, devres, drvres, rc = -ENODEV;
> +	int card, queue, devres, drvres, rc = -ENODEV, ovrd;
> 
>  	if (!get_device(dev))
>  		return rc;
> @@ -991,10 +990,11 @@ static int ap_device_probe(struct device *dev)
>  		 */
>  		card = AP_QID_CARD(to_ap_queue(dev)->qid);
>  		queue = AP_QID_QUEUE(to_ap_queue(dev)->qid);
> -		if (ap_dev->driver_override) {
> -			if (strcmp(ap_dev->driver_override,
> -				   ap_drv->driver.name))
> -				goto out;
> +		ovrd = device_match_driver_override(dev, &ap_drv->driver);
> +		if (ovrd > 0) {
> +			/* override set and matches, nothing to do */
> +		} else if (ovrd == 0) {
> +			goto out;
>  		} else {
>  			mutex_lock(&ap_attr_mutex);
>  			devres = test_bit_inv(card, ap_perms.apm) &&
> diff --git a/drivers/s390/crypto/ap_bus.h 
> b/drivers/s390/crypto/ap_bus.h
> index 51e08f27bd75..04ea256ecf91 100644
> --- a/drivers/s390/crypto/ap_bus.h
> +++ b/drivers/s390/crypto/ap_bus.h
> @@ -166,7 +166,6 @@ void ap_driver_unregister(struct ap_driver *);
>  struct ap_device {
>  	struct device device;
>  	int device_type;		/* AP device type. */
> -	const char *driver_override;
>  };
> 
>  #define to_ap_dev(x) container_of((x), struct ap_device, device)
> diff --git a/drivers/s390/crypto/ap_queue.c 
> b/drivers/s390/crypto/ap_queue.c
> index 3fe2e41c5c6b..ca9819e6f7e7 100644
> --- a/drivers/s390/crypto/ap_queue.c
> +++ b/drivers/s390/crypto/ap_queue.c
> @@ -734,26 +734,14 @@ static ssize_t driver_override_show(struct device 
> *dev,
>  				    struct device_attribute *attr,
>  				    char *buf)
>  {
> -	struct ap_queue *aq = to_ap_queue(dev);
> -	struct ap_device *ap_dev = &aq->ap_dev;
> -	int rc;
> -
> -	device_lock(dev);
> -	if (ap_dev->driver_override)
> -		rc = sysfs_emit(buf, "%s\n", ap_dev->driver_override);
> -	else
> -		rc = sysfs_emit(buf, "\n");
> -	device_unlock(dev);
> -
> -	return rc;
> +	guard(spinlock)(&dev->driver_override.lock);
> +	return sysfs_emit(buf, "%s\n", dev->driver_override.name ?: "");
>  }
> 
>  static ssize_t driver_override_store(struct device *dev,
>  				     struct device_attribute *attr,
>  				     const char *buf, size_t count)
>  {
> -	struct ap_queue *aq = to_ap_queue(dev);
> -	struct ap_device *ap_dev = &aq->ap_dev;
>  	int rc = -EINVAL;
>  	bool old_value;
> 
> @@ -764,13 +752,13 @@ static ssize_t driver_override_store(struct 
> device *dev,
>  	if (ap_apmask_aqmask_in_use)
>  		goto out;
> 
> -	old_value = ap_dev->driver_override ? true : false;
> -	rc = driver_set_override(dev, &ap_dev->driver_override, buf, count);
> +	old_value = device_has_driver_override(dev);
> +	rc = __device_set_driver_override(dev, buf, count);
>  	if (rc)
>  		goto out;
> -	if (old_value && !ap_dev->driver_override)
> +	if (old_value && !device_has_driver_override(dev))
>  		--ap_driver_override_ctr;
> -	else if (!old_value && ap_dev->driver_override)
> +	else if (!old_value && device_has_driver_override(dev))
>  		++ap_driver_override_ctr;
> 
>  	rc = count;

Thanks Danilo
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>

^ permalink raw reply

* Re: [PATCH] hv_sock: update outdated comment for renamed vsock_stream_recvmsg()
From: patchwork-bot+netdevbpf @ 2026-03-24 12:20 UTC (permalink / raw)
  To: Kexin Sun
  Cc: kys, haiyangz, wei.liu, decui, longli, sgarzare, davem, edumazet,
	kuba, pabeni, horms, linux-hyperv, virtualization, netdev,
	linux-kernel, julia.lawall, xutong.ma, yunbolyu, ratnadiraw
In-Reply-To: <20260321105753.6751-1-kexinsun@smail.nju.edu.cn>

Hello:

This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Sat, 21 Mar 2026 18:57:53 +0800 you wrote:
> The function vsock_stream_recvmsg() was renamed to
> vsock_connectible_recvmsg() by commit a9e29e5511b9 ("af_vsock:
> update functions for connectible socket").  Update the comment
> accordingly.
> 
> Assisted-by: unnamed:deepseek-v3.2 coccinelle
> Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn>
> 
> [...]

Here is the summary with links:
  - hv_sock: update outdated comment for renamed vsock_stream_recvmsg()
    https://git.kernel.org/netdev/net-next/c/88c07dff9f6d

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply

* [PATCH AUTOSEL 6.19] mshv: Fix error handling in mshv_region_pin
From: Sasha Levin @ 2026-03-24 11:19 UTC (permalink / raw)
  To: patches, stable
  Cc: Stanislav Kinsburskii, Michael Kelley, Wei Liu, Sasha Levin, kys,
	haiyangz, decui, longli, linux-hyperv, linux-kernel
In-Reply-To: <20260324111931.3257972-1-sashal@kernel.org>

From: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>

[ Upstream commit c0e296f257671ba10249630fe58026f29e4804d9 ]

The current error handling has two issues:

First, pin_user_pages_fast() can return a short pin count (less than
requested but greater than zero) when it cannot pin all requested pages.
This is treated as success, leading to partially pinned regions being
used, which causes memory corruption.

Second, when an error occurs mid-loop, already pinned pages from the
current batch are not properly accounted for before calling
mshv_region_invalidate_pages(), causing a page reference leak.

Treat short pins as errors and fix partial batch accounting before
cleanup.

Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The buggy code is confirmed in v6.19.y stable. Now let me complete the
remaining phases.

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `mshv` (Microsoft Hyper-V root driver)
- Action: "Fix" - explicitly a bug fix
- Summary: Fix error handling in mshv_region_pin

Record: [mshv] [fix] [error handling for pin_user_pages_fast short pin
counts and partial batch accounting]

**Step 1.2: Tags**
- Signed-off-by: Stanislav Kinsburskii (author, also the mshv subsystem
  contributor)
- Reviewed-by: Michael Kelley (known Hyper-V reviewer)
- Signed-off-by: Wei Liu (Hyper-V maintainer)
- No Fixes: tag (expected for candidates under review)
- No Reported-by (likely found via code review)

Record: Reviewed by a known Hyper-V developer, applied by the subsystem
maintainer.

**Step 1.3: Body Text**
Two distinct bugs described:
1. `pin_user_pages_fast()` returning a short pin count (0 < ret <
   nr_pages) treated as success → partially pinned regions used →
   **memory corruption**
2. When error occurs mid-loop, partial batch pages not accounted for
   before cleanup → **page reference leak**

Record: Bug 1 = memory corruption from partially pinned regions. Bug 2 =
page reference leak. No stack traces or user reports, likely found via
code inspection.

**Step 1.4: Hidden Bug Fix Detection**
Not hidden - explicitly described as a bug fix. Both bugs are real and
well-described.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file: `drivers/hv/mshv_regions.c`
- Changes: ~4 lines modified in `mshv_region_pin()`
- Scope: Single-function surgical fix

**Step 2.2: Code Flow Change**
Three hunks:
1. `if (ret < 0)` → `if (ret != nr_pages)`: Before, short pin counts
   (e.g., requested 100 pages, got 50) were treated as success. After,
   any short pin is treated as an error.
2. Added `if (ret > 0) done_count += ret;` before cleanup: Before,
   partial pins from the current batch were not accounted for in
   `done_count`. After, they are properly counted so
   `mshv_region_invalidate_pages()` unpins all actually-pinned pages.
3. `return ret;` → `return ret < 0 ? ret : -ENOMEM;`: Proper error code
   when short pin occurs (ret > 0 is not an error code, so convert to
   -ENOMEM).

**Step 2.3: Bug Mechanism**
- Category: Memory safety / resource leak fix
- Bug 1: Using partially-pinned memory regions leads to accessing
  unpinned pages → memory corruption
- Bug 2: Missing accounting of partial batch on error → leaked page
  references (pages remain pinned but never unpinned)

**Step 2.4: Fix Quality**
- Obviously correct: the `pin_user_pages_fast()` API explicitly
  documents short pin returns
- Minimal/surgical: 4 lines changed
- No regression risk: the fix only makes error handling stricter and
  more correct

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
Verified via `git blame`: The buggy code was introduced in commit
`e950c30a1051d` (v6.19), but the same bug pattern existed since
`621191d709b14` (v6.15) when the mshv driver was first introduced in
`mshv_root_main.c`.

**Step 3.2: Fixes Tag**
No explicit Fixes: tag present. The bug originates from the initial
introduction of the pin logic.

**Step 3.3: File History**
8 commits to mshv_regions.c total, all since v6.19. The file was created
by moving code from mshv_root_main.c.

**Step 3.4: Author**
Stanislav Kinsburskii is the primary contributor to the mshv driver
subsystem (authored the majority of mshv_regions.c commits). This is a
fix by someone deeply familiar with the code.

**Step 3.5: Dependencies**
The fix is self-contained. No prerequisites needed.

## PHASE 4: MAILING LIST (skipping WebFetch for efficiency - the commit
is clearly a bug fix)

## PHASE 5: CODE SEMANTIC ANALYSIS

`mshv_region_pin()` is called from `mshv_prepare_pinned_region()`
(mshv_root_main.c:1214), which is the path for setting up memory regions
for Hyper-V virtual machines. This is a core operation for any VM
creation with the mshv driver.

`mshv_region_invalidate_pages()` (the cleanup function) calls
`unpin_user_pages()` on the pages. If `done_count` doesn't include the
partial batch, those pages leak.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code in Stable Trees**
- The mshv driver was introduced in v6.15
- The file `mshv_regions.c` was created in v6.19
- The buggy pin pattern existed in `mshv_root_main.c` since v6.15
- Current active stable: 6.19.y has the bug in `mshv_regions.c`
- LTS trees (6.12.y, 6.6.y, 6.1.y, 5.15.y, 5.10.y) do NOT have the mshv
  driver at all

**Step 6.2: Backport Complications**
The patch applies cleanly to 6.19.y. For older stable trees (6.15-6.18
if still maintained), the code is in a different file
(`mshv_root_main.c`) and has a slightly different structure, requiring
rework.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** drivers/hv/ = Hyper-V virtualization driver. PERIPHERAL to
IMPORTANT for Hyper-V users (Azure VMs, Windows/Linux hybrid
environments).

**Step 7.2:** Active subsystem with ongoing development in v6.19.

## PHASE 8: IMPACT AND RISK

**Step 8.1: Who is Affected**
Users running the mshv_root driver (Hyper-V root partition users
creating VMs). This is a specific but important use case (Azure/Hyper-V
environments).

**Step 8.2: Trigger Conditions**
The short pin count from `pin_user_pages_fast()` can occur when:
- Memory pressure causes some pages to fail pinning
- The user address range crosses VMA boundaries
- Pages are swapped out or otherwise unavailable
These are real-world conditions that can occur under memory pressure.

**Step 8.3: Failure Mode Severity**
- Memory corruption (CRITICAL): partially pinned regions used as if
  fully pinned
- Page reference leak (HIGH): leaked page references prevent page
  reclaim

**Step 8.4: Risk-Benefit**
- Benefit: HIGH - prevents memory corruption and resource leaks
- Risk: VERY LOW - 4 lines, obviously correct, single function, error
  path only
- Ratio: Excellent

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes memory corruption (CRITICAL severity)
- Fixes page reference leak (HIGH severity)
- Tiny, surgical fix (4 lines in one function)
- Obviously correct - matches well-documented `pin_user_pages_fast()`
  API semantics
- Reviewed by Hyper-V maintainer (Michael Kelley)
- Applied by subsystem maintainer (Wei Liu)
- Author is primary contributor to the code
- Self-contained, no dependencies

**Evidence AGAINST backporting:**
- Only relevant to 6.19.y (and potentially 6.15-6.18 with rework)
- The mshv driver is relatively new and has a limited user base
- Not reported by users (found via code review)
- LTS trees are unaffected (driver doesn't exist there)

**Stable Rules Checklist:**
1. Obviously correct and tested? **YES** - reviewed by maintainer,
   trivially verifiable
2. Fixes a real bug? **YES** - memory corruption and page leak
3. Important issue? **YES** - memory corruption is critical
4. Small and contained? **YES** - 4 lines, single function
5. No new features or APIs? **YES** - pure bug fix
6. Can apply to stable trees? **YES** - applies cleanly to 6.19.y

## Verification

- [Phase 1] Parsed tags: Reviewed-by Michael Kelley, Signed-off-by Wei
  Liu (maintainer)
- [Phase 2] Diff analysis: 4 lines changed in mshv_region_pin() error
  handling - changes `ret < 0` to `ret != nr_pages`, adds partial batch
  accounting, fixes return code
- [Phase 3] git blame: buggy code from e950c30a1051d (v6.19), originally
  from 621191d709b14 (v6.15)
- [Phase 3] git show v6.15 mshv_root_main.c: confirmed same bug pattern
  (`if (ret < 0)`) in original driver
- [Phase 3] git tag --contains: mshv driver introduced in v6.15, file
  moved in v6.19
- [Phase 5] grep callers: mshv_region_pin called from
  mshv_prepare_pinned_region (VM memory setup path)
- [Phase 6] v6.19 release code verified: buggy `if (ret < 0)` present in
  v6.19:drivers/hv/mshv_regions.c
- [Phase 6] LTS trees (6.12.y and older): mshv driver does not exist,
  not affected
- [Phase 8] Failure mode: memory corruption from partially pinned
  regions + page reference leak, CRITICAL severity

The fix is small, surgical, and obviously correct. It fixes a memory
corruption bug that can be triggered under real-world memory pressure
conditions. It meets all stable kernel criteria.

**YES**

 drivers/hv/mshv_regions.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
index adba3564d9f1a..baa864cac375a 100644
--- a/drivers/hv/mshv_regions.c
+++ b/drivers/hv/mshv_regions.c
@@ -314,15 +314,17 @@ int mshv_region_pin(struct mshv_mem_region *region)
 		ret = pin_user_pages_fast(userspace_addr, nr_pages,
 					  FOLL_WRITE | FOLL_LONGTERM,
 					  pages);
-		if (ret < 0)
+		if (ret != nr_pages)
 			goto release_pages;
 	}
 
 	return 0;
 
 release_pages:
+	if (ret > 0)
+		done_count += ret;
 	mshv_region_invalidate_pages(region, 0, done_count);
-	return ret;
+	return ret < 0 ? ret : -ENOMEM;
 }
 
 static int mshv_region_chunk_unmap(struct mshv_mem_region *region,
-- 
2.51.0


^ permalink raw reply related

* Re: [PATCH net-next] net: mana: Use at least SZ_4K in doorbell ID range check
From: Paolo Abeni @ 2026-03-24 11:03 UTC (permalink / raw)
  To: Simon Horman, Erni Sri Satya Vennela
  Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
	edumazet, kuba, shradhagupta, dipayanroy, shirazsaleem, kotaranov,
	yury.norov, kees, linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260321100425.GX74886@horms.kernel.org>



On 3/21/26 11:04 AM, Simon Horman wrote:
> On Fri, Mar 20, 2026 at 05:21:01AM -0700, Erni Sri Satya Vennela wrote:
>> mana_gd_ring_doorbell() accesses doorbell offsets up to 0xFF8 + 8 = 4KB
>> within a doorbell page. When db_page_size is zero, the validation check
>> in mana_gd_register_device() reduces to:
>>   db_page_off + 0 > bar0_size
>> which passes, even though mana_gd_ring_doorbell() will access
>> [db_page_off, db_page_off + 4KB) and may go beyond BAR0.
>>
>> Use max(SZ_4K, db_page_size) in the range check so that a zero or
>> unexpectedly small db_page_size still results in a rejection when the
>> doorbell page would fall outside BAR0.
> 
> Thanks Erni,
> 
> I understand the maths here. And to that extent this change makes sense to me.
> But I am curious to know how a db_page_size of zero works. I was expecting
> some space is required there.

To rephrase Simon's question, this feels like papering over a
memory/state corruption. I think at best it deserves a cleaner explanation.

/P


^ permalink raw reply

* Re: [PATCH v4 04/21] mm: avoid deadlock when holding rmap on mmap_prepare error
From: Vlastimil Babka (SUSE) @ 2026-03-24 10:55 UTC (permalink / raw)
  To: Lorenzo Stoakes (Oracle), Andrew Morton
  Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
	Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
	Alexandre Torgue, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
	David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
	Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
	linux-kernel, linux-doc, linux-hyperv, linux-stm32,
	linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
	target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <d44248be9da68258b07c2c59d4e73485ee0ca943.1774045440.git.ljs@kernel.org>

On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Commit ac0a3fc9c07d ("mm: add ability to take further action in
> vm_area_desc") added the ability for drivers to instruct mm to take actions
> after the .mmap_prepare callback is complete.
> 
> To make life simpler and safer, this is done before the VMA/mmap write lock
> is dropped but when the VMA is completely established.
> 
> So on error, we simply munmap() the VMA.
> 
> As part of this implementation, unfortunately a horrible hack had to be
> implemented to support some questionable behaviour hugetlb relies upon -
> that is that the file rmap lock is held until the operation is complete.
> 
> The implementation, for convenience, did this in mmap_action_finish() so
> both the VMA and mmap_prepare compatibility layer paths would have this
> correctly handled.
> 
> However, it turns out there is a mistake here - the rmap lock cannot be
> held on munmap, as free_pgtables() -> unlink_file_vma_batch_add() ->
> unlink_file_vma_batch_process() takes the file rmap lock.
> 
> We therefore currently have a deadlock issue that might arise.
> 
> Resolve this by leaving it to callers to handle the unmap.
> 
> The compatibility layer does not support this rmap behaviour, so we simply
> have it unmap on error after calling mmap_action_complete().
> 
> In the VMA implementation, we only perform the unmap after the rmap lock is
> dropped.
> 
> This resolves the issue by ensuring the rmap lock is always dropped when
> the unmap occurs.
> 
> Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>


^ permalink raw reply

* Re: [PATCH v4 01/21] mm: various small mmap_prepare cleanups
From: Vlastimil Babka (SUSE) @ 2026-03-24 10:46 UTC (permalink / raw)
  To: Lorenzo Stoakes (Oracle), Andrew Morton
  Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
	Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
	Alexandre Torgue, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
	David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
	Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
	Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
	linux-kernel, linux-doc, linux-hyperv, linux-stm32,
	linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
	target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <99f408e4694f44ab12bdc55fe0bd9685d3bd1117.1774045440.git.ljs@kernel.org>

On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Rather than passing arbitrary fields, pass a vm_area_desc pointer to mmap
> prepare functions to mmap prepare, and an action and vma pointer to mmap
> complete in order to put all the action-specific logic in the function
> actually doing the work.
> 
> Additionally, allow mmap prepare functions to return an error so we can
> error out as soon as possible if there is something logically incorrect in
> the input.
> 
> Update remap_pfn_range_prepare() to properly check the input range for the
> CoW case.
> 
> Also remove io_remap_pfn_range_complete(), as we can simply set up the
> fields correctly in io_remap_pfn_range_prepare() and use
> remap_pfn_range_complete() for this.
> 
> While we're here, make remap_pfn_range_prepare_vma() a little neater, and
> pass mmap_action directly to call_action_complete().
> 
> Then, update compat_vma_mmap() to perform its logic directly, as
> __compat_vma_map() is not used by anything so we don't need to export it.
> 
> Also update compat_vma_mmap() to use vfs_mmap_prepare() rather than
> calling the mmap_prepare op directly.
> 
> Finally, update the VMA userland tests to reflect the changes.
> 
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>



^ permalink raw reply

* Re: [PATCH 12/12] driver core: remove driver_set_override()
From: Greg Kroah-Hartman @ 2026-03-24  8:09 UTC (permalink / raw)
  To: Danilo Krummrich
  Cc: Russell King, Rafael J. Wysocki, Ioana Ciornei, Nipun Gupta,
	Nikhil Agarwal, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
	Dexuan Cui, Long Li, Bjorn Helgaas, Armin Wolf, Bjorn Andersson,
	Mathieu Poirier, Vineeth Vijayan, Peter Oberparleiter,
	Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
	Christian Borntraeger, Sven Schnelle, Harald Freudenberger,
	Holger Dengler, Mark Brown, Michael S. Tsirkin, Jason Wang,
	Xuan Zhuo, Eugenio Pérez, Alex Williamson, Juergen Gross,
	Stefano Stabellini, Oleksandr Tyshchenko,
	Christophe Leroy (CS GROUP), linux-kernel, driver-core,
	linuxppc-dev, linux-hyperv, linux-pci, platform-driver-x86,
	linux-arm-msm, linux-remoteproc, linux-s390, linux-spi,
	virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <20260324005919.2408620-13-dakr@kernel.org>

On Tue, Mar 24, 2026 at 01:59:16AM +0100, Danilo Krummrich wrote:
> All buses have been converted from driver_set_override() to the generic
> driver_override infrastructure introduced in commit cb3d1049f4ea
> ("driver core: generalize driver_override in struct device").
> 
> Buses now either opt into the generic sysfs callbacks via the
> bus_type::driver_override flag, or use device_set_driver_override() /
> __device_set_driver_override() directly.
> 
> Thus, remove the now-unused driver_set_override() helper.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220789
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---
>  drivers/base/driver.c         | 75 -----------------------------------
>  include/linux/device/driver.h |  2 -
>  2 files changed, 77 deletions(-)

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply

* [PATCH 12/12] driver core: remove driver_set_override()
From: Danilo Krummrich @ 2026-03-24  0:59 UTC (permalink / raw)
  To: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
	Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
	Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
	Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
	Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Harald Freudenberger, Holger Dengler, Mark Brown,
	Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
	Alex Williamson, Juergen Gross, Stefano Stabellini,
	Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
  Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
	platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
	linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
	Danilo Krummrich
In-Reply-To: <20260324005919.2408620-1-dakr@kernel.org>

All buses have been converted from driver_set_override() to the generic
driver_override infrastructure introduced in commit cb3d1049f4ea
("driver core: generalize driver_override in struct device").

Buses now either opt into the generic sysfs callbacks via the
bus_type::driver_override flag, or use device_set_driver_override() /
__device_set_driver_override() directly.

Thus, remove the now-unused driver_set_override() helper.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
---
 drivers/base/driver.c         | 75 -----------------------------------
 include/linux/device/driver.h |  2 -
 2 files changed, 77 deletions(-)

diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 8ab010ddf709..7ed834f7199c 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -30,81 +30,6 @@ static struct device *next_device(struct klist_iter *i)
 	return dev;
 }
 
-/**
- * driver_set_override() - Helper to set or clear driver override.
- * @dev: Device to change
- * @override: Address of string to change (e.g. &device->driver_override);
- *            The contents will be freed and hold newly allocated override.
- * @s: NUL-terminated string, new driver name to force a match, pass empty
- *     string to clear it ("" or "\n", where the latter is only for sysfs
- *     interface).
- * @len: length of @s
- *
- * Helper to set or clear driver override in a device, intended for the cases
- * when the driver_override field is allocated by driver/bus code.
- *
- * Returns: 0 on success or a negative error code on failure.
- */
-int driver_set_override(struct device *dev, const char **override,
-			const char *s, size_t len)
-{
-	const char *new, *old;
-	char *cp;
-
-	if (!override || !s)
-		return -EINVAL;
-
-	/*
-	 * The stored value will be used in sysfs show callback (sysfs_emit()),
-	 * which has a length limit of PAGE_SIZE and adds a trailing newline.
-	 * Thus we can store one character less to avoid truncation during sysfs
-	 * show.
-	 */
-	if (len >= (PAGE_SIZE - 1))
-		return -EINVAL;
-
-	/*
-	 * Compute the real length of the string in case userspace sends us a
-	 * bunch of \0 characters like python likes to do.
-	 */
-	len = strlen(s);
-
-	if (!len) {
-		/* Empty string passed - clear override */
-		device_lock(dev);
-		old = *override;
-		*override = NULL;
-		device_unlock(dev);
-		kfree(old);
-
-		return 0;
-	}
-
-	cp = strnchr(s, len, '\n');
-	if (cp)
-		len = cp - s;
-
-	new = kstrndup(s, len, GFP_KERNEL);
-	if (!new)
-		return -ENOMEM;
-
-	device_lock(dev);
-	old = *override;
-	if (cp != s) {
-		*override = new;
-	} else {
-		/* "\n" passed - clear override */
-		kfree(new);
-		*override = NULL;
-	}
-	device_unlock(dev);
-
-	kfree(old);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(driver_set_override);
-
 /**
  * driver_for_each_device - Iterator for devices bound to a driver.
  * @drv: Driver we're iterating.
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index bbc67ec513ed..aa3465a369f0 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -160,8 +160,6 @@ int __must_check driver_create_file(const struct device_driver *driver,
 void driver_remove_file(const struct device_driver *driver,
 			const struct driver_attribute *attr);
 
-int driver_set_override(struct device *dev, const char **override,
-			const char *s, size_t len);
 int __must_check driver_for_each_device(struct device_driver *drv, struct device *start,
 					void *data, device_iter_t fn);
 struct device *driver_find_device(const struct device_driver *drv,
-- 
2.53.0


^ permalink raw reply related

* [PATCH 11/12] spi: use generic driver_override infrastructure
From: Danilo Krummrich @ 2026-03-24  0:59 UTC (permalink / raw)
  To: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
	Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
	Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
	Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
	Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Harald Freudenberger, Holger Dengler, Mark Brown,
	Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
	Alex Williamson, Juergen Gross, Stefano Stabellini,
	Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
  Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
	platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
	linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
	Danilo Krummrich, Gui-Dong Han
In-Reply-To: <20260324005919.2408620-1-dakr@kernel.org>

When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock
held is intentional. [1]

Also note that we do not enable the driver_override feature of struct
bus_type, as SPI - in contrast to most other buses - passes "" to
sysfs_emit() when the driver_override pointer is NULL. Thus, printing
"\n" instead of "(null)\n".

Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Fixes: 5039563e7c25 ("spi: Add driver_override SPI device attribute")
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
---
 drivers/spi/spi.c       | 19 +++++++------------
 include/linux/spi/spi.h |  5 -----
 2 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 53dee314d76a..4101c2803eb3 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -50,7 +50,6 @@ static void spidev_release(struct device *dev)
 	struct spi_device	*spi = to_spi_device(dev);
 
 	spi_controller_put(spi->controller);
-	kfree(spi->driver_override);
 	free_percpu(spi->pcpu_statistics);
 	kfree(spi);
 }
@@ -73,10 +72,9 @@ static ssize_t driver_override_store(struct device *dev,
 				     struct device_attribute *a,
 				     const char *buf, size_t count)
 {
-	struct spi_device *spi = to_spi_device(dev);
 	int ret;
 
-	ret = driver_set_override(dev, &spi->driver_override, buf, count);
+	ret = __device_set_driver_override(dev, buf, count);
 	if (ret)
 		return ret;
 
@@ -86,13 +84,8 @@ static ssize_t driver_override_store(struct device *dev,
 static ssize_t driver_override_show(struct device *dev,
 				    struct device_attribute *a, char *buf)
 {
-	const struct spi_device *spi = to_spi_device(dev);
-	ssize_t len;
-
-	device_lock(dev);
-	len = sysfs_emit(buf, "%s\n", spi->driver_override ? : "");
-	device_unlock(dev);
-	return len;
+	guard(spinlock)(&dev->driver_override.lock);
+	return sysfs_emit(buf, "%s\n", dev->driver_override.name ?: "");
 }
 static DEVICE_ATTR_RW(driver_override);
 
@@ -376,10 +369,12 @@ static int spi_match_device(struct device *dev, const struct device_driver *drv)
 {
 	const struct spi_device	*spi = to_spi_device(dev);
 	const struct spi_driver	*sdrv = to_spi_driver(drv);
+	int ret;
 
 	/* Check override first, and if set, only use the named driver */
-	if (spi->driver_override)
-		return strcmp(spi->driver_override, drv->name) == 0;
+	ret = device_match_driver_override(dev, drv);
+	if (ret >= 0)
+		return ret;
 
 	/* Attempt an OF style match */
 	if (of_driver_match_device(dev, drv))
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index af7cfee7b8f6..0dc671c07d3a 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -159,10 +159,6 @@ extern void spi_transfer_cs_change_delay_exec(struct spi_message *msg,
  * @modalias: Name of the driver to use with this device, or an alias
  *	for that name.  This appears in the sysfs "modalias" attribute
  *	for driver coldplugging, and in uevents used for hotplugging
- * @driver_override: If the name of a driver is written to this attribute, then
- *	the device will bind to the named driver and only the named driver.
- *	Do not set directly, because core frees it; use driver_set_override() to
- *	set or clear it.
  * @pcpu_statistics: statistics for the spi_device
  * @word_delay: delay to be inserted between consecutive
  *	words of a transfer
@@ -224,7 +220,6 @@ struct spi_device {
 	void			*controller_state;
 	void			*controller_data;
 	char			modalias[SPI_NAME_SIZE];
-	const char		*driver_override;
 
 	/* The statistics */
 	struct spi_statistics __percpu	*pcpu_statistics;
-- 
2.53.0


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox