From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0C9CC5CFC2 for ; Thu, 15 Jul 2021 17:20:20 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3849D613BA for ; Thu, 15 Jul 2021 17:20:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3849D613BA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m4523-0008D9-5Y for qemu-devel@archiver.kernel.org; Thu, 15 Jul 2021 13:20:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m451J-0007PN-5L for qemu-devel@nongnu.org; Thu, 15 Jul 2021 13:19:33 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:25683) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m451G-0003eO-0W for qemu-devel@nongnu.org; Thu, 15 Jul 2021 13:19:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626369568; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=mYzDlwoVaLOn6INOVbdHW1P3RK3Fi1KEFlbx3TGNVgY=; b=LjgQiZe6wJvsgBEjEVVTziVsKtHxN/6mlJHe/Q5eCxkWh6WoVUCvCWa9mgf8AgmxGoOU0t VpRYkXNxs6fa3ca5Sac+60TqvB9gXqYxyQmg5XHgkEBda5qLKtAWOX408VRDxwQLyaDsXm OdVFMRR6pPTnRK/JVwFwz+aFVhyaVvk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-538-yKv-9XYENmWIBMqPOwe1jA-1; Thu, 15 Jul 2021 13:19:18 -0400 X-MC-Unique: yKv-9XYENmWIBMqPOwe1jA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8D7971084F4B; Thu, 15 Jul 2021 17:19:17 +0000 (UTC) Received: from redhat.com (ovpn-115-37.ams2.redhat.com [10.36.115.37]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5316360C05; Thu, 15 Jul 2021 17:19:08 +0000 (UTC) Date: Thu, 15 Jul 2021 18:19:05 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Vladimir Sementsov-Ogievskiy Subject: Re: [PATCH v2] docs: document file-posix locking protocol Message-ID: References: <20210703135033.835344-1-vsementsov@virtuozzo.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Kevin Wolf , qemu-block , Markus Armbruster , QEMU Developers , Max Reitz , Nir Soffer , den@openvz.org, Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, Jul 15, 2021 at 08:13:40PM +0300, Vladimir Sementsov-Ogievskiy wrote: > 03.07.2021 17:50, Nir Soffer wrote: > > On Sat, Jul 3, 2021 at 4:51 PM Vladimir Sementsov-Ogievskiy > > wrote: > > [..] > > > > + > > > +Important notice: Qemu may fallback to POSIX file locks only if OFD locks > > > +unavailable. Other programs should behave similarly: use POSIX file locks > > > +only if OFD locks unavailable and if you are OK with drawbacks of POSIX > > > +file locks (for example, they are lost on close() of any file descriptor > > > +for that file). > > > > Worth an example. > > Hmm.. Copying here the whole #ifdef and probing logic around these locks from Qemu is too much.. > > I can't imagine what small and short could be added here. > > Actually I think, OFD is old enough so we shouldn't care > too much about older kernels without it. Let's just rewrite > paragraph to something like this: Yes, that's a good point. From a Linux POV, I think our platform support matrix means we can assume existance of OFD locking unconditionally. The kernel impl transparently applies to all filesystems too. So we could likely change the code such that Linux always uses OFD and non-Linux uses traditional POSIX locks. > Related question, are POSIX locks somehow compatible with OFD > locks? If one program use OFD and the other use POSIX locks on > the same file.. Will it work or not? Yes, the kernel level implementation uses the same locking primitives internally. The only difference between the two is how they're invoked from userspace, and the semantics around lock release when closing files. So it is fully compatible with applications mixing the two APIs for fcntl POSIX and OFD locking The flock() syscall is however completely independant locking from the fcntl based locking. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|