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;
Message-ID: <5268baed1650b4cba32978ad32d14a5ef00539f2.camel@redhat.com>
Subject: Re: [GIT PULL] nfsd changes for 5.18
From:   Jeff Layton <jlayton@redhat.com>
To:     Chuck Lever III <chuck.lever@oracle.com>,
        Igor Mammedov <imammedo@redhat.com>
Cc:     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>,
        Bruce Fields <bfields@fieldses.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 11 Jul 2022 06:33:04 -0400
In-Reply-To: <B62B3A57-A8F7-478B-BBAB-785D0C2EE51C@oracle.com>
References: <EF97E1F5-B70F-4F9F-AC6D-7B48336AE3E5@oracle.com>
         <20220710124344.36dfd857@redhat.com>
         <B62B3A57-A8F7-478B-BBAB-785D0C2EE51C@oracle.com>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.3 (3.44.3-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Sun, 2022-07-10 at 16:42 +0000, Chuck Lever III wrote:
>=20
> > On Jul 10, 2022, at 6:43 AM, Igor Mammedov <imammedo@redhat.com> wrote:
> >=20
> > On Mon, 21 Mar 2022 14:12:31 +0000
> > Chuck Lever III <chuck.lever@oracle.com> wrote:
> >=20
> > couldn't find offender patch on ML so replying here
>=20
> Probably:
>=20
> https://lore.kernel.org/linux-nfs/AEC24099-5BC9-49C8-B759-920824F23F3C@or=
acle.com/
>=20
>=20
> > > Hi Linus-
> > >=20
> > > The following changes since commit 7e57714cd0ad2d5bb90e50b5096a0e671d=
ec1ef3:
> > >=20
> > > Linux 5.17-rc6 (2022-02-27 14:36:33 -0800)
> > >=20
> > > are available in the Git repository at:
> > >=20
> > > git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git tags/nfsd=
-5.18
> > >=20
> > > for you to fetch changes up to 4fc5f5346592cdc91689455d83885b0af65d71=
b8:
> > >=20
> > > nfsd: fix using the correct variable for sizeof() (2022-03-20 12:49:3=
8 -0400)
> > >=20
> > > ----------------------------------------------------------------
> > > New features:
> > > - NFSv3 support in NFSD is now always built
> > > - Added NFSD support for the NFSv4 birth-time file attribute
> > [...]
> >=20
> > > Ondrej Valousek (1):
> > > nfsd: Add support for the birth time attribute
>=20
> Thank you for the report, Igor.
>=20
>=20
> > 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.
>=20
> 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.
>=20
> 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.
>=20

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.

>=20
> > However kernel on server side (since this patch and to
> > current master) upon getting such request will return EINVAL.
> > (my guess is that TIME_CREATE not being decoded properly and
> > that messes up request parsing).
>=20
> I'll send a quick-and-dirty fix your way as we explore the
> question of whether NFSD needs to ignore the birth time value
> in this case.
>=20
>=20
> > End result is unusable mount (unless it's treated as readonly).
>=20
> That seems odd, and not clear whether that's a client or server
> problem. I hope that will clear up once the server deals with
> the time_create attribute appropriately.
>=20
>=20
> > Reproduces with current master (HEAD at e5524c2a1fc40) and MacOS
> > client (Big Sur or newest Monterey).
> >=20
> > server is typical setup exporting files from XFS (Fedora36)
> >=20
> > #  rpcdebug -m nfsd -s all
> >=20
> > on client:
> >=20
> > % mount -t nfs -o vers=3D4,rw,nfc,sec=3Dsys testnas:/mnt  ~/test
> > % touch ~/test/fff
> >     touch: test/fff: Invalid argument
> >=20
> > server logs:
> >=20
> > nfsd: fh_compose(exp fd:00/128 fff, ino=3D0)
> > NFSD: nfsd4_open filename  op_openowner 0000000000000000
> >=20
> > Here is a request the touch generates:
> >        Network File System, Ops(6): PUTFH, SAVEFH, OPEN, GETATTR, RESTO=
REFH, GETATTR
> >            [Program Version: 4]
> >            [V4 Procedure: COMPOUND (1)]
> >            Tag: create
> >            minorversion: 0
> >            Operations (count: 6): PUTFH, SAVEFH, OPEN, GETATTR, RESTORE=
FH, GETATTR
> >                Opcode: PUTFH (22)
> >                Opcode: SAVEFH (32)
> >                Opcode: OPEN (18)
> >                    seqid: 0x00000004
> >                    share_access: OPEN4_SHARE_ACCESS_BOTH (3)
> >                    share_deny: OPEN4_SHARE_DENY_NONE (0)
> >                    clientid: 0xba93c9620aec46ea
> >                    owner: <DATA>
> >                    Open Type: OPEN4_CREATE (1)
> >                        Create Mode: UNCHECKED4 (0)
> >                        Attr mask: 0x00040002 (Mode, Time_Create)
> >                            reco_attr: Mode (33)
> >                            reco_attr: Time_Create (50)
> >                    Claim Type: CLAIM_NULL (0)
> >                        Name: fff
> >=20
> >        [...]
> >=20
> > when trying to copy file via GUI (Finder) it goes a different route
> > but ends up with error anyway and with leftover 0-length file on server
> > with messed up permissions, i.e.
>=20
> The current NFSv4 OPEN(CREATE) code path is still not right. Fixing
> the TIME_CREATE problem should make this symptom go away for now,
> but eventually that path will need to be restructured so that it
> cannot leave a turd if the whole create process was not able to
> complete.
>=20
>=20
> > open/create without Time_Create succeeds but followup
> > setattr with Time_Create fails EINVAL.
> >=20
> >        Network File System, Ops(3): PUTFH, SETATTR, GETATTR
> >            [Program Version: 4]
> >            [V4 Procedure: COMPOUND (1)]
> >            Tag: setattr
> >            minorversion: 0
> >            Operations (count: 3): PUTFH, SETATTR, GETATTR
> >                Opcode: PUTFH (22)
> >                Opcode: SETATTR (34)
> >                    StateID
> >                    Attr mask: 0x00450002 (Mode, Time_Access_Set, Time_C=
reate, Time_Modify_Set)
> >                        reco_attr: Mode (33)
> >                        reco_attr: Time_Access_Set (48)
> >                        reco_attr: Time_Create (50)
> >                        reco_attr: Time_Modify_Set (54)
> >                Opcode: GETATTR (9)
> >            [Main Opcode: SETATTR (34)]
> >=20
> > [...]
> > > --
> > > Chuck Lever
>=20
> --
> Chuck Lever
>=20
>=20
>=20

--=20
Jeff Layton <jlayton@redhat.com>