> Date: Mon, 19 Feb 2018 16:22:30 +0100
> From: Martin Pieuchot <[email protected]>
>
> Now that suser() is no longer messing with a per-process field, we
> can directly turn setrtable(2) as NOLOCK.
>
> Apart from sanity checks this syscall writes an int-sized per-process
> field. Is a memory barrier enough?
>
> ok?
I'm wondering if we need a memory barrier here at all. What race are
you trying to prevent here?
> Index: kern/syscalls.master
> ===================================================================
> RCS file: /cvs/src/sys/kern/syscalls.master,v
> retrieving revision 1.180
> diff -u -p -r1.180 syscalls.master
> --- kern/syscalls.master 12 Dec 2017 01:12:34 -0000 1.180
> +++ kern/syscalls.master 19 Feb 2018 15:05:34 -0000
> @@ -532,7 +532,7 @@
> 307 OBSOL statfs53
> 308 OBSOL fstatfs53
> 309 OBSOL fhstatfs53
> -310 STD { int sys_setrtable(int rtableid); }
> +310 STD NOLOCK { int sys_setrtable(int rtableid); }
> 311 STD NOLOCK { int sys_getrtable(void); }
> 312 OBSOL t32_getdirentries
> 313 STD { int sys_faccessat(int fd, const char *path, \
> Index: kern/uipc_syscalls.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/uipc_syscalls.c,v
> retrieving revision 1.165
> diff -u -p -r1.165 uipc_syscalls.c
> --- kern/uipc_syscalls.c 19 Feb 2018 08:59:52 -0000 1.165
> +++ kern/uipc_syscalls.c 19 Feb 2018 15:19:35 -0000
> @@ -1189,6 +1190,9 @@ sys_setrtable(struct proc *p, void *v, r
> return (EINVAL);
>
> p->p_p->ps_rtableid = (u_int)rtableid;
> + /* Force visibility */
> + membar_producer();
> +
> return (0);
> }
>
>
>
