Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 11 Jul 2022 14:19:41 -0400
From:   Bruce Fields <bfields@fieldses.org>
To:     Jeff Layton <jlayton@redhat.com>
Cc:     Chuck Lever III <chuck.lever@oracle.com>,
        Igor Mammedov <imammedo@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Ondrej Valousek <ondrej.valousek.xm@renesas.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [GIT PULL] nfsd changes for 5.18
Message-ID: <20220711181941.GC14184@fieldses.org>
References: <EF97E1F5-B70F-4F9F-AC6D-7B48336AE3E5@oracle.com>
 <20220710124344.36dfd857@redhat.com>
 <B62B3A57-A8F7-478B-BBAB-785D0C2EE51C@oracle.com>
 <5268baed1650b4cba32978ad32d14a5ef00539f2.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5268baed1650b4cba32978ad32d14a5ef00539f2.camel@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Mon, Jul 11, 2022 at 06:33:04AM -0400, Jeff Layton wrote:
> On Sun, 2022-07-10 at 16:42 +0000, Chuck Lever III wrote:
> > > This patch regressed clients that support TIME_CREATE attribute.
> > > Starting with this patch client might think that server supports
> > > TIME_CREATE and start sending this attribute in its requests.
> > 
> > Indeed, e377a3e698fb ("nfsd: Add support for the birth time
> > attribute") does not include a change to nfsd4_decode_fattr4()
> > that decodes the birth time attribute.
> > 
> > I don't immediately see another storage protocol stack in our
> > kernel that supports a client setting the birth time, so NFSD
> > might have to ignore the client-provided value.
> > 
> 
> Cephfs allows this. My thinking at the time that I implemented it was
> that it should be settable for backup purposes, but this was possibly a
> mistake. On most filesystems, the btime seems to be equivalent to inode
> creation time and is read-only.

So supporting it as read-only seems reasonable.

Clearly, failing to decode the setattr attempt isn't the right way to do
that.  I'm not sure what exactly it should be doing--some kind of
permission error on any setattr containing TIME_CREATE?

--b.