[LTP] [PATCH] Revert "tpci: unbind driver in test_assign_resources()"

[LTP] [PATCH] Revert "tpci: unbind driver in test_assign_resources()"

[Hongtao Zhang via ltp]

While the patch fixes a use-after-free in /proc/iomem by unbinding and
rebinding the driver around PCI resource reassignment, this approach is
too dangerous for a general test. Unbinding a driver from a critical device
(e.g. a network or block controller) can instantly break SSH connectivity or
cause filesystem corruption. Such side effects are unacceptable compared to the original issue.
So need to revert that patch.

Signed-off-by: Hongtao Zhang <zhanghongtao35@huawei.com>
---
 .../device-drivers/pci/tpci_kernel/ltp_tpci.c     | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/testcases/kernel/device-drivers/pci/tpci_kernel/ltp_tpci.c b/testcases/kernel/device-drivers/pci/tpci_kernel/ltp_tpci.c
index 45138d834..660b3a423 100644
--- a/testcases/kernel/device-drivers/pci/tpci_kernel/ltp_tpci.c
+++ b/testcases/kernel/device-drivers/pci/tpci_kernel/ltp_tpci.c
@@ -442,24 +442,9 @@ static int test_assign_resources(void)
 
 		if (r->flags & IORESOURCE_MEM &&
 			r->flags & IORESOURCE_PREFETCH) {
-
-			if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
-				if (dev->dev.driver)
-					device_release_driver(&dev->dev);
-			}
-
 			pci_release_resource(dev, i);
 			ret = pci_assign_resource(dev, i);
 			prk_info("assign resource to '%d', ret '%d'", i, ret);
-
-			if (ret == 0 && dev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
-				int attach_ret;
-
-				attach_ret = device_attach(&dev->dev);
-				if (attach_ret < 0)
-					prk_info("device_attach failed for endpoint, ret: %d", attach_ret);
-			}
-
 			rc |= (ret < 0 && ret != -EBUSY) ? TFAIL : TPASS;
 		}
 	}
-- 
2.43.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] Revert "tpci: unbind driver in test_assign_resources()"

[linuxtestproject.agent]

Hi Hongtao,

On Tue, 14 Jul 2026 17:06:32 +0800, Hongtao Zhang wrote:
> Revert "tpci: unbind driver in test_assign_resources()"

Two small commit-message issues below; the code itself looks fine.

> While the patch fixes a use-after-free in /proc/iomem by unbinding and
> rebinding the driver around PCI resource reassignment, this approach is
> too dangerous for a general test. Unbinding a driver from a critical device
> (e.g. a network or block controller) can instantly break SSH connectivity or
> cause filesystem corruption. Such side effects are unacceptable compared to
> the original issue.
> So need to revert that patch.

"So need to revert that patch." reads informally and is grammatically
incomplete. The motivation was already stated in the preceding sentences;
this closing line can be dropped entirely, or rewritten as "Revert the
patch."

Also, the body is missing the standard traceability line that git revert
adds: "This reverts commit <full-SHA>." Without it, bisect and git-log
searches cannot mechanically link this revert to the commit it undoes.
The subject quotes the original message, but the SHA makes the link
unambiguous. Please add it.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] Revert "tpci: unbind driver in test_assign_resources()"

[Yizhou Tang]

On Tue, Jul 14, 2026 at 6:50 PM <linuxtestproject.agent@gmail.com> wrote:
>
> Hi Hongtao,
>
> On Tue, 14 Jul 2026 17:06:32 +0800, Hongtao Zhang wrote:
> > Revert "tpci: unbind driver in test_assign_resources()"
>
> Two small commit-message issues below; the code itself looks fine.
>
> > While the patch fixes a use-after-free in /proc/iomem by unbinding and
> > rebinding the driver around PCI resource reassignment, this approach is
> > too dangerous for a general test. Unbinding a driver from a critical device
> > (e.g. a network or block controller) can instantly break SSH connectivity or
> > cause filesystem corruption. Such side effects are unacceptable compared to
> > the original issue.
> > So need to revert that patch.
>
> "So need to revert that patch." reads informally and is grammatically
> incomplete. The motivation was already stated in the preceding sentences;
> this closing line can be dropped entirely, or rewritten as "Revert the
> patch."
>
> Also, the body is missing the standard traceability line that git revert
> adds: "This reverts commit <full-SHA>." Without it, bisect and git-log
> searches cannot mechanically link this revert to the commit it undoes.
> The subject quotes the original message, but the SHA makes the link
> unambiguous. Please add it.
>
> Verdict - Needs revision

Hi,

We recently confirmed this commit does cause a flood of I/O errors on
the root filesystem in our testing, leaving the machine unusable until
reboot.

Given that, we'd appreciate the community helping to decide soon
whether the revert is warranted.

Best regards,
Yi

>
>
> ---
> Note:
>
> The agent can sometimes produce false positives although often its
> findings are genuine. If you find issues with the review, please
> comment this email or ignore the suggestions.
>
> Regards,
> LTP AI Reviewer
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] Revert "tpci: unbind driver in test_assign_resources()"

[Andrea Cervesato via ltp]

Hi Yizhou,

> Hi,
> 
> We recently confirmed this commit does cause a flood of I/O errors on
> the root filesystem in our testing, leaving the machine unusable until
> reboot.
> 
> Given that, we'd appreciate the community helping to decide soon
> whether the revert is warranted.

Are you 100% sure that is caused by the patch you want to revert?
Because the patch looked ok to me when I reviewed. We need to have
more context and info around the issue which has been generated in
order to avoid any workaround for a system/kernel bug.

Regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] Revert "tpci: unbind driver in test_assign_resources()"

[Yizhou Tang]

On Wed, Jul 15, 2026 at 11:54 PM Andrea Cervesato
<andrea.cervesato@suse.com> wrote:
>
> Hi Yizhou,
>
> > Hi,
> >
> > We recently confirmed this commit does cause a flood of I/O errors on
> > the root filesystem in our testing, leaving the machine unusable until
> > reboot.
> >
> > Given that, we'd appreciate the community helping to decide soon
> > whether the revert is warranted.
>
> Are you 100% sure that is caused by the patch you want to revert?
> Because the patch looked ok to me when I reviewed. We need to have
> more context and info around the issue which has been generated in
> order to avoid any workaround for a system/kernel bug.
>

Hi Andrea,

I can't claim 100% certainty, as I'm not a PCI expert.

Let me give you the context we have. Environment: Ubuntu 24.04, kernel
built from the latest 6.6 stable branch. Root filesystem / is XFS on
/dev/sda4.
Reproducer: kirk -f kernel_misc -p tpci -v.

With dmesg -T --follow we captured:
[Fri Jul 10 19:22:08 2026] ltp_tpci: assign resource #6
[Fri Jul 10 19:22:08 2026] ltp_tpci: name = 0000:d7:12.2, flags = 0,
start 0x0, end 0x0
[Fri Jul 10 19:22:08 2026] ltp_tpci: test-case 13
[Fri Jul 10 19:22:08 2026] ltp_tpci: save state
[Fri Jul 10 19:22:08 2026] ltp_tpci: saved state of device
[Fri Jul 10 19:22:08 2026] ltp_tpci: test-case 14
[Fri Jul 10 19:22:08 2026] ltp_tpci: restore state
[Fri Jul 10 19:22:08 2026] ltp_tpci: test-case 15
[Fri Jul 10 19:22:08 2026] ltp_tpci: find device capability
[Fri Jul 10 19:22:08 2026] ltp_tpci: device has PM capability
[Fri Jul 10 19:22:08 2026] ltp_tpci: test-case 16
[Fri Jul 10 19:22:08 2026] ltp_tpci: device doesn't have PCI-EXP capability

At this point there is a gap of roughly one minute that no log could
not be captured. During that window the console scrolled a large
volume of messages too fast to record. Among what was visible on the
console was:
XFS (sda4): Please unmount the filesystem and rectify the problem(s).
What did make it into the log afterwards is only the resulting I/O-error flood:

[Fri Jul 10 19:23:06 2026] systemd-journald[818]: Failed to open
/var/log/journal/...: Input/output error (Dropped 2749 similar
message(s))
[Fri Jul 10 19:23:06 2026] systemd-journald[818]: Failed to rotate
/var/log/journal/.../system.journal: Input/output error (Dropped 4815
similar message(s))
[Fri Jul 10 19:23:06 2026] systemd-journald[818]: Failed to rotate
/var/log/journal/.../user-1000.journal: Input/output error
[Fri Jul 10 19:23:06 2026] systemd-journald[818]: Failed to open
/var/log/journal/...: Input/output error (Dropped 2406 similar
message(s))
[Fri Jul 10 19:23:06 2026] systemd-journald[818]: Failed to open
/var/log/journal/...: Input/output error

The machine is unusable after this and only recovers on reboot.

The one thing I can state with confidence: after reverting this patch,
the problem no longer reproduces on the same setup.

Best regards,
Yi

>
> Regards,
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp