Date: Mon, 6 Apr 2015 18:19:32 -0500 From: Guy Helmer <guy.helmer@gmail.com> To: Conrad Meyer <cse.cem@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: lockf() vs. flock() -- lockf() not locking? Message-ID: <38FF4CA2-5116-4168-AC6D-DD6A60AEAB3D@gmail.com> In-Reply-To: <CAG6CVpVrs_VqbFC4vAsDooP-z10458Lwi6fUqhotQt3tgCEABQ@mail.gmail.com> References: <3950D855-0F4E-49E0-A388-4C7ED102B68B@gmail.com> <CAG6CVpVrs_VqbFC4vAsDooP-z10458Lwi6fUqhotQt3tgCEABQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 6, 2015, at 4:51 PM, Conrad Meyer <cse.cem@gmail.com> wrote: >=20 > On Mon, Apr 6, 2015 at 5:18 PM, Guy Helmer <guy.helmer@gmail.com> = wrote: >> =46rom 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 stress test that quickly = corrupts the target file using the lockf() implementation, and the test = fails to cause corruption using the flock() implementation. I=E2=80=99ve = instrumented the code, and it's clear that multiple processes are = simultaneously in the block of code after the =E2=80=9Clockf(fd, F_LOCK, = 0)=E2=80=9D line. >>=20 >> Am I missing something obvious? Any ideas? >=20 >=20 > 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. >=20 > Are the locked files on NFS? No, this involves files on local filesystems. Regards, Guy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38FF4CA2-5116-4168-AC6D-DD6A60AEAB3D>