Suspicious shifting of sempid in try_atomic_semop()

[Christoph Hellwig]

In ipc/sem.c:try_atomic_semop() there is the following code:

	for (sop = sops; sop < sops + nsops; sop++) {
		...
		curr->sempid = (curr->sempid << 16) | pid;
		....
	}

it's undone in the error case:

	while (sop >= sops) {
		...
		curr->sempid >>= 16;
		...
	}

the problem is that in some cases we seem to end up with a sempid
of zero which leads to wrong returns of semctl(..., GETPID, ...)
like in

	http://www.freestandards.org/lsb/test/results/index.php?testcaseid=732

Is there a specific reason we use this shift method I have missed?

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.