Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Details
- Reviewers
zlei - Group Reviewers
network - Commits
- rG5b0bc0edac5c: socket: Export the FIB number of sockets
rG349d1366edd2: socket: Export the FIB number of sockets
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 60225 Build 57109: arc lint + arc unit
Event Timeline
Looks good to me.
| sys/sys/socketvar.h | ||
|---|---|---|
| 618 | struct xsocket is used as KPI. I wonder if we should prefer fixed sized int, aka int32_t for exported so_fibnum. Thought on either 32bit or 64bit architectures sizeof int == sizeof int32_t. | |
| sys/kern/uipc_socket.c | ||
|---|---|---|
| 5047 | The fib of socket is readonly once set. So I think no need to read it under lock. | |
| sys/kern/uipc_socket.c | ||
|---|---|---|
| 5047 | Somewhat surprisingly, this is not true: see the SO_SETFIB setsockopt handler. Right now, that option handler does not use any locking. I have a patch which adds it in order to synchronize a new check. In particular, I want to disallow changing the FIB of a listening socket, so we have: SOCK_LOCK(so);
if (SOLISTENING(so)) {
error = EINVAL;
...since SOLISTENING() requires some synchronization. So, I prefer to keep the locking here, even though it is formally unnecessary for now. | |
| sys/kern/uipc_socket.c | ||
|---|---|---|
| 5047 | Yes, you are right. I missed SO_SETFIB setsockopt handler while doing the quick review. | |