From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Status of fcntl() mandatory locking Date: Sun, 27 Apr 2014 17:35:52 +0200 Message-ID: <535D23D8.8080005@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: mtk.manpages@gmail.com, Jeff Layton , Neil Brown , Theodore T'so , Christoph Hellwig , Andy Lutomirski To: Linux-Fsdevel Return-path: Received: from mail-ee0-f46.google.com ([74.125.83.46]:51025 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751580AbaD0Prk (ORCPT ); Sun, 27 Apr 2014 11:47:40 -0400 Received: by mail-ee0-f46.google.com with SMTP id t10so4107057eei.19 for ; Sun, 27 Apr 2014 08:47:39 -0700 (PDT) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello all, =46or 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 versions of Linux is subject to race conditions which render it unreli=E2= =80=90 able: a write(2) call that overlaps with a lock may modify data after the mandatory lock is acquired; a read(2) call that over=E2= =80=90 laps with a lock may detect changes to data that were made only after a write lock was acquired. Similar races exist between 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 mandato= ry locking is unreliable? If things have changed, an uopdate to the man pa= ge is obviously in order. 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