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

[glebius]

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.

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

[zlei]

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]

sys/compat/linux/linux_socket.c

1072–1079

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

[glebius]

sys/netinet/sctp_usrreq.c

7351–7359

And actually fixes a serious bug. Thanks!

[glebius]

sys/cam/ctl/ctl_ha.c

400

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

[glebius]

Address review comments.

This also fixed bug with not copying out entire sockaddr_in6.

[zlei]

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.

[zlei]

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.

[glebius]

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.

[zlei]

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 :)

[zlei]

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) {
...

[glebius]

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.

[zlei]

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.

[dchagin]

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

[glebius]

In D42635#974075, @dchagin wrote:

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.

[glebius]

committed