Page MenuHomeFreeBSD

inpcb: apply smr_advance(9)/smr_wait(9) trick only to reusable sockets
AcceptedPublic

Authored by glebius on Wed, Mar 4, 9:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 20, 7:42 AM
Unknown Object (File)
Thu, Mar 19, 8:48 AM
Unknown Object (File)
Tue, Mar 17, 12:17 PM
Unknown Object (File)
Fri, Mar 13, 5:11 PM
Unknown Object (File)
Wed, Mar 11, 8:31 AM
Unknown Object (File)
Wed, Mar 11, 4:38 AM
Unknown Object (File)
Mon, Mar 9, 2:31 PM
Unknown Object (File)
Sun, Mar 8, 9:17 AM
Subscribers

Details

Reviewers
markj
pouria
Group Reviewers
network
Summary

The protocols marked with PR_CONNREQUIRED can never go through pr_connect
after being disconnected. This is a tiny improvement of fdb987bebddf0.

Diff Detail

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

Event Timeline

This removes the smr_advance() calls, but also the clearing of the addr/port. Is it intentional?

I don't see a point in clearing the addresses either. Speculatively (didn't check!) it should even fix getsockname(2) on a disconnected TCP connection.

I don't see a point in clearing the addresses either. Speculatively (didn't check!) it should even fix getsockname(2) on a disconnected TCP connection.

I don't see much point either, but the code has done this since at least 1994. But ok, I think this change is functionally a no-op anyway, since only the UDP code uses these functions...?

sys/netinet6/in6_pcb.c
515–516

This comment applies to the smr_advance() call, so should be moved to make that more clear. Same thing above.

Adjust comment placement per Mark's suggestion.

I'll write a manual for in_pcb someday...

sys/netinet/in_pcb.c
1430–1436

style

sys/netinet6/in6_pcb.c
516–523
This revision is now accepted and ready to land.Thu, Mar 19, 9:57 PM
markj added inline comments.
sys/netinet/in_pcb.c
1430–1436

+1

This revision now requires review to proceed.Fri, Mar 20, 8:27 PM

I don't see a point in clearing the addresses either. Speculatively (didn't check!) it should even fix getsockname(2) on a disconnected TCP connection.

I don't see much point either, but the code has done this since at least 1994. But ok, I think this change is functionally a no-op anyway, since only the UDP code uses these functions...?

The commit log message should mention this aspect of the change.

This revision is now accepted and ready to land.Sat, Mar 21, 2:07 AM