Re: Unlock getsockopt(2)
On Wed, Nov 30, 2022 at 02:02:03AM +0300, Vitaliy Makkoveev wrote:
> On Mon, Nov 28, 2022 at 08:38:02PM +0300, Vitaliy Makkoveev wrote:
> > Subj.
> >
> > At sockets layer we touch only per-socket data, which is solock()
> > protected().
> >
> > At protocol layer, unix(4) and key management sockets have no
> > (*pr_ctloutput)() handlers. route_ctloutput() touches only per socket
> > data, which is solock() protected. inet{,6} globals are protected by
> > netlock, which is solock() backend for corresponding sockets.
> >
>
> Since getsockopt(2) and setsockopt(2) both follow the same
> (*pr_ctloutput)() handlers, it makes sense to unlock them both.
The scariest part is multicast forwarding. ip_mforward() is called
with shared netlock and kernel lock from ip_input(). The kernel
lock is needed as multicast is not MP safe yet and forwarding changes
multicast data.
As long setsockopt(2) runs with exlusive netlock, kernel lock is
not necessary.
OK bluhm@
Re: Unlock getsockopt(2)
On Mon, Nov 28, 2022 at 08:38:02PM +0300, Vitaliy Makkoveev wrote:
> Subj.
>
> At sockets layer we touch only per-socket data, which is solock()
> protected().
>
> At protocol layer, unix(4) and key management sockets have no
> (*pr_ctloutput)() handlers. route_ctloutput() touches only per socket
> data, which is solock() protected. inet{,6} globals are protected by
> netlock, which is solock() backend for corresponding sockets.
>
Since getsockopt(2) and setsockopt(2) both follow the same
(*pr_ctloutput)() handlers, it makes sense to unlock them both.
Index: sys/kern/syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.236
diff -u -p -r1.236 syscalls.master
--- sys/kern/syscalls.master9 Nov 2022 10:26:28 - 1.236
+++ sys/kern/syscalls.master29 Nov 2022 22:58:25 -
@@ -223,7 +223,7 @@
103STD { int sys_sigreturn(struct sigcontext *sigcntxp); }
104STD { int sys_bind(int s, const struct sockaddr *name, \
socklen_t namelen); }
-105STD { int sys_setsockopt(int s, int level, int name, \
+105STD NOLOCK { int sys_setsockopt(int s, int level, int name, \
const void *val, socklen_t valsize); }
106STD { int sys_listen(int s, int backlog); }
107STD { int sys_chflagsat(int fd, const char *path, \
@@ -249,7 +249,7 @@
struct timespec *timeout); }
117STD NOLOCK { int sys_sendmmsg(int s, struct mmsghdr *mmsg,\
unsigned int vlen, int flags); }
-118STD { int sys_getsockopt(int s, int level, int name, \
+118STD NOLOCK { int sys_getsockopt(int s, int level, int name, \
void *val, socklen_t *avalsize); }
119STD { int sys_thrkill(pid_t tid, int signum, void *tcb); }
120STD NOLOCK { ssize_t sys_readv(int fd, \
Unlock getsockopt(2)
Subj.
At sockets layer we touch only per-socket data, which is solock()
protected().
At protocol layer, unix(4) and key management sockets have no
(*pr_ctloutput)() handlers. route_ctloutput() touches only per socket
data, which is solock() protected. inet{,6} globals are protected by
netlock, which is solock() backend for corresponding sockets.
Index: sys/kern/syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.236
diff -u -p -r1.236 syscalls.master
--- sys/kern/syscalls.master9 Nov 2022 10:26:28 - 1.236
+++ sys/kern/syscalls.master28 Nov 2022 17:29:03 -
@@ -249,7 +249,7 @@
struct timespec *timeout); }
117STD NOLOCK { int sys_sendmmsg(int s, struct mmsghdr *mmsg,\
unsigned int vlen, int flags); }
-118STD { int sys_getsockopt(int s, int level, int name, \
+118STD NOLOCK { int sys_getsockopt(int s, int level, int name, \
void *val, socklen_t *avalsize); }
119STD { int sys_thrkill(pid_t tid, int signum, void *tcb); }
120STD NOLOCK { ssize_t sys_readv(int fd, \
