Re:Re: [PATCH] watchdog: wdt_pci: Fix shared IRQ storm and complete system lockup

[w15303746062 <w15303746062@163.com>]

From: Mingyu Wang <25181214217@stu.xidian.edu.cn>

Hi Guenter,

Point taken. You are absolutely right that relying on an unverified macro to synthesize hardware behavior is flawed. I apologize for not making the virtualized and synthesized nature of this test setup clear in the initial patch description. 

Since the true physical hardware behavior cannot be verified, and the driver does not actively evaluate that bit, we agree that applying a patch based on this assumption is inappropriate. 

I will drop this patch. Thank you for the rigorous review and for pointing out this limitation in our testing methodology.

Best regards,
Mingyu










At 2026-05-11 12:39:26, "Guenter Roeck" <linux@roeck-us.net> wrote:
>Hi,
>
>On 5/10/26 20:08, w15303746062 wrote:
>> 
>> 
>> From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>> 
>> Hi Guenter,
>> 
>> You are correct; standard QEMU does not support the WDT500/501.
>> 
>> We observed this issue using DevGen, an automated framework we are developing. It synthesizes QEMU virtual device models directly from Linux driver source code using LLM guidance, allowing us to fuzz legacy or obscure drivers that lack physical hardware or official emulators.
>> 
>> Because the synthesized device is an imperfect model, it generated unexpected interrupt loads on a heavily shared PCI IRQ line (shared with the i2c-i801 controller in our setup). However, this successfully exposed a real logic flaw: the `wdt_pci` driver registers an `IRQF_SHARED` handler but fails to verify the `WDC_SR_IRQ` bit. It erroneously claimed the interrupts, bypassed the kernel's spurious IRQ defenses, and caused a livelock.
>> 
>> I understand this hardware is essentially obsolete. The patch provides a purely defensive fix for a legitimate API violation (unverified shared IRQ).
>> 
>> If applying this adds unnecessary churn, please feel free to drop it, or perhaps consider marking the driver as BROKEN. I leave it entirely to your judgment.
>> 
>
>That is entirely not the problem. The problem is that your AI implemented
>a QEMU emulation without really knowing what the hardware is doing while
>guessing what status bits unused by the driver mean for the real hardware.
>We (and the AI) actually don't know what the WDC_SR_IRQ does, or if it
>is indeed low active. That is just a guess. I can not accept a patch
>based on a guess, much less one making unconfirmed claims.
>
>If the driver is indeed unused or obsolete is a completely different
>question. Marking it as BROKEN without real evidence that it is indeed
>broken, just because some AI believes that it is broken, would be
>inappropriate.
>
>Please note that I also find the patch description inappropriate and
>misleading. It suggests that the problem was observed on real hardware,
>while it was actually observed with a qemu implementation implemented by AI
>based on the driver itself, including guesswork about status bits unused
>by the driver.
>
>Guenter