From nobody Mon Apr 10 23:30:08 2023 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PwQDw5k00z44xH0 for ; Mon, 10 Apr 2023 23:30:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PwQDw3WpSz3G7S for ; Mon, 10 Apr 2023 23:30:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681169408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=sC893dgkGeMAFKsTSt3lfJpOxCTxxBLtrBJQ83XQUn8=; b=xZqV6PT1fEMojR2fzkxIa6ZqAYW8BDuHMJE6HWbyZDFqxDUqRFfbJS7mVwyaD/IoqR3STr zW4nOdCzVb+x8n9RlbxsKD/8hei0mRX7QgABcAlwy3sclokFJXZJSnqTe026x6UAnrSvTE aTWg/95SsMYKTM3teTYW84BoOR+Bx1Z8LDyT8YWg9bd6oMO/Y210VJMUyztUQKDodhJagC j4hqV1PuWJi6kG3WPSLT/YA5+VWjv5muZnZSnDzjnFrv88QLXqDcnd1QbWpGnE0BEdOgIv sV9KmXdekXc7MiuVJqni37ALbTn+IA478p4uJob5JzitXxMZcFauhHoBv0BHMw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681169408; a=rsa-sha256; cv=none; b=jjZtLrFZ59EBYr3dxFz9Dj6XPW5kVEWkA+NbGwAigninE7+g6rDjhPsd6hpcpUjfdHlwwt 6sxdVuv7uKewYRhfCuXbwfXruEWtP7QQ3xs6NwqEEviMKsGiRbheiXXPQG5uOHfKS1x08W WeUkwy1L1MV9SbVQ+z6Y9YGl5K6XafEK4tCfly37nJdUiqPGhNIZVcLXEhUi8lTmTfxnxb pYnSMMRZdlRzXiqHoH2xeQ4/ujUPmONMoVA7Kluivd/DeOWFElq1MVJ/J1Blju50b78AnS 2tcLvCdLLkoivfb0oLAwEJhEIBHCYXl4rc9wE04JfRNqmc5m2TEQr5cEIwKCyA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PwQDw2dBLz18DS for ; Mon, 10 Apr 2023 23:30:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33ANU8wV001694 for ; Mon, 10 Apr 2023 23:30:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33ANU8Gk001693 for bugs@FreeBSD.org; Mon, 10 Apr 2023 23:30:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 270749] [FUSEFS] File close() failures relating to attempted atime update Date: Mon, 10 Apr 2023 23:30:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jamie@catflap.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.mimetype attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270749 Bug ID: 270749 Summary: [FUSEFS] File close() failures relating to attempted atime update Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: jamie@catflap.org Attachment #241405 text/plain mime type: Created attachment 241405 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D241405&action= =3Dedit patch to check whether we have permissions to update atime There is a bug in fusefs, discovered by ThomasWaldmann@github relating to closing files on fusefs filesystems. See: https://github.com/borgbackup/borg/issues/6871 I tracked it down to: title: fusefs: update atime on reads when using cached attributes commit: 0bade34633f997c22f5e4e0931df0d534f560a38 author Alan Somers 2021-11-29 01:53:31 +0000 committer Alan Somers 2021-12-14 22:15:53 +0000 link:=20=20=20=20=20 https://cgit.freebsd.org/src/commit/sys/fs/fuse?h=3Dstable/13&id=3D0bade346= 33f997c22f5e4e0931df0d534f560a38 The problem only started after that commit - I've tested current (as of tod= ay) and the issue still exists there. This is my take of what is going on: Basically, it appears that on a fusefs mounted filesystem, a file close fai= ls when fuse tries to update the "atime" of a file that it doesn't have write-access to. It doesn't matter if the filesystem is mounted read-only - the effect is the same. For example, if a file is opened and read, and then closed, all subsequent closes to that file fail until the filesystem is remounted. - Even closes f= or opens that don't themselves update atime fail - presumably because fuse sti= ll has this metadata pending. The following test demonstrates this. "file-close-check" is a simple c prog= ram that does an fopen/fclose then another fopen/fclose, then fopen/fread 100 bytes/fclose, followed by a final fopen/fclose These are the results. On the remote system, "/tmp/test[12]" are just small text files, one owned by me, one not: 4 -rw-r--r-- 1 jamie wheel - 1,626 10 Apr 19:58 test1 4 -rw-r--r-- 1 root wheel - 1,626 10 Apr 18:56 test2 root@catwalk:/tmp # mkdir xx root@catwalk:/tmp # sshfs jamie@catflap.org:/tmp xx root@catwalk:/tmp # file-close-check xx/test? xx/test1 | open: ok, close: ok | open: ok, close: ok | open: ok, read: 100 bytes, close: ok | open: ok, close: ok xx/test2 | open: ok, close: ok | open: ok, close: ok | open: ok, read: 100 bytes, close: Permission denied | open: ok, close: Permission denied Then run the same command again: root@catwalk:/tmp # file-close-check xx/test? xx/test1 | open: ok, close: ok | open: ok, close: ok | open: ok, read: 100 bytes, close: ok | open: ok, close: ok xx/test2 | open: ok, close: Permission denied | open: ok, close: Permissi= on denied | open: ok, read: 100 bytes, close: Permission denied | open: ok, cl= ose: Permission denied From what I can see, in file "sys/fs/fuse/fuse_vnops.c", it does indeed che= ck if the data flush succeeded, and if so, and there has been an atime update,= it then tries to set that: err =3D fuse_flush(vp, cred, pid, fflag); if (err =3D=3D 0 && (fvdat->flag & FN_ATIMECHANGE)) { struct vattr vap; VATTR_NULL(&vap); vap.va_atime =3D fvdat->cached_attrs.va_atime; err =3D fuse_internal_setattr(vp, &vap, td, NULL); } However, if there is no data to write, the flush succeeds even if there is = no write access to the file, causing the fuse_internal_setattr to then fail. The attached patch "fixes" the problem, by adding the "checkparam" code to = this section too, but I don't know if it's the right fix, or if it breaks what t= he commit does, so someone with more fusefs experience needs to check it. Cheers, Jamie --=20 You are receiving this mail because: You are the assignee for the bug.=