Hi netdev maintainers,

This is a pair of bugfixes for the stmmac driver's receive pipeline. These
issues occur when stmmac_rx_refill() does not (fully) succeed, which happens
more frequently when free memory is low.

The first patch closes Bugzilla bug #221010, where stmmac_rx() can circle
around to a still-dirty descriptor (with a NULL buffer pointer), mistake it for
a filled descriptor (due to OWN=0), and attempt to dereference the buffer.

In testing that patch, I discovered a second issue: starvation of available RX
buffers causes the NIC to stop sending interrupts; if the driver stops polling,
it will wait indefinitely for an interrupt that will never come. (Note: the
first patch makes this issue more prominent -- mostly because it lets the
system survive long enough to exhibit it -- but doesn't *cause* it.) The second
patch addresses that problem as well.

The first two patches are minimal and intended for stable. The third is a
general cleanup that removes the `limit` clamp and *solves* the issue of the
loop mistaking dirty entries for filled ones, rather than *avoiding* it.
Because this final patch changes the range of stmmac_rx_dirty()'s possible
return values, it's intended for -next, not stable.

I look forward to your feedback,
Sam

Sam Edwards (3):
  net: stmmac: Fix NULL deref when RX encounters a dirty descriptor
  net: stmmac: Prevent indefinite RX stall on buffer exhaustion
  net: stmmac: Remove stmmac_rx()'s `limit`, check desc validity instead

 .../net/ethernet/stmicro/stmmac/stmmac_main.c    | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

-- 
2.52.0

On Sun, 15 Mar 2026 19:10:06 -0700 Sam Edwards wrote:
> This is a pair of bugfixes for the stmmac driver's receive pipeline. These
> issues occur when stmmac_rx_refill() does not (fully) succeed, which happens
> more frequently when free memory is low.
> 
> The first patch closes Bugzilla bug #221010, where stmmac_rx() can circle
> around to a still-dirty descriptor (with a NULL buffer pointer), mistake it for
> a filled descriptor (due to OWN=0), and attempt to dereference the buffer.
> 
> In testing that patch, I discovered a second issue: starvation of available RX
> buffers causes the NIC to stop sending interrupts; if the driver stops polling,
> it will wait indefinitely for an interrupt that will never come. (Note: the
> first patch makes this issue more prominent -- mostly because it lets the
> system survive long enough to exhibit it -- but doesn't *cause* it.) The second
> patch addresses that problem as well.
> 
> The first two patches are minimal and intended for stable. The third is a
> general cleanup that removes the `limit` clamp and *solves* the issue of the
> loop mistaking dirty entries for filled ones, rather than *avoiding* it.
> Because this final patch changes the range of stmmac_rx_dirty()'s possible
> return values, it's intended for -next, not stable.

Please (ask your LLM to) read
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html

You can't submit fixes and next changes in one go.

Please have a critical look at the commit messages.
They are very bloviated and not slop looking.
-- 
pw-bot: cr

On Tue, Mar 17, 2026 at 8:27 PM Jakub Kicinski <kuba@kernel.org> wrote:
> ...

Hi Jakub,

> Please (ask your LLM to) read
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html

Thanks, I wasn't aware that this subsystem-specific documentation
existed. The reverse-xmas-tree rule also means I need to move the `int
budget` variable lower in the declarations.

> You can't submit fixes and next changes in one go.

ACK, I'll drop patch 3 for now and designate a v2 for `net`.

> Please have a critical look at the commit messages.
> They are very bloviated and not slop looking.

Thank you for saying my messages aren't slop. :) I'll try to dial back
the verbosity, though. What kind of bloviation do I have? Should I be
leaving off more context, or should I focus more on preserving the
same detail but using fewer words?

Cheers,
Sam

On Tue, 17 Mar 2026 20:46:00 -0700 Sam Edwards wrote:
> > Please have a critical look at the commit messages.
> > They are very bloviated and not slop looking.  
> 
> Thank you for saying my messages aren't slop. :)

Typo, of course. Are you saying you haven't use an LLM at all to write
these patches or commit messages?

> I'll try to dial back the verbosity, though. What kind of bloviation
> do I have? Should I be leaving off more context, or should I focus
> more on preserving the same detail but using fewer words?

IDK, writing is hard. I read the commit message for patch 1 and I felt
like I understood less than when I started :S Try to imagine you don't
know the code very well and think what information is crucial to
understanding the change.

On Wed, Mar 18, 2026 at 3:11 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 17 Mar 2026 20:46:00 -0700 Sam Edwards wrote:
> > > Please have a critical look at the commit messages.
> > > They are very bloviated and not slop looking.
> >
> > Thank you for saying my messages aren't slop. :)
>
> Typo, of course. Are you saying you haven't use an LLM at all to write
> these patches or commit messages?

That's right: My crash analysis, source code study, bug reporting, fix
implementation, testing, commit messages, and correspondence were done
the pre-LLM way. (Perhaps it's time for me to adopt a disclaimer a la
xkcd.com/3126? /s)

> > I'll try to dial back the verbosity, though. What kind of bloviation
> > do I have? Should I be leaving off more context, or should I focus
> > more on preserving the same detail but using fewer words?
>
> IDK, writing is hard. I read the commit message for patch 1 and I felt
> like I understood less than when I started :S

Ah yeah, I get it: Sometimes with negative feedback, people don't know
*why* something is off, only *that* it's off.

(Aside: I originally wrote the patch 1 message last month as a comment
explaining my issue on Bugzilla, and later reused most of it when
preparing this series. Patches 2/3 were written fresh as I was getting
ready to hit send. Maybe I was relying on context from the Bugzilla
thread more than I thought.)

> Try to imagine you don't
> know the code very well and think what information is crucial to
> understanding the change.

I have a bit of an edge then: I'm actually pretty new to this driver,
and used the commit messages to document what I had to learn in the
process.

I'll try to workshop the commit messages in preparation for a series
v2. Thank you for taking the time to speak with me about this.

Best wishes,
Sam