From c3b7f0240fbc0739d5405f922ea5d19ed25346da Mon Sep 17 00:00:00 2001 From: Mike Yuan Date: Mon, 20 Jan 2025 22:26:47 +0100 Subject: [PATCH] mountpoint-util: update comment in is_name_to_handle_at_fatal_error() We can now assume name_to_handle_at() syscall is available, however the underlying fs can still lack support for it. --- src/basic/mountpoint-util.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/basic/mountpoint-util.c b/src/basic/mountpoint-util.c index 15655cc075..4ae5f5191f 100644 --- a/src/basic/mountpoint-util.c +++ b/src/basic/mountpoint-util.c @@ -37,10 +37,10 @@ #define ORIGINAL_MAX_HANDLE_SZ 128 bool is_name_to_handle_at_fatal_error(int err) { - /* name_to_handle_at() can return "acceptable" errors that are due to the context. For example the - * kernel does not support name_to_handle_at() at all (ENOSYS), or the syscall was blocked - * (EACCES/EPERM; maybe through seccomp, because we are running inside of a container), or the mount - * point is not triggered yet (EOVERFLOW, think autofs+nfs4), or some general name_to_handle_at() + /* name_to_handle_at() can return "acceptable" errors that are due to the context. For example + * the file system does not support name_to_handle_at() (EOPNOTSUPP), or the syscall was blocked + * (EACCES/EPERM; maybe through seccomp, because we are running inside of a container), or + * the mount point is not triggered yet (EOVERFLOW, think autofs+nfs4), or some general name_to_handle_at() * flakiness (EINVAL). However other errors are not supposed to happen and therefore are considered * fatal ones. */