From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: Status of fcntl() mandatory locking Date: Tue, 29 Apr 2014 07:21:42 +0200 Message-ID: <535F36E6.80606@gmail.com> References: <535D23D8.8080005@gmail.com> <20140428060757.3127a3c7@tlielax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: mtk.manpages@gmail.com, Linux-Fsdevel , Neil Brown , Theodore T'so , Christoph Hellwig , Andy Lutomirski To: Jeff Layton Return-path: Received: from mail-ee0-f41.google.com ([74.125.83.41]:49502 "EHLO mail-ee0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751656AbaD2FVs (ORCPT ); Tue, 29 Apr 2014 01:21:48 -0400 Received: by mail-ee0-f41.google.com with SMTP id t10so5508133eei.0 for ; Mon, 28 Apr 2014 22:21:47 -0700 (PDT) In-Reply-To: <20140428060757.3127a3c7@tlielax.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 04/28/2014 12:07 PM, Jeff Layton wrote: > On Sun, 27 Apr 2014 17:35:52 +0200 > "Michael Kerrisk (man-pages)" wrote: >=20 >> Hello all, >> >> For a long time now, the fcntl(2) man page has carried this text >> regarding mandatory (byte-range) locking: >> >> >> Mandatory locking >> The implementation of mandatory locking in all known versio= ns >> of Linux is subject to race conditions which render it unrel= i=E2=80=90 >> able: a write(2) call that overlaps with a lock may modify da= ta >> after the mandatory lock is acquired; a read(2) call that ove= r=E2=80=90 >> laps with a lock may detect changes to data that were made on= ly >> after a write lock was acquired. Similar races exist betwe= en >> mandatory locks and mmap(2). It is therefore inadvisable = to >> rely on mandatory locking. >> >> I wanted to check: does it remain true with modern kernels that mand= atory >> locking is unreliable? If things have changed, an uopdate to the man= page >> is obviously in order. >> >> Cheers, >> >> Michael >> >> >=20 > Yes, it's still unreliable in modern kernels for the same reasons. Th= e > basic problem is that another task can race in and grab a lock after > you check for it but before you do the I/O. >=20 > FWIW, this probably fixable if someone is motivated enough to do so. > You could have reads and writes set an implicit lock on the file > that isn't merged with existing locks. Doing that with mmap might be > "interesting" though. Thanks for the confirmation, Jeff. Cheers, Michael --=20 Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html