8b3d2c19 | 23-Feb-2025 |
Mark Johnston <markj@FreeBSD.org> |
inpcb: Fix reuseport lbgroup array resizing
in_pcblisten() moves an inpcb from the per-group list into the array, at which point it becomes visible to inpcb lookups in the datapath. It assumes that
inpcb: Fix reuseport lbgroup array resizing
in_pcblisten() moves an inpcb from the per-group list into the array, at which point it becomes visible to inpcb lookups in the datapath. It assumes that there is space in the array for this, but that's not guaranteed, since in_pcbinslbgrouphash() doesn't reserve space in the array if the inpcb isn't associated with a listening socket.
We could resize the array in in_pcblisten(), but that would introduce a failure case where there currently is none. Instead, keep track of the number of pending inpcbs as well, and modify in_pcbinslbgrouphash() to reserve space for each pending (i.e., not-yet-listening) inpcb.
Add a regression test.
Reviewed by: glebius Reported by: netchild Fixes: 7cbb6b6e28db ("inpcb: Close some SO_REUSEPORT_LB races, part 2") Differential Revision: https://reviews.freebsd.org/D49100
show more ...
|
93fbdef5 | 22-Feb-2025 |
Zhenlei Huang <zlei@FreeBSD.org> |
tests: carp: Update test case unicast_v4 to catch PR 284872
In the current test case unicast_v4, host one acts as a router, but it uses if_bridge(4) to verify the reachability to CARP master. Unfort
tests: carp: Update test case unicast_v4 to catch PR 284872
In the current test case unicast_v4, host one acts as a router, but it uses if_bridge(4) to verify the reachability to CARP master. Unfortunately, if_bridge(4) brings the two CARP hosts into the same broadcast domain, thus with an unusual (undocumented) setup, one host is in unicast mode but another one in multicast, or two hosts are both in multicast mode, the test case can falsely report success.
Fix that by propagating route via routed(8).
PR 284872 shows that CARP(4) happens to send packets with multicast destination when the unicast peer address is in the range x.x.x.224 ~ x.x.x.239. Update the peer address in test case to catch that bug.
PR: 284872 Reviewed by: kp MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D49076
show more ...
|
65cc5af1 | 12-Feb-2025 |
Jose Luis Duran <jlduran@FreeBSD.org> |
sys tests: Add scapy as a required program
These atf-python tests rely on scapy to run. Add it as a required program.
Reported by: glebius, kp Reviewed by: kp Approved by: emaste (mentor) MFC after
sys tests: Add scapy as a required program
These atf-python tests rely on scapy to run. Add it as a required program.
Reported by: glebius, kp Reviewed by: kp Approved by: emaste (mentor) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D48946
show more ...
|
7cbb6b6e | 23-Jan-2025 |
Mark Johnston <markj@FreeBSD.org> |
inpcb: Close some SO_REUSEPORT_LB races, part 2
Suppose a thread is adds a socket to an existing TCP lbgroup that is actively accepting connections. It has to do the following operations: 1. set SO
inpcb: Close some SO_REUSEPORT_LB races, part 2
Suppose a thread is adds a socket to an existing TCP lbgroup that is actively accepting connections. It has to do the following operations: 1. set SO_REUSEPORT_LB on the socket 2. bind() the socket to the shared address/port 3. call listen()
Step 2 makes the inpcb visible to incoming connection requests. However, at this point the inpcb cannot accept new connections. If in_pcblookup() matches it, the remote end will see ECONNREFUSED even when other listening sockets are present in the lbgroup. This means that dynamically adding inpcbs to an lbgroup (e.g., by starting up new workers) can trigger spurious connection failures for no good reason. (A similar problem exists when removing inpcbs from an lbgroup, but that is harder to fix and is not addressed by this patch; see the review for a bit more commentary.)
Fix this by augmenting each lbgroup with a linked list of inpcbs that are pending a listen() call. When adding an inpcb to an lbgroup, keep the inpcb on this list if listen() hasn't been called, so it is not yet visible to the lookup path. Then, add a new in_pcblisten() routine which makes the inpcb visible within the lbgroup now that it's safe to let it handle new connections.
Add a regression test which verifies that we don't get spurious connection errors while adding sockets to an LB group.
Reviewed by: glebius MFC after: 1 month Sponsored by: Klara, Inc. Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D48544
show more ...
|