This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".
The branch, master has been updated
via 4e48aba61aa5733dec195f3813845b2b1a7287be (commit)
via ca3254d4fe579e04a4f77fe703449f3e02e45397 (commit)
via 4f6f1eecda57f5a5524546ad2b4e010753f9e0d2 (commit)
from cdb38f36437ebb3687901f6f65f33e8b65912025 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 4e48aba61aa5733dec195f3813845b2b1a7287be
Author: Milos Nikic <[email protected]>
Date: Tue Oct 27 21:32:24 2026 -0700
libdiskfs: Do not update a node that a failed create did not make
dir_lookup with O_CREAT on a synchronous mount writes out the directory
and the new node after diskfs_create_node, whether or not it succeeded.
When it fails (no space, no free inode, a quota), there is no new node,
and diskfs_file_update was called with a null pointer: any failed
create on a filesystem mounted with -s killed the translator.
Write out the new node only when there is one.
Message-ID: <[email protected]>
commit ca3254d4fe579e04a4f77fe703449f3e02e45397
Author: Milos Nikic <[email protected]>
Date: Tue Oct 27 21:32:23 2026 -0700
libdiskfs: Do not enter names in a removed directory
rmdir, or a rename onto an empty directory, clears the directory and
drops its last link, but the node stays as long as someone holds it: a
port on it, or a process's working directory. Nothing stopped a
create, a link or a rename through such a reference from entering a
name in it. The name is in a directory nothing reaches; when the node
goes, its blocks are freed, and the file entered stays allocated with
no name at all (e2fsck: "Unattached inode"). With a rename, the file's
old name is gone too.
diskfs_direnter now refuses with ENOENT, as Linux does, when the
directory has no links. Its callers already undo the link they took on
an error. diskfs_rename_dir checks before it rewrites "..", as its
error path after the rewrite does not undo it.
How to reproduce:
$ mkdir /tmp/d && cd /tmp/d && rmdir /tmp/d && touch x; echo $?
0
The create in the removed directory succeeds; with this change it fails
with ENOENT.
Message-ID: <[email protected]>
commit 4f6f1eecda57f5a5524546ad2b4e010753f9e0d2
Author: Milos Nikic <[email protected]>
Date: Tue Oct 27 21:32:22 2026 -0700
libdiskfs: Do not unlock the directory being moved before locking it
diskfs_S_dir_rename unlocks FNP before it calls diskfs_rename_dir, which
locks it only with the lookup of FROMNAME. The exits before that, when
the target lookup fails or the target exists with EXCL, jumped to OUT,
which unlocks FNP anyway. Nothing shows when FNP is free, but a thread
holding it, such as a lookup in the directory being moved, loses its
lock.
Clear FNP before those exits, as the exits after the lookup do.
How to reproduce, as a user who cannot write /usr:
$ mkdir ~/d && mv ~/d /usr/
The target lookup fails with EACCES, and OUT unlocks FNP, which this
thread does not hold.
Message-ID: <[email protected]>
-----------------------------------------------------------------------
Summary of changes:
libdiskfs/dir-lookup.c | 4 +++-
libdiskfs/dir-renamed.c | 14 +++++++++++++-
libdiskfs/direnter.c | 9 +++++++++
3 files changed, 25 insertions(+), 2 deletions(-)
hooks/post-receive
--
Hurd
