Re: [PATCH net] net: 8139cp: close race between NAPI completion and Rx unmask

[Daniel Palmer]

Hi Colton,

On Thu, 22 Oct 2026 at 08:12, Colton Pawielski via B4 Relay
<devnull+colton.pawielski.gmail.com@xxxxxxxxxx> wrote:
>
> From: Colton Pawielski <colton.pawielski@xxxxxxxxx>
>
> cp_rx_poll() calls napi_complete_done() and only then takes cp->lock
> with interrupts disabled to unmask the Rx interrupts.  An interrupt
> that is not masked while polling (TxOK, TxErr, ...) can arrive in
> between.  cp_interrupt() then sees the Rx status bits, which are still
> set, finds NAPI no longer scheduled, masks Rx and schedules NAPI again.
> cp_rx_poll() then carries on and unmasks Rx anyway.
>
> From that point Rx interrupts are enabled while NAPI is scheduled:
> cp_interrupt() leaves the Rx bits for the poll routine, does not mask
> them because napi_schedule_prep() fails, and the level-triggered
> interrupt fires again as soon as it returns.  On an SH7751 LANDISK
> under combined Tx/Rx load this interrupt storm was captured with a RAM
> trace right before the board locked up hard.
>
> Do the completion and the unmask under the lock, as 8139too does.
>
> Fixes: ab1e7e1d2666 ("8139cp: use napi_complete_done()")
> Signed-off-by: Colton Pawielski <colton.pawielski@xxxxxxxxx>

I tried this out on my landisks and it seems to be fine.
So for as far as "I put this on my hardware and it didn't break my
ethernet or make it explode":

Tested-by: Daniel Palmer <daniel@xxxxxxxxx>

I don't know enough about the APIs involved to review this properly
but for FWIW I had my clanker try to reproduce this in QEMU with an
emulation of the landisk and it said it could get into the state
described in the patch so it seems valid.

Cheers,

Daniel