bin/116543: lockf(1) is broken

Martin Horcicka martin at horcicka.eu
Sat Sep 22 01:50:07 PDT 2007


>Number:         116543
>Category:       bin
>Synopsis:       lockf(1) is broken
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 22 08:50:06 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Martin Horcicka
>Release:        6.2-RELEASE-p6
>Organization:
>Environment:
Not relevant...
>Description:
lockf(1) is broken since revision 1.12 of src/usr.bin/lockf/lockf.c. The author of the changes did not realize that the lock file is removed (by default) before being closed by the process that holds it.

Consider the following series of events:

  Process A acquires the lock file
  Process B tries to acquire it as well but fails and waits
  Process A removes and closes the lock file
  Process B wakes up and acquires the lock file which is already removed (!)
  Process C acquires the lock file because there was no file of that name (!)
  Now both processes B and C think they hold the lock file (!)

>How-To-Repeat:
Run this command in two terminals at the same time:

  lockf lock sh -c 'for n in `jot 10`; do echo mmm; sleep 1; done'

One of them will start running and the other will wait. When the first stops running, run it again. Now you can see two processes running at the same time and both thinking they hold the lock file.

>Fix:
Throw away all changes of src/usr.bin/lockf/lockf.c after revision 1.11. They are wrong.


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list