sys_semop() retries redo the semop copyin() - why?

Martin Husemann <[email protected]>
Newsgroups gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
I am looking at PR 59352, trying to add compat_netbsd32 support for
semtimedop().

I noticed a very strange retry loop in do_semop() where it waits for
other processes and then redoes the whole copyin() of the semops passed
to the system call - which sounds bogus to me, but I might be missing
something.

Making the restart loop happen only after the initial copyin() will make
code sharing with the netbsd32 emulation a lot easier - so is the following
patch OK or is there some reason the userland records need to be copied in
again?

Martin
P.S.: this is a bit hard to read in a context diff - it just moves the
restart label down after the copyin().


Index: sysv_sem.c
===================================================================
RCS file: /cvsroot/src/sys/kern/sysv_sem.c,v
retrieving revision 1.101
diff -c -u -p -r1.101 sysv_sem.c
--- sysv_sem.c	6 Oct 2024 22:15:33 -0000	1.101
+++ sysv_sem.c	29 Apr 2025 16:29:57 -0000
@@ -828,7 +828,6 @@ do_semop(struct lwp *l, int usemid, stru
 		mutex_exit(p->p_lock);
 	}
 
-restart:
 	if (nsops <= SMALL_SOPS) {
 		sops = small_sops;
 	} else if (nsops <= seminfo.semopm) {
@@ -848,6 +847,7 @@ restart:
 		return error;
 	}
 
+restart:
 	mutex_enter(&semlock);
 	/* In case of reallocation, we will wait for completion */
 	while (__predict_false(sem_realloc_state))
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.