On Sun, 2022-07-10 at 16:42 +0000, Chuck Lever III wrote: > > > On Jul 10, 2022, at 6:43 AM, Igor Mammedov <imammedo@xxxxxxxxxx> wrote: > > > > On Mon, 21 Mar 2022 14:12:31 +0000 > > Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > > couldn't find offender patch on ML so replying here > > Probably: > > https://lore.kernel.org/linux-nfs/AEC24099-5BC9-49C8-B759-920824F23F3C@xxxxxxxxxx/ > > > > > Hi Linus- > > > > > > The following changes since commit 7e57714cd0ad2d5bb90e50b5096a0e671dec1ef3: > > > > > > Linux 5.17-rc6 (2022-02-27 14:36:33 -0800) > > > > > > are available in the Git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git tags/nfsd-5.18 > > > > > > for you to fetch changes up to 4fc5f5346592cdc91689455d83885b0af65d71b8: > > > > > > nfsd: fix using the correct variable for sizeof() (2022-03-20 12:49:38 -0400) > > > > > > ---------------------------------------------------------------- > > > New features: > > > - NFSv3 support in NFSD is now always built > > > - Added NFSD support for the NFSv4 birth-time file attribute > > [...] > > > > > Ondrej Valousek (1): > > > nfsd: Add support for the birth time attribute > > Thank you for the report, Igor. > > > > 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. > > > 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). > > 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. > > > > End result is unusable mount (unless it's treated as readonly). > > 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. > > > > Reproduces with current master (HEAD at e5524c2a1fc40) and MacOS > > client (Big Sur or newest Monterey). > > > > server is typical setup exporting files from XFS (Fedora36) > > > > # rpcdebug -m nfsd -s all > > > > on client: > > > > % mount -t nfs -o vers=4,rw,nfc,sec=sys testnas:/mnt ~/test > > % touch ~/test/fff > > touch: test/fff: Invalid argument > > > > server logs: > > > > nfsd: fh_compose(exp fd:00/128 fff, ino=0) > > NFSD: nfsd4_open filename op_openowner 0000000000000000 > > > > Here is a request the touch generates: > > Network File System, Ops(6): PUTFH, SAVEFH, OPEN, GETATTR, RESTOREFH, GETATTR > > [Program Version: 4] > > [V4 Procedure: COMPOUND (1)] > > Tag: create > > minorversion: 0 > > Operations (count: 6): PUTFH, SAVEFH, OPEN, GETATTR, RESTOREFH, 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 > > > > [...] > > > > 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. > > 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. > > > > open/create without Time_Create succeeds but followup > > setattr with Time_Create fails EINVAL. > > > > 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_Create, 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)] > > > > [...] > > > -- > > > Chuck Lever > > -- > Chuck Lever > > > -- Jeff Layton <jlayton@xxxxxxxxxx>
