Page MenuHomeFreeBSD

sockets: don't malloc/free sockaddr memory on accept(2)
ClosedPublic

Authored by glebius on Nov 16 2023, 4:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sep 23 2024, 3:16 PM
Unknown Object (File)
Sep 16 2024, 10:42 PM
Unknown Object (File)
Sep 16 2024, 11:40 AM
Unknown Object (File)
Sep 9 2024, 1:27 PM
Unknown Object (File)
Sep 8 2024, 3:26 PM
Unknown Object (File)
Sep 8 2024, 4:57 AM
Unknown Object (File)
Sep 7 2024, 11:01 PM
Unknown Object (File)
Aug 24 2024, 12:41 AM

Details

Summary

Let the accept functions provide stack memory for protocols to fill it in.
Generic code should provide sockaddr_storage, specialized code may provide
smaller structure.

While rewriting accept(2) make 'addrlen' a true in/out parameter, reporting
required length in case if provided length was insufficient. Our manual
page accept(2) and POSIX don't explicitly require that, but one can read
the text as they do. Linux also does that. Update tests accordingly.

Diff Detail

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

Event Timeline

rscheff added a subscriber: rscheff.

the TCP part seems good; and my worry about the data struct allocated may being to small is caught by a KASSERT in soaccept too. That part looks good to me.

Not commenting about the L2 and linux aspects though.

This revision is now accepted and ready to land.Nov 16 2023, 5:10 PM
zlei added inline comments.
sys/cam/ctl/ctl_ha.c
400

I'm not familiar with ctl(4), but it seems ctl.conf(5) says it support IPv6.

So does ctl(4) not yet support IPv6 ?

sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522–2527

This bzero seems to be redundant. All members of struct sockaddr_l2cap are set via the following sequence.

sys/netinet/sctp_usrreq.c
7341–7347

Looks more readable.

7351–7359

Ditto.

dchagin added inline comments.
sys/compat/linux/linux_socket.c
1072–1079

or if (PTRIN(addr) != NULL) {?

sys/netinet/sctp_usrreq.c
7351–7359

And actually fixes a serious bug. Thanks!

glebius added inline comments.
sys/cam/ctl/ctl_ha.c
400

softc->ha_lso is created in ctl_ha_listen() always as PF_INET socket.

glebius marked an inline comment as done.

Address review comments.

This also fixed bug with not copying out entire sockaddr_in6.

This revision now requires review to proceed.Nov 17 2023, 8:21 PM
zlei accepted this revision as: zlei.EditedNov 18 2023, 10:37 AM

Looks good to me.

so the assignment can be shorted

I meant the assignment can be simplified.

sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522

No need for type casting.

From the compiler perspective, the type of the variable is known.
In this case typeof *sa == struct sockaddr_l2cap so the assignment can be shorted.

This revision is now accepted and ready to land.Nov 18 2023, 10:37 AM
sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522

No need for type casting.

From the compiler perspective, the type of the variable is known.
In this case typeof *sa == struct sockaddr_l2cap so the assignment can be shorted.

I compiled with clang and gcc, both work.

So unless the type casting is intended ( with a good reason ), I would prefer to remove them.

sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522

No need for type casting.

From the compiler perspective, the type of the variable is known.
In this case typeof *sa == struct sockaddr_l2cap so the assignment can be shorted.

I compiled with clang and gcc, both work.

How is that possible? For me it fails immediately on system clang:

/usr/src/FreeBSD/sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c:2522:8: error: expected expression
        *sa = {
              ^

I think the problem is not with compiler being able or not being able to determine type of variable. The problem is with compiler parser, which isn't able to tell a code block from structure value.

sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522

No need for type casting.

From the compiler perspective, the type of the variable is known.
In this case typeof *sa == struct sockaddr_l2cap so the assignment can be shorted.

I compiled with clang and gcc, both work.

How is that possible? For me it fails immediately on system clang:

/usr/src/FreeBSD/sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c:2522:8: error: expected expression
        *sa = {
              ^

I think the problem is not with compiler being able or not being able to determine type of variable. The problem is with compiler parser, which isn't able to tell a code block from structure value.

Sorry I mixed C and C++ features.

I compiled with clang and gcc, both work.

I tested that feature on godbolt.org and forgot to change lang of source code to C, it is default to C++ :-)

Please ignore my previous comment No need for type casting, and go ahead :)

sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522

Minor style changes, to keep align with current practices.

# egrep -r '=\s*\(struct \S+\s*\)\s*{' sys
sys/gdb/netgdb.c:	aux = (struct debugnet_proto_aux) {
...
sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522

I personally like this space. IMHO, it makes it more human readable. If you really insist I can delete it of course, but it is there intentionally. Not a typo.

sys/netgraph/bluetooth/socket/ng_btsocket_l2cap.c
2522

I personally like this space. IMHO, it makes it more human readable. If you really insist I can delete it of course, but it is there intentionally. Not a typo.

Yeh I thought it is typo.

*sa = (struct sockaddr_l2cap ){

I spot this as I do not feel comfortable with it ( I can not tell why ) at the first glance. Probably because I had bad times arguing over code styles with my teammates. ;) We finally concluded a set of checkstyle rules shared between multiple teams and projects and checking styles is done by CI ( via pre commit hook ), then no one waste time arguing about styles any more ;) Anyway enthusiasm and intelligence are precious and as a team we should mainly focus on more important things such as documents / features and bugs.

Well I do not have strong option. I'm OK if you think it makes it more human readable.

Linux emu part, I hope you merge that into at least stable/14

Linux emu part, I hope you merge that into at least stable/14

Nope. It is too large of a change for a stable branch and it doesn't close any critical bug.