Sam Price created a merge request:
https://gitlab.rtems.org/rtems/pkg/rtems-lwip/-/merge_requests/56
Project:Branches: TheSamPrice/rtems-lwip:io-accept-and-semaphore to
rtems/pkg/rtems-lwip:main
Author: Sam Price
## Summary
rtems_lwip_io: Do not build a descriptor from a failed accept
accept() passes lwip_accept()'s return straight to
rtems_lwip_make_sysfd_from_lwipfd() without checking it. When lwip_accept()
fails it returns -1, and a perfectly valid RTEMS descriptor is then built with
data0 = -1.
That descriptor is worse than an error. rtems_lwip_iop_to_lwipfd() finds the
handlers match, so it returns data0 verbatim -- -1 -- and every call made on
the descriptor returns -1 having set no errno at all, because none of the
paths that do set errno was taken.
On a non-blocking listener, which is what any event-driven server uses, an
accept with nothing pending is the ordinary case rather than an error. So a
server polling an idle listener is handed a fresh descriptor on every poll,
believes it has a connection each time, and leaks a descriptor each time.
Observed on arm/xilinx_zynq_a9_qemu with ESPHome's API server: successive
accepts returning fds 4, 5, 6 with no client connected, each failing at
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY) -> -1, errno unchanged
A blocking listener never sees it, which is why the ordinary tests do not.
While in the same file: socket() returns on its error path without releasing
the semaphore it took. The mutex is recursive, so the task that took it is
unaffected and the next task to want it is not -- the deadlock lands somewhere
else entirely, which is the hardest kind to attribute.
Signed-off-by: Samuel Price <[email protected]>
Assisted-by: Claude Opus 5 (1M context) <[email protected]>
## Generative AI
Assisted-by: Claude Opus 5 (1M context) <[email protected]>
<!-- Default settings, if it is a dropdown it will set after submission -->
--
View it on GitLab:
https://gitlab.rtems.org/rtems/pkg/rtems-lwip/-/merge_requests/56
You're receiving this email because of your account on gitlab.rtems.org.
Unsubscribe from this thread:
https://gitlab.rtems.org/-/namespace/22/sent_notifications/5-etuw4t3fym88xz42z96lb4pim-m/unsubscribe
| Manage all notifications: https://gitlab.rtems.org/-/profile/notifications |
Help: https://gitlab.rtems.org/help
_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
