From owner-cvs-all@FreeBSD.ORG Wed Oct 5 17:39:16 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 295F916A41F; Wed, 5 Oct 2005 17:39:16 +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 C466A43D48; Wed, 5 Oct 2005 17:39:15 +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 j95HdFSW058406; Wed, 5 Oct 2005 17:39:15 GMT (envelope-from csjp@repoman.freebsd.org) Received: (from csjp@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id j95HdFS7058405; Wed, 5 Oct 2005 17:39:15 GMT (envelope-from csjp) Message-Id: <200510051739.j95HdFS7058405@repoman.freebsd.org> From: "Christian S.J. Peron" Date: Wed, 5 Oct 2005 17:39:15 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/usr.bin/lockf lockf.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2005 17:39:16 -0000 csjp 2005-10-05 17:39:15 UTC FreeBSD src repository Modified files: usr.bin/lockf lockf.c 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. Reported by: kris Tested by: kris MFC after: 1 week Revision Changes Path 1.12 +8 -30 src/usr.bin/lockf/lockf.c