Page MenuHomeFreeBSD

inpcb: retire the inpcb global list
Needs ReviewPublic

Authored by glebius on Thu, Mar 19, 7:20 PM.
Tags
None
Referenced Files
F149560719: D55967.diff
Wed, Mar 25, 6:37 AM
Unknown Object (File)
Tue, Mar 24, 6:10 PM
Unknown Object (File)
Mon, Mar 23, 8:07 AM
Unknown Object (File)
Fri, Mar 20, 4:32 AM
Unknown Object (File)
Fri, Mar 20, 4:23 AM
Subscribers

Details

Reviewers
markj
pouria
Group Reviewers
transport
network
Summary

The iteration over all pcbs is possible without the global list. The
newborn inpcbs are put on a global list of unconnected inpcbs, then after
connect(2) or bind(2) they move to respective hash slot list.

This adds a bit of complexity to inp_next(), but the storage scheme is
actually simplified.

One potential problem before this change was that a couple of pcbs fall
into the same hash slot and are linked A->B there, but they also sit next
to each other in the global list, linked as B->A. This can deadlock of
course. The problem was never observed in the wild, but I was able to
instrument it with lots of effort: just few pcbs in the system, hash size
reduced down to 2 and a lot of repetitive calls into two kinds of
iterators.

However the main motivation is not the above problem, but make a step
towards splitting the big hash lock into per-slot locks.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 71616
Build 68499: arc lint + arc unit

Event Timeline

sys/netinet/in_pcb.h
330
sys/netinet/tcp_usrreq.c
3013

If we break here, we'll proceed to the next loop and print one inpcb before breaking again.

sys/netinet/in_pcb.h
326
327

"CK-nature" is not very clear. I'd write something like, "we can't share the linkage pointers because unlocked readers might be iterating over them."