From owner-cvs-src@FreeBSD.ORG Sat Nov 12 21:00:01 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13DC916A41F; Sat, 12 Nov 2005 21:00:01 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBDA943D45; Sat, 12 Nov 2005 21:00:00 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id jACL00QV051133; Sat, 12 Nov 2005 21:00:00 GMT (envelope-from csjp@repoman.freebsd.org) Received: (from csjp@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id jACL00H4051131; Sat, 12 Nov 2005 21:00:00 GMT (envelope-from csjp) Message-Id: <200511122100.jACL00H4051131@repoman.freebsd.org> From: "Christian S.J. Peron" Date: Sat, 12 Nov 2005 21:00:00 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: RELENG_6 Cc: Subject: cvs commit: src/usr.bin/lockf lockf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 21:00:01 -0000 csjp 2005-11-12 21:00:00 UTC FreeBSD src repository Modified files: (Branch: RELENG_6) usr.bin/lockf lockf.c Log: Sync with head: -style(9) nits MFC Log: Fix long standing race condition associated with how lockf uses open(2) for mutual exclusion: A brief description of the problem: 1) Proc A picks up non-blocking lock on file X 2) Proc B attempts to pickup lock, fails then waits 3) Proc C attempts to pickup lock, fails then waits 4) Proc A releases lock 5) Proc B acquires lock, release it to pickup a non-blocking version 6) Proc C acquires lock, release it to pickup a non-blocking version 7) Both process B and C race each other to pickup lock again This occurs mainly because the processes do not keep the lock after they have been waiting on it. They drop it, attempt to re-acquire it. (They use the wait to notify when the lock has become available then race to pick it up). This results in additional CPU utilization during the race, and can also result in processes picking locks up out of order. This change attempts to correct this problem by eliminating the test/acquire race and having the operating system handle it. Revision Changes Path 1.11.8.1 +93 -130 src/usr.bin/lockf/lockf.c