Page MenuHomeFreeBSD

inpcb: retire the inpcb global list
Needs ReviewPublic

Authored by glebius on Thu, Mar 19, 7:20 PM.
Tags
None
Referenced Files
F151070749: D55967.diff
Sun, Apr 5, 7:06 PM
Unknown Object (File)
Sat, Apr 4, 11:43 PM
Unknown Object (File)
Fri, Mar 27, 12:40 PM
Unknown Object (File)
Fri, Mar 27, 6:21 AM
Unknown Object (File)
Fri, Mar 27, 6:00 AM
Unknown Object (File)
Wed, Mar 25, 6:37 AM
Unknown Object (File)
Tue, Mar 24, 6:10 PM
Unknown Object (File)
Mon, Mar 23, 8:07 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 71552
Build 68435: arc lint + arc unit

Event Timeline

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

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."

sys/netinet/in_pcb.h
324–331
325

Really it's just unconnected pcbs.

326

The comment describes two lists--what is the third list?

glebius added inline comments.
sys/netinet/in_pcb.h
326

What I'm trying to say here is that a pcb is linked by either of inp_hash_exact, inp_hash_wild, inp_unconn_list. All three members are of the same list entry type. Then I try explain why we can't use just one list entry member, or a union.

sys/netinet/in_pcb.h
326

Ok, it's more clear to me now.

365

The cache line annotation is wrong now. Why group these together?