[Bug 267159] SO_REUSEPORT_LB race conditions
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 17 Oct 2022 19:40:05 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267159 Bug ID: 267159 Summary: SO_REUSEPORT_LB race conditions Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: markj@FreeBSD.org net_epoch permits in_pcblookup_lbgroup() and in_pcbremlbgrouphash() to run concurrently, but they weren't written with this in mind. The latter may remove entries in an LB group, after which it compacts the group. If a new group structure is allocated, in_pcbremlbgrouphash() puts it at the head of the hash chain before copying the contents of the old group over, so there's a small window where we have a group of size 0, which can cause problems in the lookup path (kernel panics or inexplicable connection setup failures). I think there's a similar problem when growing a group structure. Finally, the group structures are not really protected by SMR, only by net_epoch. We should probably never shrink the group structure, I don't think it's worth the complexity. When growing the structure, we should populate the new one and issue a memory barrier before making it visible to other CPUs (i.e., before adding it to the hash chain). -- You are receiving this mail because: You are the assignee for the bug.