[lwip-devel] [bug #66230] LWIP assert "pbuf_free: p->ref > 0" and "tcpip_thread: Invalid message" reported in lwip 2.2.0

[David Cermak]

Follow-up Comment #1, bug #66230 (group lwip):

I’ve encountered a problem that might be related to this bug report, and
this one: https://savannah.nongnu.org/bugs/?66173 and also my own issue:
https://github.com/david-cermak/lwip-1/actions/runs/11362660453/job/31604981274#step:4:28856.

The issue is that the last read `pbuf` in a socket is not protected, even when
`LWIP_NETCONN_FULLDUPLEX=1` is enabled. See the relevant code here:
https://github.com/lwip-tcpip/lwip/blob/master/src/api/sockets.c#L981.

A simple way to reproduce this is to have two threads read a few bytes
simultaneously from the same socket, after the socket has already received a
large amount of data (so the data is cached in the lastdata pbuf).
Here’s an example:
https://github.com/lwip-tcpip/lwip/blob/f1587db60cc62d47584de5e9355d434e7e896fbc/test/apps/test_apps.c.

I’m unsure how to resolve this and would appreciate input from lwIP
experts.

One simple fix would be adding an extra lock for each socket:
https://github.com/lwip-tcpip/lwip/commit/c4532c43f55f279208e4e086c26bef3c26f7e74e.

Alternatively, we could "peek" into the mbox without locking the pbuf, locking
only when we actually read:
https://github.com/lwip-tcpip/lwip/commit/611f5e3b3e013b93fc533ceb7cde61a3caa79e9b.
However, this would introduce more complexity, require recursive locking in
the protect macro, and would likely hurt performance.

Does anyone have suggestions on how best to tackle this?


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?66230>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/

signature.asc
Description: PGP signature