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