Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S934320AbcKKQxI (ORCPT <rfc822;w@1wt.eu>);
        Fri, 11 Nov 2016 11:53:08 -0500
Received: from mail-lf0-f50.google.com ([209.85.215.50]:35798 "EHLO
        mail-lf0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1755923AbcKKQxG (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 11 Nov 2016 11:53:06 -0500
MIME-Version: 1.0
In-Reply-To: <87mvh6j803.fsf@thinkpad.rath.org>
References: <87lgwrufuk.fsf@thinkpad.rath.org> <CAOssrKfa9yV9evADWx+PTc9ddQchO97Mcu4pGAoAaPQ9qtXvwg@mail.gmail.com>
 <87mvh6likl.fsf@vostro.rath.org> <CAOssrKc3RPbJuwTRpkykAvrvgjM0i0J=X8WWrGCpeX67AwGcGA@mail.gmail.com>
 <87mvh6j803.fsf@thinkpad.rath.org>
From: Mike Marshall <hubcap@omnibond.com>
Date: Fri, 11 Nov 2016 11:53:04 -0500
Message-ID: <CAOg9mSShK3mBHAv9WbiGhGTaPEczYwT--NHdtC+wP4xiCarNqg@mail.gmail.com>
Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT
 flag to INIT
To: Nikolaus Rath <Nikolaus@rath.org>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
        Andrew Gallagher <andrewjcg@fb.com>,
        lkml <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uABGrIYN031452
Content-Length: 2547
Lines: 60

I try to choose error codes from the appropriate man
page when vfs calls into Orangefs with
whatever_operations.action... there's probably better
ways, like reading the vfs code and seeing what it
expects <g>...

-Mike

On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath <Nikolaus@rath.org> wrote:
> On Nov 11 2016, Miklos Szeredi <mszeredi@redhat.com> wrote:
>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <Nikolaus@rath.org> wrote:
>>> On Nov 11 2016, Miklos Szeredi <mszeredi@redhat.com> wrote:
>>>> On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT
>>>>> flag. But as far as I can tell, the flag is simply accepted without
>>>>> having any effect (including in libfuse).
>>>>>
>>>>> I tried to find related later commits, but did not find anything either.
>>>>>
>>>>> Am I missing something?
>>>>
>>>> Hmm, if fuse fs detects this flag, then it can return ENOSYS from open
>>>> resulting in this and subsequent opens succeeding without further
>>>> calls to userspace.    If fuse fs doesn't detect this flag, it should
>>>> not return -ENOSYS, as that will result in the open failing, it should
>>>> instead implement a no-op open method.
>>>
>>> That doesn't sound like a good approach to me. That way, the file system
>>> has to *know* that this flag has been introduced in order to behave
>>> correctly, i.e. filesystems that predate the introduction of the flag
>>> will suddenly behave differently.
>>>
>>> I think the correct behavior would be to for the kernel to check if
>>> userspace passed the flag, and treat ENOSYS specially if and only if the
>>> flag was passed.
>>
>> ENOSYS is not a valid return value for any existing syscall.  Fuse
>> uses that fact to attach this special meaning to ENOSYS.  So
>> compatibility is not an issue here, old filesystems should never
>> return ENOSYS from open.
>
> Oh, I was under the impression that any FUSE handler is free to return
> any error it wants. Where does one have to look to determine which
> return values are valid?
>
>
> Best,
> -Nikolaus
>
> --
> GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
> Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>              »Time flies like an arrow, fruit flies like a Banana.«
> --
> 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