From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-db5eur01on0093.outbound.protection.outlook.com ([104.47.2.93]:40672
	"EHLO EUR01-DB5-obe.outbound.protection.outlook.com"
	rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
	id S1754745AbcFPNzz (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 16 Jun 2016 09:55:55 -0400
Reply-To: <skinsbursky@virtuozzo.com>
Subject: Re: fuse does not show lock info in /proc/.../fdinfo/...
References: <5751D130.5010202@virtuozzo.com>
 <CAJfpegvSZbrTKDTxjti=mq1tMboBrwqqEzhJfcUQAYNMCYqAcA@mail.gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>,
	Maxim Patlasov <mpatlasov@virtuozzo.com>
CC: fuse-devel <fuse-devel@lists.sourceforge.net>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
From: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Message-ID: <5762A81F.30907@virtuozzo.com>
Date: Thu, 16 Jun 2016 15:22:39 +0200
MIME-Version: 1.0
In-Reply-To: <CAJfpegvSZbrTKDTxjti=mq1tMboBrwqqEzhJfcUQAYNMCYqAcA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Hello Miklos,

16.06.2016 13:49, Miklos Szeredi пишет:
> On Fri, Jun 3, 2016 at 8:49 PM, Maxim Patlasov <mpatlasov@virtuozzo.com> wrote:
>> Hi Miklos,
>>
>> fuse_file_lock() since its inception in 2006 implements F_SETLK command like
>> this:
>>
>>>          if (fc->no_lock)
>>>              err = posix_lock_file(file, fl, NULL);
>>>          else
>>>              err = fuse_setlk(file, fl, 0);
>>
>> where fc->no_lock is a per-mount-point tunable. It would be more natural to
>> posix-lock in both cases, like this:
>>
>>>          err = posix_lock_file(file, fl, NULL);
>>>          if (!err && !fc->no_lock)
>>>              err = fuse_setlk(file, fl, 0);
>>
>> Otherwise, by default, when fc->no_lock=0, posix_lock_file() is never
>> called, and from end-user perspective it is weird that the file was locked
>> successfully, but "fdinfo" does not show the lock.
>>
>> Do you think there were some reasons to implement it that way -- not calling
>> posix_lock_file unconditionally?
> Calling posix_lock_file() *before* we know the file can actually be
> locked may be setting us up for weird bugs.

Could you elaborate a bit on these bugs?
(BTW, it's done like this in NFS)

> It could be called
> afterwards, when we already know the real locking operation succeeded.
>    But we need to think very carefully about races between two locking
> operations, because locking state update is non-atomic after that
> change.
>
> So I think this possibly can be done, but needs some thought.
>
> Thanks,
> Miklos