Page MenuHomeFreeBSD

inpcb: merge two versions of in6_pcbconnect() into one
ClosedPublic

Authored by glebius on Feb 2 2023, 8:14 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Aug 7, 12:28 AM
Unknown Object (File)
Mon, Jul 22, 3:35 PM
Unknown Object (File)
Sun, Jul 21, 3:11 AM
Unknown Object (File)
Jul 17 2024, 4:08 PM
Unknown Object (File)
Jul 16 2024, 12:24 PM
Unknown Object (File)
Jul 16 2024, 7:25 AM
Unknown Object (File)
Jul 15 2024, 4:31 AM
Unknown Object (File)
Jul 9 2024, 5:10 PM
Subscribers

Details

Summary

No functional change.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/netinet6/in6_pcb.c
491

We have the INP_INHASHLIST flag. That flag will be set if and only if rehash is true, so do we really need rehash at all?

sys/netinet6/in6_pcb.c
491

Right now protocols (TCP & UDP) know if the inpcb is in the hash or not and tell the inpcb layer either "please add to hash" or please "move inside the hash". This makes INP_INHASHLIST a debug flag and at least for some time I want to keep it like that. Maybe later when all this code get easier to read & maintain we can shortcut these checks.

markj added inline comments.
sys/netinet6/in6_pcb.c
491

I'd argue that checking INP_INHASHLIST would make the code easier to read and maintain. :)
In particular, it's hard to remember what all of these boolean flags do when staring at a call like in_pcbconnect(..., true);.

I agree that it makes hard to remember. I started a patch to remove the parameter, but then backed up. I think it is important to not allow protocols to move inpcb in a hash unintentionally. At least at this stage of code cleanup.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 3 2023, 7:34 PM
This revision was automatically updated to reflect the committed changes.