Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Apr 2015 17:51:54 -0400
From:      Conrad Meyer <cse.cem@gmail.com>
To:        Guy Helmer <guy.helmer@gmail.com>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: lockf() vs. flock() -- lockf() not locking?
Message-ID:  <CAG6CVpVrs_VqbFC4vAsDooP-z10458Lwi6fUqhotQt3tgCEABQ@mail.gmail.com>
In-Reply-To: <3950D855-0F4E-49E0-A388-4C7ED102B68B@gmail.com>
References:  <3950D855-0F4E-49E0-A388-4C7ED102B68B@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 6, 2015 at 5:18 PM, Guy Helmer <guy.helmer@gmail.com> wrote:
> From my reading of the lockf(3) man page and reviewing the implementation=
 in lib/libc/gen/lockf.c, and corresponding code in sys/kern/kern_descrip.c=
, it appears the lockf() call should be successfully obtaining an advisory =
lock over the whole file like a successful flock() did. However, I have a s=
tress test that quickly corrupts the target file using the lockf() implemen=
tation, and the test fails to cause corruption using the flock() implementa=
tion. I=E2=80=99ve instrumented the code, and it's clear that multiple proc=
esses are simultaneously in the block of code after the =E2=80=9Clockf(fd, =
F_LOCK, 0)=E2=80=9D line.
>
> Am I missing something obvious? Any ideas?


We have switched from a whole file lock to a range lock. I think it
should still make access exclusive, so this sounds like a bug. But
just note that it is a slightly different mutual exclusion mechanism.

Are the locked files on NFS?

Best,
Conrad



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpVrs_VqbFC4vAsDooP-z10458Lwi6fUqhotQt3tgCEABQ>