NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
bin/56112: races in usr.bin/shlock
>Number: 56112
>Category: bin
>Synopsis: races in usr.bin/shlock
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Apr 16 19:30:00 +0000 2021
>Originator: Justin Parrott
>Release: 9.1 and current
>Organization:
independent
>Environment:
localhost$ uname -a
NetBSD localhost 9.1 NetBSD 9.1 (GENERIC) #0: Sun Oct 18 19:24:30 UTC 2020 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
There's a race in which shlock will notify the caller that it has the lock, but in fact another process has it.
>How-To-Repeat:
I basically have 50 processes dealing with the same couple of locks
Anyway, here's an example:
{ while true; do echo; done } |
xargs -L 1 -P 50 sh -c '
until shlock -f /tmp/lock -p $$; do done
l=$(cat /tmp/lock | sed "s/^[ ]*//")
if [ "$$" != "$l" ]
then
echo pid\($$\) does not match lock\($l\)
else
#echo the lock is ours\!
fi
#sleep 3
'
>Fix:
So inn-2.6.4/backends/shlock.c isn't susceptible to the race as far as I can see (it passes the above example anyway).
Or use flock(1)
Home |
Main Index |
Thread Index |
Old Index