Re: [PATCH 01/13] 8139cp: fix DMA mapping unwind on TX frag map failure

在 2026/7/23 03:43, Jakub Kicinski 写道:

On Wed, 22 Jul 2026 15:37:02 +0800 luyun wrote:

quoted

A gentle ping for this series, the number of patches is 2, not 13. I made a mistake
when generating the patches. Please ignore it.

Any comments or reviews would be greatly appreciated.

You must describe how your discovered the issue and what HW you have
tested it on. We don't take LLM fixes to Orphaned drivers.

Hi Jakub,

Thank you for taking the time to look at this, and sorry about the
patch numbering mess in my first submission.

On how the issue was found: it came out of a systematic audit of
the driver's error handling paths. I should be transparent that the
initial scan was assisted by AI tooling, but I then verified every
finding myself line by line before writing any patch.

Both bugs are deterministic logic errors provable by inspection.
Patch 1: in cp_start_xmit() the head descriptor is written only
after the fragment loop, but on a fragment mapping failure
unwind_tx_frag_mapping() unmaps the stale address still sitting in
that slot (a double unmap), uses fragment sizes shifted by one
slot, and never unmaps the head buffer mapping at all.
Patch 2: when cp_init_rings() fails, cp_clean_rings() has already
dropped all rx_skb entries, yet the hardware is restarted and NAPI
is scheduled unconditionally, so cp_rx_poll() hits BUG_ON(!skb).

On testing: the series is compile-tested only (full kbuild, -Werror
clean). I don't have RTL8139C+/RTL810x hardware, and QEMU's rtl8139
model is driven by 8139too, so I have no way to runtime-test this
driver. I want to be upfront about that.

I understand and respect the policy on orphaned drivers. I take
full responsibility for these changes, but I'd rather ask than assume:
are statically provable fixes like these acceptable for an orphaned
driver without hardware testing, or should I look for someone with
the hardware to confirm them first?

Thanks,
Yun