* [PATCH 2/2] clock_nanosleep.2, nanosleep.2: Use 'duration' rather than 'request'
From: Alejandro Colomar @ 2024-03-03 12:15 UTC (permalink / raw)
To: Elliott Hughes, Stefan Puiu, Bruno Haible, linux-man
Cc: Alejandro Colomar, GNU C Library, linux-api
In-Reply-To: <ZUIlirG-ypudgpbK@debian>
[-- Attachment #1: Type: text/plain, Size: 4372 bytes --]
It seems much more clear.
Suggested-by: Elliott Hughes <enh@google.com>
Cc: Stefan Puiu <stefan.puiu@gmail.com>
Cc: Bruno Haible <bruno@clisp.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
man2/clock_nanosleep.2 | 20 ++++++++++----------
man2/nanosleep.2 | 12 ++++++------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/man2/clock_nanosleep.2 b/man2/clock_nanosleep.2
index 5bda50e18..0eedc1277 100644
--- a/man2/clock_nanosleep.2
+++ b/man2/clock_nanosleep.2
@@ -19,7 +19,7 @@ .SH SYNOPSIS
.nf
.P
.BI "int clock_nanosleep(clockid_t " clockid ", int " flags ,
-.BI " const struct timespec *" request ,
+.BI " const struct timespec *" duration ,
.BI " struct timespec *_Nullable " remain );
.fi
.P
@@ -94,7 +94,7 @@ .SH DESCRIPTION
If
.I flags
is 0, then the value specified in
-.I request
+.I duration
is interpreted as an interval relative to the current
value of the clock specified by
.IR clockid .
@@ -104,11 +104,11 @@ .SH DESCRIPTION
is
.BR TIMER_ABSTIME ,
then
-.I request
+.I duration
is interpreted as an absolute time as measured by the clock,
.IR clockid .
If
-.I request
+.I duration
is less than or equal to the current value of the clock,
then
.BR clock_nanosleep ()
@@ -117,7 +117,7 @@ .SH DESCRIPTION
.BR clock_nanosleep ()
suspends the execution of the calling thread
until either at least the time specified by
-.I request
+.I duration
has elapsed,
or a signal is delivered that causes a signal handler to be called or
that terminates the process.
@@ -138,7 +138,7 @@ .SH DESCRIPTION
.BR clock_nanosleep ()
again and complete a (relative) sleep.
.SH RETURN VALUE
-On successfully sleeping for the requested interval,
+On successfully sleeping for the requested duration,
.BR clock_nanosleep ()
returns 0.
If the call is interrupted by a signal handler or encounters an error,
@@ -146,7 +146,7 @@ .SH RETURN VALUE
.SH ERRORS
.TP
.B EFAULT
-.I request
+.I duration
or
.I remain
specified an invalid address.
@@ -179,8 +179,8 @@ .SH HISTORY
Linux 2.6,
glibc 2.1.
.SH NOTES
-If the interval specified in
-.I request
+If the
+.I duration
is not an exact multiple of the granularity underlying clock (see
.BR time (7)),
then the interval will be rounded up to the next multiple.
@@ -216,7 +216,7 @@ .SH NOTES
is
.BR TIMER_ABSTIME .
(An absolute sleep can be restarted using the same
-.I request
+.I duration
argument.)
.P
POSIX.1 specifies that
diff --git a/man2/nanosleep.2 b/man2/nanosleep.2
index a8d9f5a8a..6272c21e6 100644
--- a/man2/nanosleep.2
+++ b/man2/nanosleep.2
@@ -22,7 +22,7 @@ .SH SYNOPSIS
.nf
.B #include <time.h>
.P
-.BI "int nanosleep(const struct timespec *" req ,
+.BI "int nanosleep(const struct timespec *" duration ,
.BI " struct timespec *_Nullable " rem );
.fi
.P
@@ -39,7 +39,7 @@ .SH DESCRIPTION
.BR nanosleep ()
suspends the execution of the calling thread
until either at least the time specified in
-.I *req
+.I *duration
has elapsed, or the delivery of a signal
that triggers the invocation of a handler in the calling thread or
that terminates the process.
@@ -80,7 +80,7 @@ .SH DESCRIPTION
and it makes the task of resuming a sleep that has been
interrupted by a signal handler easier.
.SH RETURN VALUE
-On successfully sleeping for the requested interval,
+On successfully sleeping for the requested duration,
.BR nanosleep ()
returns 0.
If the call is interrupted by a signal handler or encounters an error,
@@ -139,7 +139,7 @@ .SH VERSIONS
.BR nanosleep ()
function; ...
Consequently, these time services shall expire when the requested relative
-interval elapses, independently of the new or old value of the clock.
+duration elapses, independently of the new or old value of the clock.
.RE
.SH STANDARDS
POSIX.1-2008.
@@ -158,8 +158,8 @@ .SH HISTORY
This special extension was removed in Linux 2.5.39,
and is thus not available in Linux 2.6.0 and later kernels.
.SH NOTES
-If the interval specified in
-.I req
+If the
+.I duration
is not an exact multiple of the granularity underlying clock (see
.BR time (7)),
then the interval will be rounded up to the next multiple.
--
2.43.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 1/2] man*/: epoll_*(), fcntl(), flock(), ioctl(), msgctl(), *prctl(), ptrace(), quotactl(), reboot(), semctl(), shmctl(), lockf(): Consistently use 'op' and 'operation'
From: Alejandro Colomar @ 2024-03-03 12:15 UTC (permalink / raw)
To: Elliott Hughes, Stefan Puiu, Bruno Haible, linux-man
Cc: Alejandro Colomar, GNU C Library, linux-api
In-Reply-To: <ZUIlirG-ypudgpbK@debian>
[-- Attachment #1: Type: text/plain, Size: 42164 bytes --]
Reported-by: Bruno Haible <bruno@clisp.org>
Cc: Elliott Hughes <enh@google.com>
Cc: Stefan Puiu <stefan.puiu@gmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
man2/arch_prctl.2 | 12 +++---
man2/epoll_wait.2 | 4 +-
man2/fcntl.2 | 70 +++++++++++++++----------------
man2/flock.2 | 6 +--
man2/ioctl.2 | 30 +++++++-------
man2/ioctl_console.2 | 8 ++--
man2/ioctl_fideduperange.2 | 2 +-
man2/ioctl_getfsmap.2 | 6 +--
man2/ioctl_ns.2 | 2 +-
man2/ioctl_tty.2 | 10 ++---
man2/ioctl_userfaultfd.2 | 10 ++---
man2/msgctl.2 | 16 ++++----
man2/prctl.2 | 84 +++++++++++++++++++-------------------
man2/ptrace.2 | 60 +++++++++++++--------------
man2/quotactl.2 | 34 +++++++--------
man2/reboot.2 | 19 +++++----
man2/semctl.2 | 22 +++++-----
man2/shmctl.2 | 20 +++++----
man3/lockf.3 | 11 ++---
19 files changed, 217 insertions(+), 209 deletions(-)
diff --git a/man2/arch_prctl.2 b/man2/arch_prctl.2
index bbb85866c..680d36395 100644
--- a/man2/arch_prctl.2
+++ b/man2/arch_prctl.2
@@ -14,8 +14,8 @@ .SH SYNOPSIS
.BR "#include <sys/syscall.h>" " /* Definition of " SYS_* " constants */"
.B #include <unistd.h>
.P
-.BI "int syscall(SYS_arch_prctl, int " code ", unsigned long " addr );
-.BI "int syscall(SYS_arch_prctl, int " code ", unsigned long *" addr );
+.BI "int syscall(SYS_arch_prctl, int " op ", unsigned long " addr );
+.BI "int syscall(SYS_arch_prctl, int " op ", unsigned long *" addr );
.fi
.P
.IR Note :
@@ -26,8 +26,8 @@ .SH SYNOPSIS
.SH DESCRIPTION
.BR arch_prctl ()
sets architecture-specific process or thread state.
-.I code
-selects a subfunction
+.I op
+selects an operation
and passes argument
.I addr
to it;
@@ -120,8 +120,8 @@ .SH ERRORS
points to an unmapped address or is outside the process address space.
.TP
.B EINVAL
-.I code
-is not a valid subcommand.
+.I op
+is not a valid operation.
.TP
.B ENODEV
.B ARCH_SET_CPUID
diff --git a/man2/epoll_wait.2 b/man2/epoll_wait.2
index 2a0ad6364..20af75075 100644
--- a/man2/epoll_wait.2
+++ b/man2/epoll_wait.2
@@ -173,8 +173,8 @@ .SS epoll_pwait2()
.SH RETURN VALUE
On success,
.BR epoll_wait ()
-returns the number of file descriptors ready for the requested I/O, or zero
-if no file descriptor became ready during the requested
+returns the number of file descriptors ready for the requested I/O operation,
+or zero if no file descriptor became ready during the requested
.I timeout
milliseconds.
On failure,
diff --git a/man2/fcntl.2 b/man2/fcntl.2
index 4973ab028..1f9b2d430 100644
--- a/man2/fcntl.2
+++ b/man2/fcntl.2
@@ -54,21 +54,21 @@ .SH SYNOPSIS
.nf
.B #include <fcntl.h>
.P
-.BI "int fcntl(int " fd ", int " cmd ", ... /* " arg " */ );"
+.BI "int fcntl(int " fd ", int " op ", ... /* " arg " */ );"
.fi
.SH DESCRIPTION
.BR fcntl ()
performs one of the operations described below on the open file descriptor
.IR fd .
The operation is determined by
-.IR cmd .
+.IR op .
.P
.BR fcntl ()
can take an optional third argument.
Whether or not this argument is required is determined by
-.IR cmd .
+.IR op .
The required argument type is indicated in parentheses after each
-.I cmd
+.I op
name (in most cases, the required type is
.IR int ,
and we identify the argument using the name
@@ -83,7 +83,7 @@ .SH DESCRIPTION
a particular operation is to invoke
.BR fcntl ()
with the desired
-.I cmd
+.I op
value and then test whether the call failed with
.BR EINVAL ,
indicating that the kernel does not recognize this value.
@@ -121,7 +121,7 @@ .SS Duplicating a file descriptor
in
.BR open (2).
.SS File descriptor flags
-The following commands manipulate the flags associated with
+The following operations manipulate the flags associated with
a file descriptor.
Currently, only one such flag is defined:
.BR FD_CLOEXEC ,
@@ -198,7 +198,7 @@ .SS File status flags
in
.I arg
are ignored.
-On Linux, this command can change only the
+On Linux, this operation can change only the
.BR O_APPEND ,
.BR O_ASYNC ,
.BR O_DIRECT ,
@@ -529,9 +529,9 @@ .SS Open file description locks (non-POSIX)
By contrast with traditional record locks, the
.I l_pid
field of that structure must be set to zero
-when using the commands described below.
+when using the operations described below.
.P
-The commands for working with open file description locks are analogous
+The operations for working with open file description locks are analogous
to those used with traditional locks:
.TP
.BR F_OFD_SETLK " (\fIstruct flock *\fP)"
@@ -722,7 +722,7 @@ .SS Managing signals
This is done by using the
.BR fcntl ()
.B F_SETFL
-command to set the
+operation to set the
.B O_ASYNC
file status flag on the file descriptor.
Subsequently, a
@@ -732,7 +732,7 @@ .SS Managing signals
The
.BR fcntl ()
.B F_SETSIG
-command can be used to obtain delivery of a signal other than
+operation can be used to obtain delivery of a signal other than
.BR SIGIO .
.IP
Sending a signal to the owner process (group) specified by
@@ -1120,7 +1120,7 @@ .SS Leases
then either remove or downgrade its lease.
A lease is removed by performing an
.B F_SETLEASE
-command specifying
+operation specifying
.I arg
as
.BR F_UNLCK .
@@ -1130,7 +1130,7 @@ .SS Leases
the lease to a read lease.
This is done by performing an
.B F_SETLEASE
-command specifying
+operation specifying
.I arg
as
.BR F_RDLCK .
@@ -1179,11 +1179,11 @@ .SS Leases
.BR SIGIO ,
but this can be changed using the
.B F_SETSIG
-command to
+operation to
.BR fcntl ().
If a
.B F_SETSIG
-command is performed (even one specifying
+operation is performed (even one specifying
.BR SIGIO ),
and the signal
handler is established using
@@ -1289,7 +1289,7 @@ .SS File and directory change notification (dnotify)
.BR SIGIO ,
but this can be changed using the
.B F_SETSIG
-command to
+operation to
.BR fcntl ().
(Note that
.B SIGIO
@@ -1639,7 +1639,7 @@ .SH RETURN VALUE
for the inode referred to by
.IR fd .
.TP
-All other commands
+All other operations
Zero.
.P
On error, \-1 is returned, and
@@ -1659,7 +1659,7 @@ .SH ERRORS
is not an open file descriptor
.TP
.B EBADF
-.I cmd
+.I op
is
.B F_SETLK
or
@@ -1668,7 +1668,7 @@ .SH ERRORS
type of lock requested.
.TP
.B EBUSY
-.I cmd
+.I op
is
.B F_SETPIPE_SZ
and the new pipe capacity specified in
@@ -1677,7 +1677,7 @@ .SH ERRORS
used to store data in the pipe.
.TP
.B EBUSY
-.I cmd
+.I op
is
.BR F_ADD_SEALS ,
.I arg
@@ -1689,14 +1689,14 @@ .SH ERRORS
.B EDEADLK
It was detected that the specified
.B F_SETLKW
-command would cause a deadlock.
+operation would cause a deadlock.
.TP
.B EFAULT
.I lock
is outside your accessible address space.
.TP
.B EINTR
-.I cmd
+.I op
is
.B F_SETLKW
or
@@ -1705,7 +1705,7 @@ .SH ERRORS
.BR signal (7).
.TP
.B EINTR
-.I cmd
+.I op
is
.BR F_GETLK ,
.BR F_SETLK ,
@@ -1719,11 +1719,11 @@ .SH ERRORS
.TP
.B EINVAL
The value specified in
-.I cmd
+.I op
is not recognized by this kernel.
.TP
.B EINVAL
-.I cmd
+.I op
is
.B F_ADD_SEALS
and
@@ -1731,7 +1731,7 @@ .SH ERRORS
includes an unrecognized sealing bit.
.TP
.B EINVAL
-.I cmd
+.I op
is
.B F_ADD_SEALS
or
@@ -1741,7 +1741,7 @@ .SH ERRORS
does not support sealing.
.TP
.B EINVAL
-.I cmd
+.I op
is
.B F_DUPFD
and
@@ -1753,7 +1753,7 @@ .SH ERRORS
.BR getrlimit (2)).
.TP
.B EINVAL
-.I cmd
+.I op
is
.B F_SETSIG
and
@@ -1761,7 +1761,7 @@ .SH ERRORS
is not an allowable signal number.
.TP
.B EINVAL
-.I cmd
+.I op
is
.BR F_OFD_SETLK ,
.BR F_OFD_SETLKW ,
@@ -1772,7 +1772,7 @@ .SH ERRORS
was not specified as zero.
.TP
.B EMFILE
-.I cmd
+.I op
is
.B F_DUPFD
and the per-process limit on the number of open file descriptors
@@ -1785,13 +1785,13 @@ .SH ERRORS
.B ENOTDIR
.B F_NOTIFY
was specified in
-.IR cmd ,
+.IR op ,
but
.I fd
does not refer to a directory.
.TP
.B EPERM
-.I cmd
+.I op
is
.B F_SETPIPE_SZ
and the soft or hard user pipe limit has been reached; see
@@ -1803,7 +1803,7 @@ .SH ERRORS
flag on a file that has the append-only attribute set.
.TP
.B EPERM
-.I cmd
+.I op
was
.BR F_ADD_SEALS ,
but
@@ -1897,7 +1897,7 @@ .SS File locking
system call was added in Linux 2.4.
The newer system call employs a different structure for file locking,
.IR flock64 ,
-and corresponding commands,
+and corresponding operations,
.BR F_GETLK64 ,
.BR F_SETLK64 ,
and
@@ -1940,7 +1940,7 @@ .SS Record locks
system call was added in Linux 2.4.
The newer system call employs a different structure for file locking,
.IR flock64 ,
-and corresponding commands,
+and corresponding operations,
.BR F_GETLK64 ,
.BR F_SETLK64 ,
and
diff --git a/man2/flock.2 b/man2/flock.2
index 279c983ad..9c8f5b3b7 100644
--- a/man2/flock.2
+++ b/man2/flock.2
@@ -22,13 +22,13 @@ .SH SYNOPSIS
.nf
.B #include <sys/file.h>
.P
-.BI "int flock(int " fd ", int " operation );
+.BI "int flock(int " fd ", int " op );
.fi
.SH DESCRIPTION
Apply or remove an advisory lock on the open file specified by
.IR fd .
The argument
-.I operation
+.I op
is one of the following:
.RS 4
.TP 9
@@ -111,7 +111,7 @@ .SH ERRORS
.BR signal (7).
.TP
.B EINVAL
-.I operation
+.I op
is invalid.
.TP
.B ENOLCK
diff --git a/man2/ioctl.2 b/man2/ioctl.2
index c10a5e2ec..5b8c28a9c 100644
--- a/man2/ioctl.2
+++ b/man2/ioctl.2
@@ -20,8 +20,8 @@ .SH SYNOPSIS
.nf
.B #include <sys/ioctl.h>
.P
-.BI "int ioctl(int " fd ", unsigned long " request ", ...);" "\f[R] /* glibc, BSD */\f[]"
-.BI "int ioctl(int " fd ", int " request ", ...);" "\f[R] /* musl, other UNIX */\f[]"
+.BI "int ioctl(int " fd ", unsigned long " op ", ...);" "\f[R] /* glibc, BSD */\f[]"
+.BI "int ioctl(int " fd ", int " op ", ...);" "\f[R] /* musl, other UNIX */\f[]"
.fi
.SH DESCRIPTION
The
@@ -30,12 +30,12 @@ .SH DESCRIPTION
In particular, many operating characteristics of character special files
(e.g., terminals) may be controlled with
.BR ioctl ()
-requests.
+operations.
The argument
.I fd
must be an open file descriptor.
.P
-The second argument is a device-dependent request code.
+The second argument is a device-dependent operation code.
The third argument is an untyped pointer to memory.
It's traditionally
.BI "char *" argp
@@ -45,7 +45,7 @@ .SH DESCRIPTION
.P
An
.BR ioctl ()
-.I request
+.I op
has encoded in it whether the argument is an
.I in
parameter or
@@ -55,7 +55,7 @@ .SH DESCRIPTION
in bytes.
Macros and defines used in specifying an
.BR ioctl ()
-.I request
+.I op
are located in the file
.IR <sys/ioctl.h> .
See NOTES.
@@ -63,7 +63,7 @@ .SH RETURN VALUE
Usually, on success zero is returned.
A few
.BR ioctl ()
-requests use the return value as an output parameter
+operations use the return value as an output parameter
and return a nonnegative value on success.
On error, \-1 is returned, and
.I errno
@@ -79,7 +79,7 @@ .SH ERRORS
references an inaccessible memory area.
.TP
.B EINVAL
-.I request
+.I op
or
.I argp
is not valid.
@@ -89,7 +89,7 @@ .SH ERRORS
is not associated with a character special device.
.TP
.B ENOTTY
-The specified request does not apply to the kind of object that the
+The specified operation does not apply to the kind of object that the
file descriptor
.I fd
references.
@@ -106,7 +106,7 @@ .SH HISTORY
.PD 0
.in +4n
.nf
-.BI "ioctl(int " fildes ", int " request ", struct sgttyb *" argp );
+.BI "ioctl(int " fildes ", int " op ", struct sgttyb *" argp );
.fi
.in
.P
@@ -117,7 +117,7 @@ .SH HISTORY
.BR stty (2)
and
.BR gtty (2),
-and is polymorphic by request type (like a
+and is polymorphic by operation type (like a
.B void *
would be, if it had been available)).
.P
@@ -129,7 +129,7 @@ .SH HISTORY
.PD 0
.in +4n
.nf
-.BI "ioctl(int " d ", unsigned long " request ", char *" argp );
+.BI "ioctl(int " d ", unsigned long " op ", char *" argp );
.fi
.in
.P
@@ -143,7 +143,7 @@ .SH HISTORY
.PD 0
.in +4n
.nf
-.BI "int ioctl(int " fildes ", int " request ", ... /* " arg " */);"
+.BI "int ioctl(int " fildes ", int " op ", ... /* " arg " */);"
.fi
.in
.P
@@ -159,7 +159,9 @@ .SH NOTES
.\"
.SS ioctl structure
.\" added two sections - aeb
-Ioctl command values are 32-bit constants.
+Ioctl
+.I op
+values are 32-bit constants.
In principle these constants are completely arbitrary, but people have
tried to build some structure into them.
.P
diff --git a/man2/ioctl_console.2 b/man2/ioctl_console.2
index abc50b786..93a992264 100644
--- a/man2/ioctl_console.2
+++ b/man2/ioctl_console.2
@@ -25,8 +25,8 @@ .SH NAME
.SH DESCRIPTION
The following Linux-specific
.BR ioctl (2)
-requests are supported for console terminals and virtual consoles.
-Each requires a third argument, assumed here to be
+operations are supported for console terminals and virtual consoles.
+Each operation requires a third argument, assumed here to be
.IR argp .
.TP
.B KDGETLED
@@ -546,7 +546,7 @@ .SH DESCRIPTION
struct vt_mode {
char mode; /* vt mode */
char waitv; /* if set, hang on writes if not active */
- short relsig; /* signal to raise on release req */
+ short relsig; /* signal to raise on release op */
short acqsig; /* signal to raise on acquisition */
short frsig; /* unused (set to 0) */
};
@@ -861,7 +861,7 @@ .SH ERRORS
.TP
.B ENOTTY
The file descriptor is not associated with a character special device,
-or the specified request does not apply to it.
+or the specified operation does not apply to it.
.TP
.B EPERM
Insufficient permission.
diff --git a/man2/ioctl_fideduperange.2 b/man2/ioctl_fideduperange.2
index 8f43a28cc..1942c8fd0 100644
--- a/man2/ioctl_fideduperange.2
+++ b/man2/ioctl_fideduperange.2
@@ -116,7 +116,7 @@ .SH DESCRIPTION
and a status code for the deduplication operation is returned in
.IR status .
If even a single byte in the range does not match, the deduplication
-request will be ignored and
+operation request will be ignored and
.I status
set to
.BR FILE_DEDUPE_RANGE_DIFFERS .
diff --git a/man2/ioctl_getfsmap.2 b/man2/ioctl_getfsmap.2
index 0b0546743..fa9d91894 100644
--- a/man2/ioctl_getfsmap.2
+++ b/man2/ioctl_getfsmap.2
@@ -124,7 +124,7 @@ .SS Keys
.I fsmap_head.fmh_keys[0]
must contain the low key and
.I fsmap_head.fmh_keys[1]
-must contain the high key for the request.
+must contain the high key for the operation.
.P
For convenience, if
.I fmr_length
@@ -328,10 +328,10 @@ .SH ERRORS
was passed in one of the fields that must be zero.
.TP
.B ENOMEM
-Insufficient memory to process the request.
+Insufficient memory to process the operation.
.TP
.B EOPNOTSUPP
-The filesystem does not support this command.
+The filesystem does not support this operation.
.TP
.B EUCLEAN
The filesystem metadata is corrupt and needs repair.
diff --git a/man2/ioctl_ns.2 b/man2/ioctl_ns.2
index 61a1afe65..958a686b0 100644
--- a/man2/ioctl_ns.2
+++ b/man2/ioctl_ns.2
@@ -20,7 +20,7 @@ .SS Discovering namespace relationships
.P
.in +4n
.EX
-new_fd = ioctl(fd, request);
+new_fd = ioctl(fd, op);
.EE
.in
.P
diff --git a/man2/ioctl_tty.2 b/man2/ioctl_tty.2
index 9f198b1d8..c458933a2 100644
--- a/man2/ioctl_tty.2
+++ b/man2/ioctl_tty.2
@@ -18,12 +18,12 @@ .SH SYNOPSIS
.BR " Bnnn" ", " BOTHER ", " CBAUD ", " CLOCAL ,
.BR " TC*" { FLUSH , ON , OFF "} and other constants */"
.P
-.BI "int ioctl(int " fd ", int " cmd ", ...);"
+.BI "int ioctl(int " fd ", int " op ", ...);"
.fi
.SH DESCRIPTION
The
.BR ioctl (2)
-call for terminals and serial ports accepts many possible command arguments.
+call for terminals and serial ports accepts many possible operation arguments.
Most require a third argument, of varying type, here called
.I argp
or
@@ -735,7 +735,7 @@ .SS Kernel debugging
.I tty_struct
corresponding to
.IR fd .
-This command was removed in Linux 2.5.67.
+This operation was removed in Linux 2.5.67.
.\" commit b3506a09d15dc5aee6d4bb88d759b157016e1864
.\" Author: Andries E. Brouwer <andries.brouwer@cwi.nl>
.\" Date: Tue Apr 1 04:42:46 2003 -0800
@@ -764,10 +764,10 @@ .SH RETURN VALUE
.SH ERRORS
.TP
.B EINVAL
-Invalid command parameter.
+Invalid operation parameter.
.TP
.B ENOIOCTLCMD
-Unknown command.
+Unknown operation.
.TP
.B ENOTTY
Inappropriate
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index a2380a670..cbd0c7978 100644
--- a/man2/ioctl_userfaultfd.2
+++ b/man2/ioctl_userfaultfd.2
@@ -17,7 +17,7 @@ .SH SYNOPSIS
.BR "#include <linux/userfaultfd.h>" " /* Definition of " UFFD* " constants */"
.B #include <sys/ioctl.h>
.P
-.BI "int ioctl(int " fd ", int " cmd ", ...);"
+.BI "int ioctl(int " fd ", int " op ", ...);"
.fi
.SH DESCRIPTION
Various
@@ -28,18 +28,18 @@ .SH DESCRIPTION
.P
.in +4n
.EX
-ioctl(fd, cmd, argp);
+ioctl(fd, op, argp);
.EE
.in
.P
In the above,
.I fd
is a file descriptor referring to a userfaultfd object,
-.I cmd
-is one of the commands listed below, and
+.I op
+is one of the operations listed below, and
.I argp
is a pointer to a data structure that is specific to
-.IR cmd .
+.IR op .
.P
The various
.BR ioctl (2)
diff --git a/man2/msgctl.2 b/man2/msgctl.2
index 3e69eb600..70f4d1cf8 100644
--- a/man2/msgctl.2
+++ b/man2/msgctl.2
@@ -26,12 +26,12 @@ .SH SYNOPSIS
.nf
.B #include <sys/msg.h>
.P
-.BI "int msgctl(int " msqid ", int " cmd ", struct msqid_ds *" buf );
+.BI "int msgctl(int " msqid ", int " op ", struct msqid_ds *" buf );
.fi
.SH DESCRIPTION
.BR msgctl ()
performs the control operation specified by
-.I cmd
+.I op
on the System\ V message queue with identifier
.IR msqid .
.P
@@ -142,7 +142,7 @@ .SH DESCRIPTION
Bits 0100, 0010, and 0001 (the execute bits) are unused by the system.
.P
Valid values for
-.I cmd
+.I op
are:
.TP
.B IPC_STAT
@@ -320,7 +320,7 @@ .SH ERRORS
.TP
.B EACCES
The argument
-.I cmd
+.I op
is equal to
.B IPC_STAT
or
@@ -333,7 +333,7 @@ .SH ERRORS
.TP
.B EFAULT
The argument
-.I cmd
+.I op
has the value
.B IPC_SET
or
@@ -347,7 +347,7 @@ .SH ERRORS
.TP
.B EINVAL
Invalid value for
-.I cmd
+.I op
or
.IR msqid .
Or: for a
@@ -358,7 +358,7 @@ .SH ERRORS
.TP
.B EPERM
The argument
-.I cmd
+.I op
has the value
.B IPC_SET
or
@@ -402,7 +402,7 @@ .SH HISTORY
(The kernel distinguishes old and new calls by an
.B IPC_64
flag in
-.IR cmd .)
+.IR op .)
.SH NOTES
The
.BR IPC_INFO ,
diff --git a/man2/prctl.2 b/man2/prctl.2
index 31da22369..fad855832 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -46,7 +46,7 @@ .SH SYNOPSIS
.nf
.B #include <sys/prctl.h>
.P
-.BI "int prctl(int " operation ", ..."
+.BI "int prctl(int " op ", ..."
.BI " \fR/*\fP unsigned long " arg2 ", unsigned long " arg3 ,
.BI " unsigned long " arg4 ", unsigned long " arg5 " \fR*/\fP );"
.fi
@@ -2096,7 +2096,7 @@ .SH RETURN VALUE
.B PR_GET_SECCOMP
return the nonnegative values described above.
All other
-.I operation
+.I op
values return 0 on success.
On error, \-1 is returned, and
.I errno
@@ -2104,7 +2104,7 @@ .SH RETURN VALUE
.SH ERRORS
.TP
.B EACCES
-.I operation
+.I op
is
.B PR_SET_SECCOMP
and
@@ -2120,7 +2120,7 @@ .SH ERRORS
above).
.TP
.B EACCES
-.I operation
+.I op
is
.BR PR_SET_MM ,
and
@@ -2130,7 +2130,7 @@ .SH ERRORS
the file is not executable.
.TP
.B EBADF
-.I operation
+.I op
is
.BR PR_SET_MM ,
.I arg3
@@ -2141,7 +2141,7 @@ .SH ERRORS
is not valid.
.TP
.B EBUSY
-.I operation
+.I op
is
.BR PR_SET_MM ,
.I arg3
@@ -2156,7 +2156,7 @@ .SH ERRORS
is an invalid address.
.TP
.B EFAULT
-.I operation
+.I op
is
.BR PR_SET_SECCOMP ,
.I arg2
@@ -2169,7 +2169,7 @@ .SH ERRORS
is an invalid address.
.TP
.B EFAULT
-.I operation
+.I op
is
.B PR_SET_SYSCALL_USER_DISPATCH
and
@@ -2178,12 +2178,12 @@ .SH ERRORS
.TP
.B EINVAL
The value of
-.I operation
+.I op
is not recognized,
or not supported on this system.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_MCE_KILL
or
@@ -2197,10 +2197,10 @@ .SH ERRORS
.B EINVAL
.I arg2
is not valid value for this
-.IR operation .
+.IR op .
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_SECCOMP
or
@@ -2209,7 +2209,7 @@ .SH ERRORS
.BR CONFIG_SECCOMP .
.TP
.B EINVAL
-.I operation
+.I op
is
.BR PR_SET_SECCOMP ,
.I arg2
@@ -2219,7 +2219,7 @@ .SH ERRORS
.BR CONFIG_SECCOMP_FILTER .
.TP
.B EINVAL
-.I operation
+.I op
is
.BR PR_SET_MM ,
and one of the following is true
@@ -2259,7 +2259,7 @@ .SH ERRORS
.RE
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_PTRACER
and
@@ -2269,7 +2269,7 @@ .SH ERRORS
or the PID of an existing process.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_PDEATHSIG
and
@@ -2277,7 +2277,7 @@ .SH ERRORS
is not a valid signal number.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_DUMPABLE
and
@@ -2288,7 +2288,7 @@ .SH ERRORS
.BR SUID_DUMP_USER .
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_TIMING
and
@@ -2297,7 +2297,7 @@ .SH ERRORS
.BR PR_TIMING_STATISTICAL .
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_NO_NEW_PRIVS
and
@@ -2311,7 +2311,7 @@ .SH ERRORS
is nonzero.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_GET_NO_NEW_PRIVS
and
@@ -2323,7 +2323,7 @@ .SH ERRORS
is nonzero.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_THP_DISABLE
and
@@ -2334,7 +2334,7 @@ .SH ERRORS
is nonzero.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_GET_THP_DISABLE
and
@@ -2346,7 +2346,7 @@ .SH ERRORS
is nonzero.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_CAP_AMBIENT
and an unused argument
@@ -2371,7 +2371,7 @@ .SH ERRORS
does not specify a valid capability.
.TP
.B EINVAL
-.I operation
+.I op
was
.B PR_GET_SPECULATION_CTRL
or
@@ -2381,7 +2381,7 @@ .SH ERRORS
are not 0.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_PAC_RESET_KEYS
and the arguments are invalid or unsupported.
@@ -2390,7 +2390,7 @@ .SH ERRORS
above for details.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SVE_SET_VL
and the arguments are invalid or unsupported,
@@ -2400,13 +2400,13 @@ .SH ERRORS
above for details.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SVE_GET_VL
and SVE is not available on this platform.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_SYSCALL_USER_DISPATCH
and one of the following is true:
@@ -2428,7 +2428,7 @@ .SH ERRORS
.RE
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_SET_TAGGED_ADDR_CTRL
and the arguments are invalid or unsupported.
@@ -2437,7 +2437,7 @@ .SH ERRORS
above for details.
.TP
.B EINVAL
-.I operation
+.I op
is
.B PR_GET_TAGGED_ADDR_CTRL
and the arguments are invalid or unsupported.
@@ -2446,13 +2446,13 @@ .SH ERRORS
above for details.
.TP
.B ENODEV
-.I operation
+.I op
was
.B PR_SET_SPECULATION_CTRL
the kernel or CPU does not support the requested speculation misfeature.
.TP
.B ENXIO
-.I operation
+.I op
was
.B PR_MPX_ENABLE_MANAGEMENT
or
@@ -2461,7 +2461,7 @@ .SH ERRORS
Check that the kernel and processor have MPX support.
.TP
.B ENXIO
-.I operation
+.I op
was
.B PR_SET_SPECULATION_CTRL
implies that the control of the selected speculation misfeature is not possible.
@@ -2470,7 +2470,7 @@ .SH ERRORS
for the bit fields to determine which option is available.
.TP
.B EOPNOTSUPP
-.I operation
+.I op
is
.B PR_SET_FP_MODE
and
@@ -2478,7 +2478,7 @@ .SH ERRORS
has an invalid or unsupported value.
.TP
.B EPERM
-.I operation
+.I op
is
.BR PR_SET_SECUREBITS ,
and the caller does not have the
@@ -2490,7 +2490,7 @@ .SH ERRORS
.BR capabilities (7)).
.TP
.B EPERM
-.I operation
+.I op
is
.B PR_SET_SPECULATION_CTRL
wherein the speculation was disabled with
@@ -2498,7 +2498,7 @@ .SH ERRORS
and caller tried to enable it again.
.TP
.B EPERM
-.I operation
+.I op
is
.BR PR_SET_KEEPCAPS ,
and the caller's
@@ -2508,7 +2508,7 @@ .SH ERRORS
.BR capabilities (7)).
.TP
.B EPERM
-.I operation
+.I op
is
.BR PR_CAPBSET_DROP ,
and the caller does not have the
@@ -2516,7 +2516,7 @@ .SH ERRORS
capability.
.TP
.B EPERM
-.I operation
+.I op
is
.BR PR_SET_MM ,
and the caller does not have the
@@ -2524,7 +2524,7 @@ .SH ERRORS
capability.
.TP
.B EPERM
-.I operation
+.I op
is
.B PR_CAP_AMBIENT
and
@@ -2539,7 +2539,7 @@ .SH ERRORS
securebit has been set.
.TP
.B ERANGE
-.I operation
+.I op
was
.B PR_SET_SPECULATION_CTRL
and
@@ -2559,7 +2559,7 @@ .SH VERSIONS
.P
.in +4n
.EX
-.BI "ptrdiff_t prctl(int " operation ", int " arg2 ", int " arg3 );
+.BI "ptrdiff_t prctl(int " op ", int " arg2 ", int " arg3 );
.EE
.in
.P
diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 73afd3174..c6487656c 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -93,7 +93,7 @@ .SH SYNOPSIS
.nf
.B #include <sys/ptrace.h>
.P
-.BI "long ptrace(enum __ptrace_request " request ", pid_t " pid ,
+.BI "long ptrace(enum __ptrace_request " op ", pid_t " pid ,
.BI " void *" addr ", void *" data );
.fi
.SH DESCRIPTION
@@ -155,7 +155,7 @@ .SH DESCRIPTION
value containing information that indicates
the cause of the stop in the tracee.
While the tracee is stopped,
-the tracer can use various ptrace requests to inspect and modify the tracee.
+the tracer can use various ptrace operations to inspect and modify the tracee.
The tracer then causes the tracee to continue,
optionally ignoring the delivered signal
(or even delivering a different signal instead).
@@ -175,12 +175,12 @@ .SH DESCRIPTION
.BR PTRACE_DETACH .
.P
The value of
-.I request
-determines the action to be performed:
+.I op
+determines the operation to be performed:
.TP
.B PTRACE_TRACEME
Indicate that this process is to be traced by its parent.
-A process probably shouldn't make this request if its parent
+A process probably shouldn't make this operation if its parent
isn't expecting to trace it.
.RI ( pid ,
.IR addr ,
@@ -190,12 +190,12 @@ .SH DESCRIPTION
.IP
The
.B PTRACE_TRACEME
-request is used only by the tracee;
-the remaining requests are used only by the tracer.
-In the following requests,
+operation is used only by the tracee;
+the remaining operations are used only by the tracer.
+In the following operations,
.I pid
specifies the thread ID of the tracee to be acted on.
-For requests other than
+For operations other than
.BR PTRACE_ATTACH ,
.BR PTRACE_SEIZE ,
.BR PTRACE_INTERRUPT ,
@@ -212,7 +212,7 @@ .SH DESCRIPTION
.BR ptrace ()
call.
Linux does not have separate text and data address spaces,
-so these two requests are currently equivalent.
+so these two operations are currently equivalent.
.RI ( data
is ignored; but see NOTES.)
.TP
@@ -246,7 +246,7 @@ .SH DESCRIPTION
.B PTRACE_PEEKTEXT
and
.BR PTRACE_PEEKDATA ,
-these two requests are currently equivalent.
+these two operations are currently equivalent.
.TP
.B PTRACE_POKEUSER
.\" PTRACE_POKEUSR in kernel source, but glibc uses PTRACE_POKEUSER,
@@ -740,7 +740,7 @@ .SH DESCRIPTION
The
.I addr
argument is ignored.
-This request is currently
+This operation is currently
.\" As of 4.19-rc2
supported only on arm (and arm64, though only for backwards compatibility),
.\" commit 27aa55c5e5123fa8b8ad0156559d34d7edff58ca
@@ -770,7 +770,7 @@ .SH DESCRIPTION
The
.I addr
argument is ignored.
-These requests are currently
+These operations are currently
.\" As at 3.7
supported only on x86.
.TP
@@ -1211,7 +1211,7 @@ .SS Death under ptrace
.I waitpid(WNOHANG)
may return 0 instead.
In other words, the tracee may be "not yet fully dead",
-but already refusing ptrace requests.
+but already refusing ptrace operations.
.P
The tracer can't assume that the tracee
.I always
@@ -1355,7 +1355,7 @@ .SS Signal-delivery-stop
At this point, the signal is not yet delivered to the process,
and can be suppressed by the tracer.
If the tracer doesn't suppress the signal,
-it passes the signal to the tracee in the next ptrace restart request.
+it passes the signal to the tracee in the next ptrace restart operation.
This second step of signal delivery is called
.I "signal injection"
in this manual page.
@@ -1390,7 +1390,7 @@ .SS Signal injection and suppression
.P
where
.B PTRACE_restart
-is one of the restarting ptrace requests.
+is one of the restarting ptrace operations.
If
.I sig
is 0, then a signal is not delivered.
@@ -1434,7 +1434,7 @@ .SS Signal injection and suppression
.BR tgkill (2)
instead.
.P
-The fact that signal injection requests may be ignored
+The fact that signal injection operations may be ignored
when restarting the tracee after
ptrace stops that are not signal-delivery-stops
is a cause of confusion among ptrace users.
@@ -1798,7 +1798,7 @@ .SS Syscall-stops
etc.),
expiration of a POSIX timer,
change of state on a POSIX message queue,
-or completion of an asynchronous I/O request.
+or completion of an asynchronous I/O operation.
.TP
.IR si_code " == SI_KERNEL (0x80)"
.B SIGTRAP
@@ -2097,7 +2097,7 @@ .SS Attaching and detaching
.B PTRACE_INTERRUPT
command.
.P
-The request
+The operation
.P
.in +4n
.EX
@@ -2385,21 +2385,21 @@ .SS Real parent
.SH RETURN VALUE
On success, the
.B PTRACE_PEEK*
-requests return the requested data (but see NOTES),
+operations return the requested data (but see NOTES),
the
.B PTRACE_SECCOMP_GET_FILTER
-request returns the number of instructions in the BPF program,
+operation returns the number of instructions in the BPF program,
the
.B PTRACE_GET_SYSCALL_INFO
-request returns the number of bytes available to be written by the kernel,
-and other requests return zero.
+operation returns the number of bytes available to be written by the kernel,
+and other operations return zero.
.P
-On error, all requests return \-1, and
+On error, all operations return \-1, and
.I errno
is set to indicate the error.
Since the value returned by a successful
.B PTRACE_PEEK*
-request may be \-1, the caller must clear
+operation may be \-1, the caller must clear
.I errno
before the call, and then check it afterward
to determine whether or not an error occurred.
@@ -2423,11 +2423,11 @@ .SH ERRORS
An attempt was made to set an invalid option.
.TP
.B EIO
-.I request
+.I op
is invalid, or an attempt was made to read from or
write to an invalid area in the tracer's or the tracee's memory,
or there was a word-alignment violation,
-or an invalid signal was specified during a restart request.
+or an invalid signal was specified during a restart operation.
.TP
.B EPERM
The specified process cannot be traced.
@@ -2445,7 +2445,7 @@ .SH ERRORS
.B ESRCH
The specified process does not exist, or is not currently being traced
by the caller, or is not stopped
-(for requests that require a stopped tracee).
+(for operations that require a stopped tracee).
.SH STANDARDS
None.
.SH HISTORY
@@ -2462,7 +2462,7 @@ .SH NOTES
glibc currently declares
.BR ptrace ()
as a variadic function with only the
-.I request
+.I op
argument fixed.
It is recommended to always supply four arguments,
even if the requested operation does not use them,
@@ -2829,7 +2829,7 @@ .SS C library/kernel differences
.BR PTRACE_PEEKDATA ,
and
.B PTRACE_PEEKUSER
-requests have a different API: they store the result
+operations have a different API: they store the result
at the address specified by the
.I data
parameter, and the return value is the error flag.
diff --git a/man2/quotactl.2 b/man2/quotactl.2
index d7ec80e7b..3807507e8 100644
--- a/man2/quotactl.2
+++ b/man2/quotactl.2
@@ -17,7 +17,7 @@ .SH SYNOPSIS
" constants"
.RB " (or " <linux/dqblk_xfs.h> "; see NOTES) */"
.P
-.BI "int quotactl(int " cmd ", const char *_Nullable " special ", int " id ,
+.BI "int quotactl(int " op ", const char *_Nullable " special ", int " id ,
.BI " caddr_t " addr );
.fi
.SH DESCRIPTION
@@ -35,14 +35,14 @@ .SH DESCRIPTION
.BR quotactl ()
call manipulates disk quotas.
The
-.I cmd
-argument indicates a command to be applied to the user or
+.I op
+argument indicates an operation to be applied to the user or
group ID specified in
.IR id .
To initialize the
-.I cmd
+.I op
argument, use the
-.I QCMD(subcmd, type)
+.I QCMD(subop, type)
macro.
The
.I type
@@ -55,7 +55,7 @@ .SH DESCRIPTION
.BR PRJQUOTA ,
for project quotas.
The
-.I subcmd
+.I subop
value is described below.
.P
The
@@ -65,14 +65,14 @@ .SH DESCRIPTION
.P
The
.I addr
-argument is the address of an optional, command-specific, data structure
+argument is the address of an optional, operation-specific, data structure
that is copied in or out of the system.
The interpretation of
.I addr
is given with each operation below.
.P
The
-.I subcmd
+.I subop
value is one of the following operations:
.TP
.B Q_QUOTAON
@@ -649,7 +649,7 @@ .SH DESCRIPTION
which identify what types of quota
should be removed.
(Note that the quota type passed in the
-.I cmd
+.I op
argument is ignored, but should remain valid in order to pass preliminary
quotactl syscall handler checks.)
.IP
@@ -681,7 +681,7 @@ .SH RETURN VALUE
.SH ERRORS
.TP
.B EACCES
-.I cmd
+.I op
is
.BR Q_QUOTAON ,
and the quota file pointed to by
@@ -691,7 +691,7 @@ .SH ERRORS
.IR special .
.TP
.B EBUSY
-.I cmd
+.I op
is
.BR Q_QUOTAON ,
but another
@@ -705,20 +705,20 @@ .SH ERRORS
is invalid.
.TP
.B EINVAL
-.I cmd
+.I op
or
.I type
is invalid.
.TP
.B EINVAL
-.I cmd
+.I op
is
.BR Q_QUOTAON ,
but the specified quota file is corrupted.
.TP
.BR EINVAL " (since Linux 5.5)"
.\" 3dd4d40b420846dd35869ccc8f8627feef2cff32
-.I cmd
+.I op
is
.BR Q_XQUOTARM ,
but
@@ -747,7 +747,7 @@ .SH ERRORS
for the specified operation.
.TP
.B ERANGE
-.I cmd
+.I op
is
.BR Q_SETQUOTA ,
but the specified limits are out of the range allowed by the quota format.
@@ -757,13 +757,13 @@ .SH ERRORS
Quotas have not been turned on for this filesystem.
.TP
.B ESRCH
-.I cmd
+.I op
is
.BR Q_QUOTAON ,
but the specified quota format was not found.
.TP
.B ESRCH
-.I cmd
+.I op
is
.B Q_GETNEXTQUOTA
or
diff --git a/man2/reboot.2 b/man2/reboot.2
index e00ef20eb..6d106e3dc 100644
--- a/man2/reboot.2
+++ b/man2/reboot.2
@@ -21,7 +21,7 @@ .SH SYNOPSIS
.BR "#include <sys/syscall.h> " "/* Definition of " SYS_* " constants */"
.B #include <unistd.h>
.P
-.BI "int syscall(SYS_reboot, int " magic ", int " magic2 ", int " cmd ", void *" arg );
+.BI "int syscall(SYS_reboot, int " magic ", int " magic2 ", int " op ", void *" arg );
.P
/* Under glibc and most alternative libc's (including uclibc, dietlibc,
musl and a few others), some of the constants involved have gotten
@@ -31,7 +31,7 @@ .SH SYNOPSIS
.BR "#include <sys/reboot.h> " "/* Definition of " RB_* " constants */"
.B #include <unistd.h>
.P
-.BI "int reboot(int " cmd );
+.BI "int reboot(int " op );
.fi
.SH DESCRIPTION
The
@@ -66,7 +66,7 @@ .SH DESCRIPTION
(The hexadecimal values of these constants are meaningful.)
.P
The
-.I cmd
+.I op
argument can have the following values:
.TP
.B LINUX_REBOOT_CMD_CAD_OFF
@@ -157,7 +157,7 @@ .SS Behavior inside PID namespaces
is called
from a PID namespace other than the initial PID namespace
with one of the
-.I cmd
+.I op
values listed below,
it performs a "reboot" of that namespace:
the "init" process of the PID namespace is immediately terminated,
@@ -165,7 +165,7 @@ .SS Behavior inside PID namespaces
.BR pid_namespaces (7).
.P
The values that can be supplied in
-.I cmd
+.I op
when calling
.BR reboot ()
in this case are as follows:
@@ -191,7 +191,7 @@ .SS Behavior inside PID namespaces
signal.
.P
For the other
-.I cmd
+.I op
values,
.BR reboot ()
returns \-1 and
@@ -200,13 +200,13 @@ .SS Behavior inside PID namespaces
.BR EINVAL .
.SH RETURN VALUE
For the values of
-.I cmd
+.I op
that stop or restart the system,
a successful call to
.BR reboot ()
does not return.
For the other
-.I cmd
+.I op
values, zero is returned on success.
In all cases, \-1 is returned on failure, and
.I errno
@@ -218,7 +218,8 @@ .SH ERRORS
.BR LINUX_REBOOT_CMD_RESTART2 .
.TP
.B EINVAL
-Bad magic numbers or \fIcmd\fP.
+Bad magic numbers or
+.IR op .
.TP
.B EPERM
The calling process has insufficient privilege to call
diff --git a/man2/semctl.2 b/man2/semctl.2
index 2dcb63559..243919c73 100644
--- a/man2/semctl.2
+++ b/man2/semctl.2
@@ -30,12 +30,12 @@ .SH SYNOPSIS
.nf
.B #include <sys/sem.h>
.P
-.BI "int semctl(int " semid ", int " semnum ", int " cmd ", ...);"
+.BI "int semctl(int " semid ", int " semnum ", int " op ", ...);"
.fi
.SH DESCRIPTION
.BR semctl ()
performs the control operation specified by
-.I cmd
+.I op
on the System\ V semaphore set identified by
.IR semid ,
or on the
@@ -44,7 +44,7 @@ .SH DESCRIPTION
(The semaphores in a set are numbered starting at 0.)
.P
This function has three or four arguments, depending on
-.IR cmd .
+.IR op .
When there are four, the fourth has the type
.IR "union semun" .
The \fIcalling program\fP must define this union as follows:
@@ -149,7 +149,7 @@ .SH DESCRIPTION
Bits 0100, 0010, and 0001 (the execute bits) are unused by the system.
.P
Valid values for
-.I cmd
+.I op
are:
.TP
.B IPC_STAT
@@ -380,7 +380,7 @@ .SH RETURN VALUE
On success,
.BR semctl ()
returns a nonnegative value depending on
-.I cmd
+.I op
as follows:
.TP
.B GETNCNT
@@ -422,7 +422,7 @@ .SH RETURN VALUE
.BR SEM_STAT .
.P
All other
-.I cmd
+.I op
values return 0 on success.
.P
On failure,
@@ -434,7 +434,7 @@ .SH ERRORS
.TP
.B EACCES
The argument
-.I cmd
+.I op
has one of the values
.BR GETALL ,
.BR GETPID ,
@@ -464,7 +464,7 @@ .SH ERRORS
.TP
.B EINVAL
Invalid value for
-.I cmd
+.I op
or
.IR semid .
Or: for a
@@ -475,7 +475,7 @@ .SH ERRORS
.TP
.B EPERM
The argument
-.I cmd
+.I op
has the value
.B IPC_SET
or
@@ -493,7 +493,7 @@ .SH ERRORS
.TP
.B ERANGE
The argument
-.I cmd
+.I op
has the value
.B SETALL
or
@@ -575,7 +575,7 @@ .SH HISTORY
(The kernel distinguishes old and new calls by an
.B IPC_64
flag in
-.IR cmd .)
+.IR op .)
.P
In some earlier versions of glibc, the
.I semun
diff --git a/man2/shmctl.2 b/man2/shmctl.2
index d13240647..986268957 100644
--- a/man2/shmctl.2
+++ b/man2/shmctl.2
@@ -34,12 +34,12 @@ .SH SYNOPSIS
.nf
.B #include <sys/shm.h>
.P
-.BI "int shmctl(int " shmid ", int " cmd ", struct shmid_ds *" buf );
+.BI "int shmctl(int " shmid ", int " op ", struct shmid_ds *" buf );
.fi
.SH DESCRIPTION
.BR shmctl ()
performs the control operation specified by
-.I cmd
+.I op
on the System\ V shared memory segment whose identifier is given in
.IR shmid .
.P
@@ -153,7 +153,7 @@ .SH DESCRIPTION
flag.)
.P
Valid values for
-.I cmd
+.I op
are:
.TP
.B IPC_STAT
@@ -309,7 +309,9 @@ .SH DESCRIPTION
to obtain the same information).
.P
The caller can prevent or allow swapping of a shared
-memory segment with the following \fIcmd\fP values:
+memory segment with the following
+.I op
+values:
.TP
.BR SHM_LOCK " (Linux-specific)"
Prevent swapping of the shared memory segment.
@@ -379,7 +381,7 @@ .SH ERRORS
.TP
.B EFAULT
The argument
-.I cmd
+.I op
has value
.B IPC_SET
or
@@ -392,8 +394,10 @@ .SH ERRORS
\fIshmid\fP points to a removed identifier.
.TP
.B EINVAL
-\fIshmid\fP is not a valid identifier, or \fIcmd\fP
-is not a valid command.
+.I shmid
+is not a valid identifier, or
+.I op
+is not a valid operation.
Or: for a
.B SHM_STAT
or
@@ -468,7 +472,7 @@ .SH HISTORY
(The kernel distinguishes old and new calls by an
.B IPC_64
flag in
-.IR cmd .)
+.IR op .)
.SH NOTES
The
.BR IPC_INFO ,
diff --git a/man3/lockf.3 b/man3/lockf.3
index accf8e771..7267587c4 100644
--- a/man3/lockf.3
+++ b/man3/lockf.3
@@ -17,7 +17,7 @@ .SH SYNOPSIS
.nf
.B #include <unistd.h>
.P
-.BI "int lockf(int " fd ", int " cmd ", off_t " len );
+.BI "int lockf(int " fd ", int " op ", off_t " len );
.fi
.P
.RS -4
@@ -37,7 +37,7 @@ .SH DESCRIPTION
The file is specified by
.IR fd ,
a file descriptor open for writing, the action by
-.IR cmd ,
+.IR op ,
and the section consists of byte positions
.IR pos .. pos + len \-1
if
@@ -118,7 +118,7 @@ .SH ERRORS
.B EBADF
.I fd
is not an open file descriptor; or
-.I cmd
+.I op
is
.B F_LOCK
or
@@ -128,7 +128,8 @@ .SH ERRORS
is not a writable file descriptor.
.TP
.B EDEADLK
-The command was
+.I op
+was
.B F_LOCK
and this lock operation would cause a deadlock.
.TP
@@ -139,7 +140,7 @@ .SH ERRORS
.TP
.B EINVAL
An invalid operation was specified in
-.IR cmd .
+.IR op .
.TP
.B ENOLCK
Too many segment locks open, lock table is full.
--
2.43.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 0/2] Use terms consistently in function parameter names.
From: Alejandro Colomar @ 2024-03-03 12:15 UTC (permalink / raw)
To: Elliott Hughes, Stefan Puiu, Bruno Haible, linux-man
Cc: Alejandro Colomar, GNU C Library, linux-api
In-Reply-To: <ZUIlirG-ypudgpbK@debian>
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
Hi!
I finally wrote this patch. I had it in my todo for too long.
In <time.h> functions, use duration, instead of request, as suggested by
Elliott.
In ctl functions and similar, there was a lot of variation:
- command
- cmd
- request
- req
- option
- operation
- op
And they all meant the same thing. We have similar problems in the
names of the constants, which have similar variability.
In the case of the function parameters, we can easily rename them. I
chose 'op', as it seems a reasonable (and short) name, and most of the
documentation already used the term 'operation' to refer to the
parameter, even in cases where the parameter was names differently.
I would like to ask to kernel maintainers and libc implementations to
add some consistency here too, and rename the parameters accordingly,
for consistency, or at least use your own consistency, if you don't like
this one, but stick to some rules.
In the case of constants, we can't rename them. Too bad. But I'd like
to ask programmers to have this in mind for when new constants are
added, so that some consistency is followed. (This was something that
made me doubt about using 'op', because most constants seem to use
'_CMD_' in their names. If you prefer 'cmd' for the parameter names for
that reason, let's discuss it.)
Have a lovely day!
Alex
Alejandro Colomar (2):
man*/: epoll_*(), fcntl(), flock(), ioctl(), msgctl(), *prctl(),
ptrace(), quotactl(), reboot(), semctl(), shmctl(), lockf():
Consistently use 'op' and 'operation'
clock_nanosleep.2, nanosleep.2: Use 'duration' rather than 'request'
man2/arch_prctl.2 | 12 +++---
man2/clock_nanosleep.2 | 20 ++++-----
man2/epoll_wait.2 | 4 +-
man2/fcntl.2 | 70 +++++++++++++++----------------
man2/flock.2 | 6 +--
man2/ioctl.2 | 30 +++++++-------
man2/ioctl_console.2 | 8 ++--
man2/ioctl_fideduperange.2 | 2 +-
man2/ioctl_getfsmap.2 | 6 +--
man2/ioctl_ns.2 | 2 +-
man2/ioctl_tty.2 | 10 ++---
man2/ioctl_userfaultfd.2 | 10 ++---
man2/msgctl.2 | 16 ++++----
man2/nanosleep.2 | 12 +++---
man2/prctl.2 | 84 +++++++++++++++++++-------------------
man2/ptrace.2 | 60 +++++++++++++--------------
man2/quotactl.2 | 34 +++++++--------
man2/reboot.2 | 19 +++++----
man2/semctl.2 | 22 +++++-----
man2/shmctl.2 | 20 +++++----
man3/lockf.3 | 11 ++---
21 files changed, 233 insertions(+), 225 deletions(-)
--
2.43.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V4 3/5] misc: mlx5ctl: Add info ioctl
From: Saeed Mahameed @ 2024-03-02 8:03 UTC (permalink / raw)
To: Vegard Nossum
Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-api, Linux Documentation,
Leon Romanovsky, Jason Gunthorpe, Jiri Pirko, Leonid Bloch,
Itay Avraham, Jakub Kicinski, Saeed Mahameed, David Ahern,
Aron Silverton, Christoph Hellwig, andrew.gospodarek,
linux-kernel
In-Reply-To: <bb259840-35b6-4483-8e76-8046cae1269b@oracle.com>
On 29 Feb 12:47, Vegard Nossum wrote:
>
>On 07/02/2024 08:24, Saeed Mahameed wrote:
>>+static int mlx5ctl_info_ioctl(struct file *file,
>>+ struct mlx5ctl_info __user *arg,
>>+ size_t usize)
>>+{
>>+ struct mlx5ctl_fd *mfd = file->private_data;
>>+ size_t ksize = sizeof(struct mlx5ctl_info);
>>+ struct mlx5ctl_dev *mcdev = mfd->mcdev;
>>+ struct mlx5_core_dev *mdev = mcdev->mdev;
>>+ struct mlx5ctl_info *info;
>>+ int err = 0;
>>+
>>+ if (usize < ksize)
>>+ return -EINVAL;
>>+
>>+ info = kzalloc(ksize, GFP_KERNEL);
>>+ if (!info)
>>+ return -ENOMEM;
>
>struct mlx5ctl_info is small, why not put it on the stack or even copy
>it directly from the original object, assuming it has no holes/padding?
>
There's no original object, but yes storing it on the stack should work.
>>+
>>+ info->dev_uctx_cap = MLX5_CAP_GEN(mdev, uctx_cap);
>>+ info->uctx_cap = mfd->uctx_cap;
>>+ info->uctx_uid = mfd->uctx_uid;
>>+ info->ucap = mfd->ucap;
>>+
>>+ if (copy_to_user(arg, info, ksize))
>>+ err = -EFAULT;
>>+
>>+ kfree(info);
>>+ return err;
>>+}
>
>Is there even a remote possibility of extending this structure in the
>future? If so the size check will not allow you to be backwards
>compatible. Should there be a version field in there or would you
>just add a new ioctl altogether? Adding linux-api@vger.kernel.org to Cc.
>
This was my original implementation, but Greg's preference is to allow no
extension to the ioctl structures, in case of extension required, new IOCTL
and structure should be introduced.
>>diff --git a/include/uapi/misc/mlx5ctl.h b/include/uapi/misc/mlx5ctl.h
>>new file mode 100644
>>index 000000000000..9be944128025
>>--- /dev/null
>>+++ b/include/uapi/misc/mlx5ctl.h
>>@@ -0,0 +1,20 @@
>>+/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0 WITH Linux-syscall-note */
>>+/* Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. */
>>+
>>+#ifndef __MLX5CTL_IOCTL_H__
>>+#define __MLX5CTL_IOCTL_H__
>>+
>>+struct mlx5ctl_info {
>>+ __u16 uctx_uid; /* current process allocated UCTX UID */
>>+ __u16 reserved1; /* explicit padding must be zero */
>>+ __u32 uctx_cap; /* current process effective UCTX cap */
>>+ __u32 dev_uctx_cap; /* device's UCTX capabilities */
>>+ __u32 ucap; /* process user capability */
>>+};
>>+
>>+#define MLX5CTL_IOCTL_MAGIC 0x5c
>>+
>>+#define MLX5CTL_IOCTL_INFO \
>>+ _IOR(MLX5CTL_IOCTL_MAGIC, 0x0, struct mlx5ctl_info)
>>+
>>+#endif /* __MLX5CTL_IOCTL_H__ */
>
>Should you add anything to Documentation/ABI/ ? (Or add other
>documentation for this driver?)
>
The driver doesn't expose any sysfs other than the IOCTLs, but yes
a documentation might be useful to make sure ABI is stable, most of the
other drivers point out to the uapi header for documentation.
^ permalink raw reply
* Re: [PATCH V4 3/5] misc: mlx5ctl: Add info ioctl
From: Vegard Nossum @ 2024-02-29 11:47 UTC (permalink / raw)
To: Saeed Mahameed, Arnd Bergmann, Greg Kroah-Hartman, linux-api,
Linux Documentation
Cc: Leon Romanovsky, Jason Gunthorpe, Jiri Pirko, Leonid Bloch,
Itay Avraham, Jakub Kicinski, Saeed Mahameed, David Ahern,
Aron Silverton, Christoph Hellwig, andrew.gospodarek,
linux-kernel
In-Reply-To: <20240207072435.14182-4-saeed@kernel.org>
On 07/02/2024 08:24, Saeed Mahameed wrote:
> +static int mlx5ctl_info_ioctl(struct file *file,
> + struct mlx5ctl_info __user *arg,
> + size_t usize)
> +{
> + struct mlx5ctl_fd *mfd = file->private_data;
> + size_t ksize = sizeof(struct mlx5ctl_info);
> + struct mlx5ctl_dev *mcdev = mfd->mcdev;
> + struct mlx5_core_dev *mdev = mcdev->mdev;
> + struct mlx5ctl_info *info;
> + int err = 0;
> +
> + if (usize < ksize)
> + return -EINVAL;
> +
> + info = kzalloc(ksize, GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
struct mlx5ctl_info is small, why not put it on the stack or even copy
it directly from the original object, assuming it has no holes/padding?
> +
> + info->dev_uctx_cap = MLX5_CAP_GEN(mdev, uctx_cap);
> + info->uctx_cap = mfd->uctx_cap;
> + info->uctx_uid = mfd->uctx_uid;
> + info->ucap = mfd->ucap;
> +
> + if (copy_to_user(arg, info, ksize))
> + err = -EFAULT;
> +
> + kfree(info);
> + return err;
> +}
Is there even a remote possibility of extending this structure in the
future? If so the size check will not allow you to be backwards
compatible. Should there be a version field in there or would you
just add a new ioctl altogether? Adding linux-api@vger.kernel.org to Cc.
> diff --git a/include/uapi/misc/mlx5ctl.h b/include/uapi/misc/mlx5ctl.h
> new file mode 100644
> index 000000000000..9be944128025
> --- /dev/null
> +++ b/include/uapi/misc/mlx5ctl.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0 WITH Linux-syscall-note */
> +/* Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. */
> +
> +#ifndef __MLX5CTL_IOCTL_H__
> +#define __MLX5CTL_IOCTL_H__
> +
> +struct mlx5ctl_info {
> + __u16 uctx_uid; /* current process allocated UCTX UID */
> + __u16 reserved1; /* explicit padding must be zero */
> + __u32 uctx_cap; /* current process effective UCTX cap */
> + __u32 dev_uctx_cap; /* device's UCTX capabilities */
> + __u32 ucap; /* process user capability */
> +};
> +
> +#define MLX5CTL_IOCTL_MAGIC 0x5c
> +
> +#define MLX5CTL_IOCTL_INFO \
> + _IOR(MLX5CTL_IOCTL_MAGIC, 0x0, struct mlx5ctl_info)
> +
> +#endif /* __MLX5CTL_IOCTL_H__ */
Should you add anything to Documentation/ABI/ ? (Or add other
documentation for this driver?)
Vegard
^ permalink raw reply
* Re: [PATCH 00/30] RSEQ node id and mm concurrency id extensions
From: Marco Elver @ 2024-02-29 9:31 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Peter Zijlstra, linux-kernel, Thomas Gleixner, Paul E . McKenney,
Boqun Feng, H . Peter Anvin, Paul Turner, linux-api,
Christian Brauner, Florian Weimer, David.Laight, carlos,
Peter Oskolkov, Alexander Mikhalitsyn, Chris Kennelly, dvyukov
In-Reply-To: <ed828ce7-2046-4884-ab1f-d7bff3c0a714@efficios.com>
On Wed, 28 Feb 2024 at 21:01, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
[...]
> AFAIK the only project using the mm_cid concept I know of today is
> tcmalloc. It's very useful to scale data structures such as memory
> allocator arenas to the number of concurrently running threads
> within a process without having to rely on heuristics on the
> user-space side.
>
> I have plans to migrate LTTng-UST to per-ipc-namespace NUMA-aware
> mm_cid as well (after I get around to submit this extension into the
> Linux kernel) for user-space ring buffers over shared memory, but my
> current focus has been on pushing support for extensible RSEQ into
> GNU libc for the past year or so.
>
> We are getting there though:
>
> https://sourceware.org/pipermail/libc-alpha/2024-February/154390.html
Glad to see this!
> Once we have this key piece in place within GNU libc, it will become
> easier to extend rseq further because the libc will adapt to the extended
> feature set.
>
> Note that the overhead of the mm_cid assignment within the scheduler
> should be negligible after
> commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid").
>
> Another thing we've actively been working on is to get the "librseq"
> project [1] in shape so a copy the librseq headers can be integrated
> into the GNU libc project as internal header files. So basically
> librseq will become a GNU libc upstream. This will facilitate
> implementation of rseq critical section within GNU libc. One of
> the possible use-cases will be to move the GNU libc malloc
> implementation to per-mm_cid arenas.
I suppose if GNU libc malloc starts using it then usage would become
ubiquitous in no time.
> > I'm aware that TCMalloc was the inspiration for vCPUs [1], then renamed to
> > CIDs, but am wondering if other users are out there.
>
> I'd be curious to learn about those as well.
>
> I suspect that the lack of official release of librseq critical section
> helper headers may contribute to the fact that few applications use advanced
> rseq features at this point.
I guess you've answered my question, and I conclude "no known open
source usage yet". A simple search on Github or the likes also didn't
yield anything. I will go and check again in a year or so. ;-)
Thanks,
-- Marco
^ permalink raw reply
* Re: [PATCH 00/30] RSEQ node id and mm concurrency id extensions
From: Mathieu Desnoyers @ 2024-02-28 20:01 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, linux-kernel, Thomas Gleixner, Paul E . McKenney,
Boqun Feng, H . Peter Anvin, Paul Turner, linux-api,
Christian Brauner, Florian Weimer, David.Laight, carlos,
Peter Oskolkov, Alexander Mikhalitsyn, Chris Kennelly, dvyukov
In-Reply-To: <Zd-AfDcQ-r04CMXk@elver.google.com>
On 2024-02-28 13:50, Marco Elver wrote:
> Hi Mathieu, all,
>
> On Tue, Nov 22, 2022 at 03:39PM -0500, Mathieu Desnoyers wrote:
>> Extend the rseq ABI to expose NUMA node ID, mm_cid, and mm_numa_cid
>> fields.
>>
>> The NUMA node ID field allows implementing a faster getcpu(2) in libc.
>>
>> The per-memory-map concurrency id (mm_cid) [1] allows ideal scaling
>> (down or up) of user-space per-cpu data structures. The concurrency ids
>> allocated within a memory map are tracked by the scheduler, which takes
>> into account the number of concurrently running threads, thus implicitly
>> considering the number of threads, the cpu affinity, the cpusets
>> applying to those threads, and the number of logical cores on the
>> system.
>>
>> The NUMA-aware concurrency id (mm_numa_cid) is similar to the mm_cid,
>> except that it keeps track of the NUMA node ids with which each cid has
>> been associated. On NUMA systems, when a NUMA-aware concurrency ID is
>> observed by user-space to be associated with a NUMA node, it is
>> guaranteed to never change NUMA node unless a kernel-level NUMA
>> configuration change happens. This is useful for NUMA-aware per-cpu data
>> structures running in environments where a process or a set of processes
>> belonging to cpuset are pinned to a set of cores which belong to a
>> subset of the system's NUMA nodes.
> [...]
>
> Just out of curiosity: is anyone aware of any libraries that have
> started using CIDs? It looks like the cost of CID assignment is always
> paid (even though it should be small), I'm trying to understand if after
> 1.5 years there are common libraries that have started using it and what
> their exact usecase is.
Hi Marco,
AFAIK the only project using the mm_cid concept I know of today is
tcmalloc. It's very useful to scale data structures such as memory
allocator arenas to the number of concurrently running threads
within a process without having to rely on heuristics on the
user-space side.
I have plans to migrate LTTng-UST to per-ipc-namespace NUMA-aware
mm_cid as well (after I get around to submit this extension into the
Linux kernel) for user-space ring buffers over shared memory, but my
current focus has been on pushing support for extensible RSEQ into
GNU libc for the past year or so.
We are getting there though:
https://sourceware.org/pipermail/libc-alpha/2024-February/154390.html
Once we have this key piece in place within GNU libc, it will become
easier to extend rseq further because the libc will adapt to the extended
feature set.
Note that the overhead of the mm_cid assignment within the scheduler
should be negligible after
commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid").
Another thing we've actively been working on is to get the "librseq"
project [1] in shape so a copy the librseq headers can be integrated
into the GNU libc project as internal header files. So basically
librseq will become a GNU libc upstream. This will facilitate
implementation of rseq critical section within GNU libc. One of
the possible use-cases will be to move the GNU libc malloc
implementation to per-mm_cid arenas.
>
> I'm aware that TCMalloc was the inspiration for vCPUs [1], then renamed to
> CIDs, but am wondering if other users are out there.
I'd be curious to learn about those as well.
I suspect that the lack of official release of librseq critical section
helper headers may contribute to the fact that few applications use advanced
rseq features at this point.
Thanks,
Mathieu
[1] https://git.kernel.org/pub/scm/libs/librseq/librseq.git/
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: The sk_err mechanism is infuriating in userspace
From: Andy Lutomirski @ 2024-02-28 20:00 UTC (permalink / raw)
To: Paolo Abeni, David S. Miller, Jakub Kicinski
Cc: Network Development, Linux API
In-Reply-To: <CALCETrUZuhvR3GygBfyfLxeas+igNe51Tnx=HEnh9LoFutN-dQ@mail.gmail.com>
On Tue, Feb 6, 2024 at 9:24 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
> On Tue, Feb 6, 2024 at 12:43 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > What about 'destination/port unreachable' and many other similar errors
> > reported by sk_err? Which specific errors reported by sk_err does not
> > indicate that anything is wrong with the socket ?
I started writing a series to improve this in a backwards-compatible
way, but now I'm wondering whether the current behavior may be
partially a regression and not actually something well-enshrined in
history.
The nasty behavior in question is that, if a UDP or ping (or
presumably TCP, but that case is not necessarily a problem) socket
enables IP_RECVERR, then an ICMP error will asynchronously cause the
next sendmsg() to fail. The code that causes this seems to be ancient
(I think it's sock_wait_for_wmem, which predates git, but I won't
swear to that)
Looking at my own logs, though, a Linux 4.5.2 did not seem to
regularly trigger this, and I'm getting it on a regular basis on 6.2
and some newer kernels. And, somewhat damningly (with IP addresses
redacted):
$ traceroute -I 10.1.2.3
traceroute to 10.1.2.3 (10.1.2.3), 30 hops max, 60 byte packets
1 * * *
2 10.5.6.7 (10.5.6.7) 0.593 ms 0.793 ms 0.988 ms
3 10.8.9.10 (10.8.9.10) 1.247 ms 1.547 ms 1.881 ms
4 10.11.12.13 (10.11.12.13) 1.032 ms 1.333 ms 1.679 ms
send: No route to host
Whoops, traceroute is getting a bogus return when it sends a packet,
causing it to give up. The real trace should be longer.
So I'm wondering if maybe this behavior should be seen as a bug to be
fixed and not a weird old API that needs to be preserved.
--Andy
^ permalink raw reply
* Re: [PATCH 00/30] RSEQ node id and mm concurrency id extensions
From: Marco Elver @ 2024-02-28 18:50 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Peter Zijlstra, linux-kernel, Thomas Gleixner, Paul E . McKenney,
Boqun Feng, H . Peter Anvin, Paul Turner, linux-api,
Christian Brauner, Florian Weimer, David.Laight, carlos,
Peter Oskolkov, Alexander Mikhalitsyn, Chris Kennelly, dvyukov
In-Reply-To: <20221122203932.231377-1-mathieu.desnoyers@efficios.com>
Hi Mathieu, all,
On Tue, Nov 22, 2022 at 03:39PM -0500, Mathieu Desnoyers wrote:
> Extend the rseq ABI to expose NUMA node ID, mm_cid, and mm_numa_cid
> fields.
>
> The NUMA node ID field allows implementing a faster getcpu(2) in libc.
>
> The per-memory-map concurrency id (mm_cid) [1] allows ideal scaling
> (down or up) of user-space per-cpu data structures. The concurrency ids
> allocated within a memory map are tracked by the scheduler, which takes
> into account the number of concurrently running threads, thus implicitly
> considering the number of threads, the cpu affinity, the cpusets
> applying to those threads, and the number of logical cores on the
> system.
>
> The NUMA-aware concurrency id (mm_numa_cid) is similar to the mm_cid,
> except that it keeps track of the NUMA node ids with which each cid has
> been associated. On NUMA systems, when a NUMA-aware concurrency ID is
> observed by user-space to be associated with a NUMA node, it is
> guaranteed to never change NUMA node unless a kernel-level NUMA
> configuration change happens. This is useful for NUMA-aware per-cpu data
> structures running in environments where a process or a set of processes
> belonging to cpuset are pinned to a set of cores which belong to a
> subset of the system's NUMA nodes.
[...]
Just out of curiosity: is anyone aware of any libraries that have
started using CIDs? It looks like the cost of CID assignment is always
paid (even though it should be small), I'm trying to understand if after
1.5 years there are common libraries that have started using it and what
their exact usecase is.
I'm aware that TCMalloc was the inspiration for vCPUs [1], then renamed to
CIDs, but am wondering if other users are out there.
Thanks,
-- Marco
[1] https://lore.kernel.org/lkml/20220218210633.23345-10-mathieu.desnoyers@efficios.com/
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] sticon: Allow to get max font width and height
From: Alexey Gladkov @ 2024-02-27 14:06 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: LKML, Jiri Slaby, linux-api
In-Reply-To: <2024022755-viewable-breeding-0bff@gregkh>
On Tue, Feb 27, 2024 at 06:52:17AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 26, 2024 at 04:21:12PM +0100, Alexey Gladkov wrote:
> > Signed-off-by: Alexey Gladkov <legion@kernel.org>
>
> For obvious reasons, I can't take patches without any changelog text at
> all, and you don't want me to :(
It's just an RFC. I'm not sure if this is the best solution or if I added
the new ioctl correctly.
If you think that this approach is acceptable, then I will send a proper
patches.
--
Rgrds, legion
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] sticon: Allow to get max font width and height
From: Greg Kroah-Hartman @ 2024-02-27 5:52 UTC (permalink / raw)
To: Alexey Gladkov; +Cc: LKML, Jiri Slaby, linux-api
In-Reply-To: <07c0cb7f0c175460561957190e48a6e01a74a676.1708960303.git.legion@kernel.org>
On Mon, Feb 26, 2024 at 04:21:12PM +0100, Alexey Gladkov wrote:
> Signed-off-by: Alexey Gladkov <legion@kernel.org>
For obvious reasons, I can't take patches without any changelog text at
all, and you don't want me to :(
thanks,
greg k-h
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: WANG Xuerui @ 2024-02-26 17:38 UTC (permalink / raw)
To: Christian Brauner
Cc: Arnd Bergmann, Xi Ruoyao, Icenowy Zheng, Huacai Chen, linux-api,
Kees Cook, Xuefeng Li, Jianmin Lv, Xiaotian Wu, WANG Rui,
Miao Wang, loongarch@lists.linux.dev, Linux-Arch,
Linux Kernel Mailing List
In-Reply-To: <20240226-altmodisch-gedeutet-91c5ba2f6071@brauner>
On 2/26/24 23:35, Christian Brauner wrote:
> On Mon, Feb 26, 2024 at 10:00:05PM +0800, WANG Xuerui wrote:
>> On 2/26/24 21:32, Christian Brauner wrote:
>>> On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
>>>> On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
>>>>> On Mon, 2024-02-26 at 07:56 +0100, Arnd Bergmann wrote:
>>>>>> On Mon, Feb 26, 2024, at 07:03, Icenowy Zheng wrote:
>>>>>>> 在 2024-02-25星期日的 15:32 +0800，Xi Ruoyao写道：
>>>>>>>> On Sun, 2024-02-25 at 14:51 +0800, Icenowy Zheng wrote:
>>>>>>>>> My idea is this problem needs syscalls to be designed with deep
>>>>>>>>> argument inspection in mind; syscalls before this should be
>>>>>>>>> considered
>>>>>>>>> as historical error and get fixed by resotring old syscalls.
>>>>>>>> I'd not consider fstat an error as using statx for fstat has a
>>>>>>>> performance impact (severe for some workflows), and Linus has
>>>>>>>> concluded
>>>>>>> Sorry for clearance, I mean statx is an error in ABI design, not fstat.
>>>>> I'm wondering why we decided to use AT_EMPTY_PATH/"" instead of
>>>>> "AT_NULL_PATH"/nullptr in the first place?
>>>> Not sure, but it's hard to change now since the libc
>>>> implementation won't easily know whether using the NULL
>>>> path is safe on a given kernel. It could check the kernel
>>>> version number, but that adds another bit of complexity in
>>>> the fast path and doesn't work on old kernels with the
>>>> feature backported.
>>>>
>>>>> But it's not irrational to pass a path to syscall, as long as we still
>>>>> have the concept of file system (maybe in 2371 or some year we'll use a
>>>>> 128-bit UUID instead of path).
>>>>>
>>>>>> The problem I see with the 'use use fstat' approach is that this
>>>>>> does not work on 32-bit architectures, unless we define a new
>>>>>> fstatat64_time64() syscall, which is one of the things that statx()
>>>>> "fstat64_time64". Using statx for fstatat should be just fine.
>>>> Right. It does feel wrong to have only an fstat() variant but not
>>>> fstatat() if we go there.
>>>>
>>>>> Or maybe we can just introduce a new AT_something to make statx
>>>>> completely ignore pathname but behave like AT_EMPTY_PATH + "".
>>>> I think this is better than going back to fstat64_time64(), but
>>>> it's still not great because
>>>>
>>>> - all the reserved flags on statx() are by definition incompatible
>>>> with existing kernels that return -EINVAL for any flag they do
>>>> not recognize.
>>>>
>>>> - you still need to convince libc developers to actually use
>>>> the flag despite the backwards compatibility problem, either
>>>> with a fallback to the current behavior or a version check.
>>>>
>>>> Using the NULL path as a fallback would solve the problem with
>>>> seccomp, but it would not make the normal case any faster.
>>>>
>>>>>> was trying to avoid.
>>>>> Oops. I thought "newstat" should be using 64-bit time but it seems the
>>>>> "new" is not what I'd expected... The "new" actually means "newer than
>>>>> Linux 0.9"! :(
>>>>>
>>>>> Let's not use "new" in future syscall names...
>>>> Right, we definitely can't ever succeed. On some architectures
>>>> we even had "oldstat" and "stat" before "newstat" and "stat64",
>>>> and on some architectures we mix them up. E.g. x86_64 has fstat()
>>>> and fstatat64() with the same structure but doesn't define
>>>> __NR_newfstat. On mips64, there is a 'newstat' but it has 32-bit
>>>> timestamps unlike all other 64-bit architectures.
>>>>
>>>> statx() was intended to solve these problems once and for all,
>>>> and it appears that we have failed again.
>>> New apis don't invalidate old apis necessarily. That's just not going to
>>> work in an age where you have containerized workloads.
>>>
>>> statx() is just the beginning of this. A container may have aritrary
>>> seccomp profiles that return ENOSYS or even EPERM for whatever reason
>>> for any new api that exists. So not implementing fstat() might already
>>> break container workloads.
>>>
>>> Another example: You can't just skip on implementing mount() and only
>>> implement the new mount api for example. Because tools that look for api
>>> simplicity and don't need complex setup will _always_ continue to use
>>> mount() and have a right to do so.
>>>
>>> And fwiw, mount() isn't fully inspectable by seccomp since forever. The
>>> list goes on and on.
>>>
>>> But let's look at the original mail. Why are they denying statx() and
>>> what's that claim about it not being able to be rewritten to something
>>> safe? Looking at:
>>>
>>> intptr_t SIGSYSFstatatHandler(const struct arch_seccomp_data& args,
>>> void* fs_denied_errno) {
>>> if (args.nr == __NR_fstatat_default) {
>>> if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
>>> args.args[3] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
>>> return syscall(__NR_fstat_default, static_cast<int>(args.args[0]),
>>> reinterpret_cast<default_stat_struct*>(args.args[2]));
>>> }
>>> return -reinterpret_cast<intptr_t>(fs_denied_errno);
>>> }
>>>
>>> What this does it to rewrite fstatat() to fstat() if it was made with
>>> AT_EMPTY_PATH and the path argument was "". That is easily doable for
>>> statx() because it has the exact same AT_EMPTY_PATH semantics that
>>> fstatat() has.
>>>
>>> Plus, they can even filter on mask and rewrite that to something that
>>> they think is safe. For example, STATX_BASIC_STATS which is equivalent
>>> to what any fstat() call returns. So it's pretty difficult to understand
>>> what their actual gripe with statx() is.
>>>
>>> It can't be that statx() passes a struct because fstatat() and fstat()
>>> do that too. So what exactly is that problem there?
>> From our investigation:
>>
>> For (new)fstatat calls that the sandboxed process may make, this SIGSYS
>> handler either:
>>
>> * turns allowed calls (those looking at fd's) into fstat's that only have
>> one argument (the fd) each, or
>> * denies the call,
> Yes, but look at the filtering that they do:
>
> if (args.nr == __NR_fstatat_default) {
> if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
> args.args[3] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
>
> So if you have a statx() call instead of an fstatat() call this is
> trivially:
>
> if (args.nr == __NR_statx) {
> if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
> args.args[2] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
>
> maybe if they care about it also simply check
> args.args[3] == STATX_BASIC_STATS.
>
> And then just as with fstatat() rewrite it to fstat().
But fstat() and fstatat() share the same return value type i.e. struct
stat, different from struct statx. And they are different enough that
their existing seccomp policy can distinguish. In the statx-only case
though, the seccomp policy cannot distinguish "statx actually called
with empty path" from "statx called with AT_EMPTY_PATH but non-empty
path" because in both cases the path would be a non-NULL pointer opaque
to the policy cBPF program.
>> so the sandbox only ever sees fstat calls and no (new)fstatat's, and the
>> guarantee that only open fds can ever been stat'ed trivially holds.
>>
>> With statx, however, there's no way of guaranteeing "only look at fd"
>> semantics without peeking into the path argument, because a non-empty path
>> makes AT_EMPTY_PATH ineffective, and the flags are not validated prior to
>> use making it near-impossible to introduce new semantics in a
>> backwards-compatible manner.
> I don't understand. That's exactly the same thing as for fstatat(). My
> point is that you can turn statx() into fstat() just like you can turn
> fstatat() into fstat(). So if you add fstat()/fstat64() what's left to
> do?
Yes, once fstat is restored it's a matter of transforming every allowed
statx into fstat, then translating struct stat back into struct statx.
What we're seeking is a possible way forward without re-introducing that
though, because we still have some time and don't have to rush.
>>> What this tells me without knowing the exact reason is that they thought
>>> "Oh, if we just return ENOSYS then the workload or glibc will just
>>> always be able to fallback to fstat() or fstatat()". Which ultimately is
>>> the exact same thing that containers often assume.
>>>
>>> So really, just skipping on various system calls isn't going to work.
>>> You can't just implement new system calls and forget about the rest
>>> unless you know exactly what workloads your architecure will run on.
>>>
>>> Please implement fstat() or fstatat() and stop inventing hacks for
>>> statx() to make weird sandboxing rules work, please.
>> We have already provided fstat(at) on LoongArch for a while by
>> unconditionally doing statx and translating the returned structure -- see
>> the [glibc] and [golang] [golang-2] implementations for example -- without
> But you're doing that translation in userspace. I was talking about
> adding the fstat()/fstat64() system calls.
Hmm, yeah. I meant to provide some more context but I later realized
that the sandbox is in charge of rewriting the syscalls from inside the
sandbox, so the userland may not matter in the big picture after all.
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: Xi Ruoyao @ 2024-02-26 16:49 UTC (permalink / raw)
To: Christian Brauner, Arnd Bergmann
Cc: Icenowy Zheng, Huacai Chen, WANG Xuerui, linux-api, Kees Cook,
Xuefeng Li, Jianmin Lv, Xiaotian Wu, WANG Rui, Miao Wang,
loongarch@lists.linux.dev, Linux-Arch, Linux Kernel Mailing List
In-Reply-To: <20240226-sandbank-bewerben-219120323e29@brauner>
On Mon, 2024-02-26 at 16:40 +0100, Christian Brauner wrote:
> > I definitely don't want to see a new time32 API added to
> > mips64 and the 32-bit architectures, so the existing stat64
> > interface won't work as a statx replacement.
>
> I don't specifically care but the same way you don't want to see newer
> time32 apis added to architectures I don't want to have hacks in our
> system calls that aren't even a clear solution to the problem outlined
> in this thread.
So we should have a fstat_whatever64, IMO.
> Short of adding fstatx() the problem isn't solved by a new flag to
> statx() as explained in my other mails. But I'm probably missing
> something here because I find this notion of "design system calls for
> seccomp and the Chromium sandbox" to be an absurd notion and it makes me
> a bit impatient.
I'm sharing the feeling on seccomp and/or (mis)uses of it, but using
statx() or fstatat() for fstat() has a performance impact as they must
inspect path (do a uaccess) and make sure it's an empty string, and
Linus concluded "if the user want fstat, you should give the user fstat"
for this issue:
https://sourceware.org/pipermail/libc-alpha/2023-September/151365.html
If it was just seccomp I'd not comment on this topic at all.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: Christian Brauner @ 2024-02-26 15:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Xi Ruoyao, Icenowy Zheng, Huacai Chen, WANG Xuerui, linux-api,
Kees Cook, Xuefeng Li, Jianmin Lv, Xiaotian Wu, WANG Rui,
Miao Wang, loongarch@lists.linux.dev, Linux-Arch,
Linux Kernel Mailing List
In-Reply-To: <ef732971-bf70-4d8c-9fe8-3ca163a0c29c@app.fastmail.com>
On Mon, Feb 26, 2024 at 02:46:49PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 26, 2024, at 14:32, Christian Brauner wrote:
> > On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
> >> On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
> >
> > What this tells me without knowing the exact reason is that they thought
> > "Oh, if we just return ENOSYS then the workload or glibc will just
> > always be able to fallback to fstat() or fstatat()". Which ultimately is
> > the exact same thing that containers often assume.
> >
> > So really, just skipping on various system calls isn't going to work.
> > You can't just implement new system calls and forget about the rest
> > unless you know exactly what workloads your architecure will run on.
> >
> > Please implement fstat() or fstatat() and stop inventing hacks for
> > statx() to make weird sandboxing rules work, please.
>
> Do you mean we should add fstat64_time64() for all architectures
> then? Would use use the same structure layout as statx for this,
> the 64-bit version of the 'struct stat' layout from
> include/uapi/asm-generic/stat.h, or something new that solves
> the same problems?
>
> I definitely don't want to see a new time32 API added to
> mips64 and the 32-bit architectures, so the existing stat64
> interface won't work as a statx replacement.
I don't specifically care but the same way you don't want to see newer
time32 apis added to architectures I don't want to have hacks in our
system calls that aren't even a clear solution to the problem outlined
in this thread.
Short of adding fstatx() the problem isn't solved by a new flag to
statx() as explained in my other mails. But I'm probably missing
something here because I find this notion of "design system calls for
seccomp and the Chromium sandbox" to be an absurd notion and it makes me
a bit impatient.
And fwiw, once mseal() lands seccomp should be a lot easier to get deep
argument inspection.
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: Christian Brauner @ 2024-02-26 15:35 UTC (permalink / raw)
To: WANG Xuerui
Cc: Arnd Bergmann, Xi Ruoyao, Icenowy Zheng, Huacai Chen, linux-api,
Kees Cook, Xuefeng Li, Jianmin Lv, Xiaotian Wu, WANG Rui,
Miao Wang, loongarch@lists.linux.dev, Linux-Arch,
Linux Kernel Mailing List
In-Reply-To: <7641391a-b109-49b3-84c8-7e72053210d8@xen0n.name>
On Mon, Feb 26, 2024 at 10:00:05PM +0800, WANG Xuerui wrote:
> On 2/26/24 21:32, Christian Brauner wrote:
> > On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
> > > On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
> > > > On Mon, 2024-02-26 at 07:56 +0100, Arnd Bergmann wrote:
> > > > > On Mon, Feb 26, 2024, at 07:03, Icenowy Zheng wrote:
> > > > > > 在 2024-02-25星期日的 15:32 +0800，Xi Ruoyao写道：
> > > > > > > On Sun, 2024-02-25 at 14:51 +0800, Icenowy Zheng wrote:
> > > > > > > > My idea is this problem needs syscalls to be designed with deep
> > > > > > > > argument inspection in mind; syscalls before this should be
> > > > > > > > considered
> > > > > > > > as historical error and get fixed by resotring old syscalls.
> > > > > > >
> > > > > > > I'd not consider fstat an error as using statx for fstat has a
> > > > > > > performance impact (severe for some workflows), and Linus has
> > > > > > > concluded
> > > > > >
> > > > > > Sorry for clearance, I mean statx is an error in ABI design, not fstat.
> > > >
> > > > I'm wondering why we decided to use AT_EMPTY_PATH/"" instead of
> > > > "AT_NULL_PATH"/nullptr in the first place?
> > >
> > > Not sure, but it's hard to change now since the libc
> > > implementation won't easily know whether using the NULL
> > > path is safe on a given kernel. It could check the kernel
> > > version number, but that adds another bit of complexity in
> > > the fast path and doesn't work on old kernels with the
> > > feature backported.
> > >
> > > > But it's not irrational to pass a path to syscall, as long as we still
> > > > have the concept of file system (maybe in 2371 or some year we'll use a
> > > > 128-bit UUID instead of path).
> > > >
> > > > > The problem I see with the 'use use fstat' approach is that this
> > > > > does not work on 32-bit architectures, unless we define a new
> > > > > fstatat64_time64() syscall, which is one of the things that statx()
> > > >
> > > > "fstat64_time64". Using statx for fstatat should be just fine.
> > >
> > > Right. It does feel wrong to have only an fstat() variant but not
> > > fstatat() if we go there.
> > >
> > > > Or maybe we can just introduce a new AT_something to make statx
> > > > completely ignore pathname but behave like AT_EMPTY_PATH + "".
> > >
> > > I think this is better than going back to fstat64_time64(), but
> > > it's still not great because
> > >
> > > - all the reserved flags on statx() are by definition incompatible
> > > with existing kernels that return -EINVAL for any flag they do
> > > not recognize.
> > >
> > > - you still need to convince libc developers to actually use
> > > the flag despite the backwards compatibility problem, either
> > > with a fallback to the current behavior or a version check.
> > >
> > > Using the NULL path as a fallback would solve the problem with
> > > seccomp, but it would not make the normal case any faster.
> > >
> > > > > was trying to avoid.
> > > >
> > > > Oops. I thought "newstat" should be using 64-bit time but it seems the
> > > > "new" is not what I'd expected... The "new" actually means "newer than
> > > > Linux 0.9"! :(
> > > >
> > > > Let's not use "new" in future syscall names...
> > >
> > > Right, we definitely can't ever succeed. On some architectures
> > > we even had "oldstat" and "stat" before "newstat" and "stat64",
> > > and on some architectures we mix them up. E.g. x86_64 has fstat()
> > > and fstatat64() with the same structure but doesn't define
> > > __NR_newfstat. On mips64, there is a 'newstat' but it has 32-bit
> > > timestamps unlike all other 64-bit architectures.
> > >
> > > statx() was intended to solve these problems once and for all,
> > > and it appears that we have failed again.
> >
> > New apis don't invalidate old apis necessarily. That's just not going to
> > work in an age where you have containerized workloads.
> >
> > statx() is just the beginning of this. A container may have aritrary
> > seccomp profiles that return ENOSYS or even EPERM for whatever reason
> > for any new api that exists. So not implementing fstat() might already
> > break container workloads.
> >
> > Another example: You can't just skip on implementing mount() and only
> > implement the new mount api for example. Because tools that look for api
> > simplicity and don't need complex setup will _always_ continue to use
> > mount() and have a right to do so.
> >
> > And fwiw, mount() isn't fully inspectable by seccomp since forever. The
> > list goes on and on.
> >
> > But let's look at the original mail. Why are they denying statx() and
> > what's that claim about it not being able to be rewritten to something
> > safe? Looking at:
> >
> > intptr_t SIGSYSFstatatHandler(const struct arch_seccomp_data& args,
> > void* fs_denied_errno) {
> > if (args.nr == __NR_fstatat_default) {
> > if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
> > args.args[3] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
> > return syscall(__NR_fstat_default, static_cast<int>(args.args[0]),
> > reinterpret_cast<default_stat_struct*>(args.args[2]));
> > }
> > return -reinterpret_cast<intptr_t>(fs_denied_errno);
> > }
> >
> > What this does it to rewrite fstatat() to fstat() if it was made with
> > AT_EMPTY_PATH and the path argument was "". That is easily doable for
> > statx() because it has the exact same AT_EMPTY_PATH semantics that
> > fstatat() has.
> >
> > Plus, they can even filter on mask and rewrite that to something that
> > they think is safe. For example, STATX_BASIC_STATS which is equivalent
> > to what any fstat() call returns. So it's pretty difficult to understand
> > what their actual gripe with statx() is.
> >
> > It can't be that statx() passes a struct because fstatat() and fstat()
> > do that too. So what exactly is that problem there?
>
> From our investigation:
>
> For (new)fstatat calls that the sandboxed process may make, this SIGSYS
> handler either:
>
> * turns allowed calls (those looking at fd's) into fstat's that only have
> one argument (the fd) each, or
> * denies the call,
Yes, but look at the filtering that they do:
if (args.nr == __NR_fstatat_default) {
if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
args.args[3] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
So if you have a statx() call instead of an fstatat() call this is
trivially:
if (args.nr == __NR_statx) {
if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
args.args[2] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
maybe if they care about it also simply check
args.args[3] == STATX_BASIC_STATS.
And then just as with fstatat() rewrite it to fstat().
>
> so the sandbox only ever sees fstat calls and no (new)fstatat's, and the
> guarantee that only open fds can ever been stat'ed trivially holds.
>
> With statx, however, there's no way of guaranteeing "only look at fd"
> semantics without peeking into the path argument, because a non-empty path
> makes AT_EMPTY_PATH ineffective, and the flags are not validated prior to
> use making it near-impossible to introduce new semantics in a
> backwards-compatible manner.
I don't understand. That's exactly the same thing as for fstatat(). My
point is that you can turn statx() into fstat() just like you can turn
fstatat() into fstat(). So if you add fstat()/fstat64() what's left to
do?
> > What this tells me without knowing the exact reason is that they thought
> > "Oh, if we just return ENOSYS then the workload or glibc will just
> > always be able to fallback to fstat() or fstatat()". Which ultimately is
> > the exact same thing that containers often assume.
> >
> > So really, just skipping on various system calls isn't going to work.
> > You can't just implement new system calls and forget about the rest
> > unless you know exactly what workloads your architecure will run on.
> >
> > Please implement fstat() or fstatat() and stop inventing hacks for
> > statx() to make weird sandboxing rules work, please.
>
> We have already provided fstat(at) on LoongArch for a while by
> unconditionally doing statx and translating the returned structure -- see
> the [glibc] and [golang] [golang-2] implementations for example -- without
But you're doing that translation in userspace. I was talking about
adding the fstat()/fstat64() system calls.
^ permalink raw reply
* [RFC PATCH v2 3/5] sticon: Allow to get max font width and height
From: Alexey Gladkov @ 2024-02-26 15:21 UTC (permalink / raw)
To: LKML, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-api
In-Reply-To: <cover.1708960303.git.legion@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
drivers/video/console/sticon.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/sticon.c b/drivers/video/console/sticon.c
index 992a4fa431aa..d32ca458eb77 100644
--- a/drivers/video/console/sticon.c
+++ b/drivers/video/console/sticon.c
@@ -56,6 +56,11 @@
#define BLANK 0
static int vga_is_gfx;
+#define STICON_MIN_FONT_WIDTH 6
+#define STICON_MIN_FONT_HEIGHT 6
+#define STICON_MAX_FONT_WIDTH 32
+#define STICON_MAX_FONT_HEIGHT 32
+
#define STI_DEF_FONT sticon_sti->font
/* borrowed from fbcon.c */
@@ -180,8 +185,10 @@ static int sticon_set_font(struct vc_data *vc, struct console_font *op,
struct sti_cooked_font *cooked_font;
unsigned char *data = op->data, *p;
- if ((w < 6) || (h < 6) || (w > 32) || (h > 32) || (vpitch != 32)
- || (op->charcount != 256 && op->charcount != 512))
+ if (!in_range(w, STICON_MIN_FONT_WIDTH, STICON_MAX_FONT_WIDTH) ||
+ !in_range(h, STICON_MIN_FONT_HEIGHT, STICON_MAX_FONT_HEIGHT) ||
+ (vpitch != 32) ||
+ (op->charcount != 256 && op->charcount != 512))
return -EINVAL;
pitch = ALIGN(w, 8) / 8;
bpc = pitch * h;
@@ -273,6 +280,19 @@ static int sticon_font_set(struct vc_data *vc, struct console_font *font,
return sticon_set_font(vc, font, vpitch);
}
+static int sticon_font_info(struct vc_data *vc, struct console_font_info *info)
+{
+ info->min_width = STICON_MIN_FONT_WIDTH;
+ info->min_height = STICON_MIN_FONT_HEIGHT;
+
+ info->max_width = STICON_MAX_FONT_WIDTH;
+ info->max_height = STICON_MAX_FONT_HEIGHT;
+
+ info->flags = KD_FONT_INFO_FLAG_LOW_SIZE | KD_FONT_INFO_FLAG_HIGH_SIZE;
+
+ return 0;
+}
+
static void sticon_init(struct vc_data *c, int init)
{
struct sti_struct *sti = sticon_sti;
@@ -371,6 +391,7 @@ static const struct consw sti_con = {
.con_scroll = sticon_scroll,
.con_switch = sticon_switch,
.con_blank = sticon_blank,
+ .con_font_info = sticon_font_info,
.con_font_set = sticon_font_set,
.con_font_default = sticon_font_default,
.con_build_attr = sticon_build_attr,
--
2.44.0
^ permalink raw reply related
* [RFC PATCH v2 4/5] vgacon: Allow to get max font width and height
From: Alexey Gladkov @ 2024-02-26 15:21 UTC (permalink / raw)
To: LKML, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-api
In-Reply-To: <cover.1708960303.git.legion@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
drivers/video/console/vgacon.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 8ef1579fa57f..b75d31ef3353 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -61,6 +61,10 @@ static struct vgastate vgastate;
#define BLANK 0x0020
#define VGA_FONTWIDTH 8 /* VGA does not support fontwidths != 8 */
+
+#define VGACON_MAX_FONT_WIDTH VGA_FONTWIDTH
+#define VGACON_MAX_FONT_HEIGHT 32
+
/*
* Interface used by the world
*/
@@ -1013,6 +1017,19 @@ static int vgacon_adjust_height(struct vc_data *vc, unsigned fontheight)
return 0;
}
+static int vgacon_font_info(struct vc_data *vc, struct console_font_info *info)
+{
+ info->min_width = VGACON_MAX_FONT_WIDTH;
+ info->min_height = 0;
+
+ info->max_width = VGACON_MAX_FONT_WIDTH;
+ info->max_height = VGACON_MAX_FONT_HEIGHT;
+
+ info->flags = KD_FONT_INFO_FLAG_LOW_SIZE | KD_FONT_INFO_FLAG_HIGH_SIZE;
+
+ return 0;
+}
+
static int vgacon_font_set(struct vc_data *c, struct console_font *font,
unsigned int vpitch, unsigned int flags)
{
@@ -1022,7 +1039,8 @@ static int vgacon_font_set(struct vc_data *c, struct console_font *font,
if (vga_video_type < VIDEO_TYPE_EGAM)
return -EINVAL;
- if (font->width != VGA_FONTWIDTH || font->height > 32 || vpitch != 32 ||
+ if (font->width != VGACON_MAX_FONT_WIDTH ||
+ font->height > VGACON_MAX_FONT_HEIGHT || vpitch != 32 ||
(charcount != 256 && charcount != 512))
return -EINVAL;
@@ -1177,6 +1195,7 @@ const struct consw vga_con = {
.con_scroll = vgacon_scroll,
.con_switch = vgacon_switch,
.con_blank = vgacon_blank,
+ .con_font_info = vgacon_font_info,
.con_font_set = vgacon_font_set,
.con_font_get = vgacon_font_get,
.con_resize = vgacon_resize,
--
2.44.0
^ permalink raw reply related
* [RFC PATCH v2 1/5] VT: Add KD_FONT_OP_GET_INFO operation
From: Alexey Gladkov @ 2024-02-26 15:21 UTC (permalink / raw)
To: LKML, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-api
In-Reply-To: <cover.1708960303.git.legion@kernel.org>
Each driver has its own restrictions on font size. There is currently no
way to understand what the requirements are. The new operation allows
userspace to get the maximum font size values.
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
drivers/tty/vt/vt.c | 24 ++++++++++++++++++++++++
drivers/tty/vt/vt_ioctl.c | 12 ++++++++++++
include/linux/console.h | 2 ++
include/linux/vt_kern.h | 1 +
include/uapi/linux/kd.h | 13 ++++++++++++-
5 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 156efda7c80d..8c2a3d98b5ec 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -4680,6 +4680,30 @@ int con_font_op(struct vc_data *vc, struct console_font_op *op)
return -ENOSYS;
}
+int con_font_info(struct vc_data *vc, struct console_font_info *info)
+{
+ int rc = -EINVAL;
+
+ info->min_height = 0;
+ info->max_height = max_font_height;
+
+ info->min_width = 0;
+ info->max_width = max_font_width;
+
+ info->flags = KD_FONT_INFO_FLAG_LOW_SIZE | KD_FONT_INFO_FLAG_HIGH_SIZE;
+
+ console_lock();
+ if (vc->vc_mode != KD_TEXT)
+ rc = -EINVAL;
+ else if (vc->vc_sw->con_font_info)
+ rc = vc->vc_sw->con_font_info(vc, info);
+ else
+ rc = -ENOSYS;
+ console_unlock();
+
+ return rc;
+}
+
/*
* Interface exported to selection and vcs.
*/
diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
index 8c685b501404..a5f160e15a76 100644
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -479,6 +479,18 @@ static int vt_k_ioctl(struct tty_struct *tty, unsigned int cmd,
break;
}
+ case KDFONTINFO:
+ struct console_font_info fnt_info;
+
+ if (copy_from_user(&fnt_info, up, sizeof(fnt_info)))
+ return -EFAULT;
+ ret = con_font_info(vc, &fnt_info);
+ if (ret)
+ return ret;
+ if (copy_to_user(up, &fnt_info, sizeof(fnt_info)))
+ return -EFAULT;
+ break;
+
default:
return -ENOIOCTLCMD;
}
diff --git a/include/linux/console.h b/include/linux/console.h
index 779d388af8a0..5bea6f6c2042 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -20,6 +20,7 @@
#include <linux/types.h>
struct vc_data;
+struct console_font_info;
struct console_font_op;
struct console_font;
struct module;
@@ -59,6 +60,7 @@ struct consw {
unsigned int lines);
int (*con_switch)(struct vc_data *vc);
int (*con_blank)(struct vc_data *vc, int blank, int mode_switch);
+ int (*con_font_info)(struct vc_data *vc, struct console_font_info *info);
int (*con_font_set)(struct vc_data *vc, struct console_font *font,
unsigned int vpitch, unsigned int flags);
int (*con_font_get)(struct vc_data *vc, struct console_font *font,
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index c1f5aebef170..6bda4cc1fe6f 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -32,6 +32,7 @@ void do_blank_screen(int entering_gfx);
void do_unblank_screen(int leaving_gfx);
void poke_blanked_console(void);
int con_font_op(struct vc_data *vc, struct console_font_op *op);
+int con_font_info(struct vc_data *vc, struct console_font_info *info);
int con_set_cmap(unsigned char __user *cmap);
int con_get_cmap(unsigned char __user *cmap);
void scrollback(struct vc_data *vc);
diff --git a/include/uapi/linux/kd.h b/include/uapi/linux/kd.h
index 6b384065c013..781e086e55bf 100644
--- a/include/uapi/linux/kd.h
+++ b/include/uapi/linux/kd.h
@@ -183,8 +183,19 @@ struct console_font {
#define KD_FONT_FLAG_DONT_RECALC 1 /* Don't recalculate hw charcell size [compat] */
+#define KDFONTINFO 0x4B73 /* font information */
+
+#define KD_FONT_INFO_FLAG_LOW_SIZE (1U << 0) /* 256 */
+#define KD_FONT_INFO_FLAG_HIGH_SIZE (1U << 1) /* 512 */
+
+struct console_font_info {
+ unsigned int min_width, min_height; /* minimal font size */
+ unsigned int max_width, max_height; /* maximum font size */
+ unsigned int flags; /* KD_FONT_INFO_FLAG_* */
+};
+
/* note: 0x4B00-0x4B4E all have had a value at some time;
don't reuse for the time being */
-/* note: 0x4B60-0x4B6D, 0x4B70-0x4B72 used above */
+/* note: 0x4B60-0x4B6D, 0x4B70-0x4B73 used above */
#endif /* _UAPI_LINUX_KD_H */
--
2.44.0
^ permalink raw reply related
* [RFC PATCH v2 2/5] newport_con: Allow to get max font width and height
From: Alexey Gladkov @ 2024-02-26 15:21 UTC (permalink / raw)
To: LKML, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-api
In-Reply-To: <cover.1708960303.git.legion@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
drivers/video/console/newport_con.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/video/console/newport_con.c b/drivers/video/console/newport_con.c
index e8e4f82cd4a1..87f174a95fa8 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -33,6 +33,9 @@
#define NEWPORT_LEN 0x10000
+#define NEWPORT_MAX_FONT_WIDTH 8
+#define NEWPORT_MAX_FONT_HEIGHT 16
+
#define FONT_DATA ((unsigned char *)font_vga_8x16.data)
static unsigned char *font_data[MAX_NR_CONSOLES];
@@ -328,8 +331,8 @@ static void newport_init(struct vc_data *vc, int init)
{
int cols, rows;
- cols = newport_xsize / 8;
- rows = newport_ysize / 16;
+ cols = newport_xsize / NEWPORT_MAX_FONT_WIDTH;
+ rows = newport_ysize / NEWPORT_MAX_FONT_HEIGHT;
vc->vc_can_do_color = 1;
if (init) {
vc->vc_cols = cols;
@@ -507,8 +510,8 @@ static int newport_set_font(int unit, struct console_font *op, unsigned int vpit
/* ladis: when I grow up, there will be a day... and more sizes will
* be supported ;-) */
- if ((w != 8) || (h != 16) || (vpitch != 32)
- || (op->charcount != 256 && op->charcount != 512))
+ if ((w != NEWPORT_MAX_FONT_WIDTH) || (h != NEWPORT_MAX_FONT_HEIGHT) ||
+ (vpitch != 32) || (op->charcount != 256 && op->charcount != 512))
return -EINVAL;
if (!(new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size,
@@ -569,6 +572,15 @@ static int newport_font_default(struct vc_data *vc, struct console_font *op, cha
return newport_set_def_font(vc->vc_num, op);
}
+static int newport_font_info(struct vc_data *vc, struct console_font_info *info)
+{
+ info->min_width = info->max_width = NEWPORT_MAX_FONT_WIDTH;
+ info->min_height = info->max_height = NEWPORT_MAX_FONT_HEIGHT;
+ info->flags = KD_FONT_INFO_FLAG_LOW_SIZE | KD_FONT_INFO_FLAG_HIGH_SIZE;
+
+ return 0;
+}
+
static int newport_font_set(struct vc_data *vc, struct console_font *font,
unsigned int vpitch, unsigned int flags)
{
@@ -688,6 +700,7 @@ const struct consw newport_con = {
.con_scroll = newport_scroll,
.con_switch = newport_switch,
.con_blank = newport_blank,
+ .con_font_info = newport_font_info,
.con_font_set = newport_font_set,
.con_font_default = newport_font_default,
.con_save_screen = newport_save_screen
--
2.44.0
^ permalink raw reply related
* [RFC PATCH v2 5/5] fbcon: Allow to get max font width and height
From: Alexey Gladkov @ 2024-02-26 15:21 UTC (permalink / raw)
To: LKML, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-api
In-Reply-To: <cover.1708960303.git.legion@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
drivers/video/fbdev/core/fbcon.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 1183e7a871f8..055d0d01243c 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -101,6 +101,9 @@ enum {
FBCON_LOGO_DONTSHOW = -3 /* do not show the logo */
};
+#define FBCON_MAX_FONT_WIDTH 32
+#define FBCON_MAX_FONT_HEIGHT 32
+
static struct fbcon_display fb_display[MAX_NR_CONSOLES];
static struct fb_info *fbcon_registered_fb[FB_MAX];
@@ -2458,6 +2461,21 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
return ret;
}
+
+static int fbcon_font_info(struct vc_data *vc, struct console_font_info *info)
+{
+ info->min_width = 0;
+ info->min_height = 0;
+
+ info->max_width = FBCON_MAX_FONT_WIDTH;
+ info->max_height = FBCON_MAX_FONT_HEIGHT;
+
+ info->flags = KD_FONT_INFO_FLAG_LOW_SIZE | KD_FONT_INFO_FLAG_HIGH_SIZE;
+
+ return 0;
+}
+
+
/*
* User asked to set font; we are guaranteed that charcount does not exceed 512
* but lets not assume that, since charcount of 512 is small for unicode support.
@@ -2485,7 +2503,8 @@ static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
- if (font->width > 32 || font->height > 32)
+ if (font->width > FBCON_MAX_FONT_WIDTH ||
+ font->height > FBCON_MAX_FONT_HEIGHT)
return -EINVAL;
/* Make sure drawing engine can handle the font */
@@ -3160,6 +3179,7 @@ static const struct consw fb_con = {
.con_scroll = fbcon_scroll,
.con_switch = fbcon_switch,
.con_blank = fbcon_blank,
+ .con_font_info = fbcon_font_info,
.con_font_set = fbcon_set_font,
.con_font_get = fbcon_get_font,
.con_font_default = fbcon_set_def_font,
--
2.44.0
^ permalink raw reply related
* [RFC PATCH v2 0/5] VT: Add ability to get font requirements
From: Alexey Gladkov @ 2024-02-26 15:21 UTC (permalink / raw)
To: LKML, Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-api
In-Reply-To: <cover.1708011391.git.legion@kernel.org>
We now have KD_FONT_OP_SET_TALL, but in fact such large fonts cannot be
loaded. No console driver supports tall fonts. Unfortunately, userspace
cannot distinguish the lack of support in the driver from errors in the
font itself. In all cases, EINVAL will be returned.
In order not to hack the KDFONTOP interface, I suggest adding a new ioctl to
obtain information about the capabilities of the console driver.
This is the second version of the patch with the fixes pointed out by Jiri
Slaby.
Previous version: https://lore.kernel.org/all/cover.1708011391.git.legion@kernel.org/
---
Alexey Gladkov (5):
VT: Add KD_FONT_OP_GET_INFO operation
newport_con: Allow to get max font width and height
sticon: Allow to get max font width and height
vgacon: Allow to get max font width and height
fbcon: Allow to get max font width and height
drivers/tty/vt/vt.c | 24 ++++++++++++++++++++++++
drivers/tty/vt/vt_ioctl.c | 12 ++++++++++++
drivers/video/console/newport_con.c | 21 +++++++++++++++++----
drivers/video/console/sticon.c | 25 +++++++++++++++++++++++--
drivers/video/console/vgacon.c | 21 ++++++++++++++++++++-
drivers/video/fbdev/core/fbcon.c | 22 +++++++++++++++++++++-
include/linux/console.h | 2 ++
include/linux/vt_kern.h | 1 +
include/uapi/linux/kd.h | 13 ++++++++++++-
9 files changed, 132 insertions(+), 9 deletions(-)
--
2.44.0
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: Rich Felker @ 2024-02-26 14:33 UTC (permalink / raw)
To: Christian Brauner
Cc: Xi Ruoyao, Arnd Bergmann, Icenowy Zheng, Huacai Chen, WANG Xuerui,
Adhemerval Zanella, linux-api, Kees Cook, Xuefeng Li, Jianmin Lv,
Xiaotian Wu, WANG Rui, Miao Wang, loongarch@lists.linux.dev,
Linux-Arch, Linux Kernel Mailing List
In-Reply-To: <20240226-siegen-desolat-49d1e20ba2cd@brauner>
On Mon, Feb 26, 2024 at 01:57:55PM +0100, Christian Brauner wrote:
> On Mon, Feb 26, 2024 at 07:57:56PM +0800, Xi Ruoyao wrote:
> > On Mon, 2024-02-26 at 10:20 +0100, Arnd Bergmann wrote:
> >
> > /* snip */
> >
> > >
> > > > Or maybe we can just introduce a new AT_something to make statx
> > > > completely ignore pathname but behave like AT_EMPTY_PATH + "".
>
> I'm not at all convinced about doing custom semantics for this.
I did not follow the entirety of this thread. I've been aware for a
while that the need to use AT_EMPTY_PATH (on archs that don't have old
syscalls) is a performance problem in addition to being a sandboxing
problem, because the semantics for it were defined to use the string
argument if present, thereby requiring the kernel to perform an
additional string read from user memory.
Unfortunately, I don't see any good fix. Even if we could add
AT_STATX_NO_PATH/AT_STATX_NULL_PATH, libc would not be using it,
because using them would incur EINVAL-then-fallback on kernels that
don't support it.
In regards to the Chromium sandbox, I think Chromium is just wrong
here. Blocking statx is not safe (it also does not work on 32-bit
archs -- it breaks time64 support! and riscv32 doesn't even have
legacy stat either, just like loongarch64), and there is really no
serious security risk from being able to stat arbitrary pathnames.
Maybe it's annoying from a theoretical purity standpoint that you
can't block that, but from a practical standpoint it doesn't really
matter.
I'd like to see a solution to this, but all the possible ones look
bad. And it's all a consequence of poor consideration of how
AT_EMPTY_PATH should work when it was first invented/added. >_<
> > > I think this is better than going back to fstat64_time64(), but
> > > it's still not great because
> > >
> > > - all the reserved flags on statx() are by definition incompatible
> > > with existing kernels that return -EINVAL for any flag they do
> > > not recognize.
> >
> > Oops, we are deeming passing undefined flags in "mask" undefined
> > behavior but not "flags", thus "wild software" may be relying on EINVAL
> > for invalid flags... We *might* make this new AT_xxx a bit in mask
> > instead of flags but it would be very dirty IMO.
>
> Uhm, no. AT_* flags have nothing to do in statx()'s mask argument at all.
They definitely cannot go in mask; that's semantically wrong.
Rich
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: WANG Xuerui @ 2024-02-26 14:00 UTC (permalink / raw)
To: Christian Brauner, Arnd Bergmann
Cc: Xi Ruoyao, Icenowy Zheng, Huacai Chen, linux-api, Kees Cook,
Xuefeng Li, Jianmin Lv, Xiaotian Wu, WANG Rui, Miao Wang,
loongarch@lists.linux.dev, Linux-Arch, Linux Kernel Mailing List
In-Reply-To: <20240226-graustufen-hinsehen-6c578a744806@brauner>
On 2/26/24 21:32, Christian Brauner wrote:
> On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
>> On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
>>> On Mon, 2024-02-26 at 07:56 +0100, Arnd Bergmann wrote:
>>>> On Mon, Feb 26, 2024, at 07:03, Icenowy Zheng wrote:
>>>>> 在 2024-02-25星期日的 15:32 +0800，Xi Ruoyao写道：
>>>>>> On Sun, 2024-02-25 at 14:51 +0800, Icenowy Zheng wrote:
>>>>>>> My idea is this problem needs syscalls to be designed with deep
>>>>>>> argument inspection in mind; syscalls before this should be
>>>>>>> considered
>>>>>>> as historical error and get fixed by resotring old syscalls.
>>>>>>
>>>>>> I'd not consider fstat an error as using statx for fstat has a
>>>>>> performance impact (severe for some workflows), and Linus has
>>>>>> concluded
>>>>>
>>>>> Sorry for clearance, I mean statx is an error in ABI design, not fstat.
>>>
>>> I'm wondering why we decided to use AT_EMPTY_PATH/"" instead of
>>> "AT_NULL_PATH"/nullptr in the first place?
>>
>> Not sure, but it's hard to change now since the libc
>> implementation won't easily know whether using the NULL
>> path is safe on a given kernel. It could check the kernel
>> version number, but that adds another bit of complexity in
>> the fast path and doesn't work on old kernels with the
>> feature backported.
>>
>>> But it's not irrational to pass a path to syscall, as long as we still
>>> have the concept of file system (maybe in 2371 or some year we'll use a
>>> 128-bit UUID instead of path).
>>>
>>>> The problem I see with the 'use use fstat' approach is that this
>>>> does not work on 32-bit architectures, unless we define a new
>>>> fstatat64_time64() syscall, which is one of the things that statx()
>>>
>>> "fstat64_time64". Using statx for fstatat should be just fine.
>>
>> Right. It does feel wrong to have only an fstat() variant but not
>> fstatat() if we go there.
>>
>>> Or maybe we can just introduce a new AT_something to make statx
>>> completely ignore pathname but behave like AT_EMPTY_PATH + "".
>>
>> I think this is better than going back to fstat64_time64(), but
>> it's still not great because
>>
>> - all the reserved flags on statx() are by definition incompatible
>> with existing kernels that return -EINVAL for any flag they do
>> not recognize.
>>
>> - you still need to convince libc developers to actually use
>> the flag despite the backwards compatibility problem, either
>> with a fallback to the current behavior or a version check.
>>
>> Using the NULL path as a fallback would solve the problem with
>> seccomp, but it would not make the normal case any faster.
>>
>>>> was trying to avoid.
>>>
>>> Oops. I thought "newstat" should be using 64-bit time but it seems the
>>> "new" is not what I'd expected... The "new" actually means "newer than
>>> Linux 0.9"! :(
>>>
>>> Let's not use "new" in future syscall names...
>>
>> Right, we definitely can't ever succeed. On some architectures
>> we even had "oldstat" and "stat" before "newstat" and "stat64",
>> and on some architectures we mix them up. E.g. x86_64 has fstat()
>> and fstatat64() with the same structure but doesn't define
>> __NR_newfstat. On mips64, there is a 'newstat' but it has 32-bit
>> timestamps unlike all other 64-bit architectures.
>>
>> statx() was intended to solve these problems once and for all,
>> and it appears that we have failed again.
>
> New apis don't invalidate old apis necessarily. That's just not going to
> work in an age where you have containerized workloads.
>
> statx() is just the beginning of this. A container may have aritrary
> seccomp profiles that return ENOSYS or even EPERM for whatever reason
> for any new api that exists. So not implementing fstat() might already
> break container workloads.
>
> Another example: You can't just skip on implementing mount() and only
> implement the new mount api for example. Because tools that look for api
> simplicity and don't need complex setup will _always_ continue to use
> mount() and have a right to do so.
>
> And fwiw, mount() isn't fully inspectable by seccomp since forever. The
> list goes on and on.
>
> But let's look at the original mail. Why are they denying statx() and
> what's that claim about it not being able to be rewritten to something
> safe? Looking at:
>
> intptr_t SIGSYSFstatatHandler(const struct arch_seccomp_data& args,
> void* fs_denied_errno) {
> if (args.nr == __NR_fstatat_default) {
> if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
> args.args[3] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
> return syscall(__NR_fstat_default, static_cast<int>(args.args[0]),
> reinterpret_cast<default_stat_struct*>(args.args[2]));
> }
> return -reinterpret_cast<intptr_t>(fs_denied_errno);
> }
>
> What this does it to rewrite fstatat() to fstat() if it was made with
> AT_EMPTY_PATH and the path argument was "". That is easily doable for
> statx() because it has the exact same AT_EMPTY_PATH semantics that
> fstatat() has.
>
> Plus, they can even filter on mask and rewrite that to something that
> they think is safe. For example, STATX_BASIC_STATS which is equivalent
> to what any fstat() call returns. So it's pretty difficult to understand
> what their actual gripe with statx() is.
>
> It can't be that statx() passes a struct because fstatat() and fstat()
> do that too. So what exactly is that problem there?
From our investigation:
For (new)fstatat calls that the sandboxed process may make, this SIGSYS
handler either:
* turns allowed calls (those looking at fd's) into fstat's that only
have one argument (the fd) each, or
* denies the call,
so the sandbox only ever sees fstat calls and no (new)fstatat's, and the
guarantee that only open fds can ever been stat'ed trivially holds.
With statx, however, there's no way of guaranteeing "only look at fd"
semantics without peeking into the path argument, because a non-empty
path makes AT_EMPTY_PATH ineffective, and the flags are not validated
prior to use making it near-impossible to introduce new semantics in a
backwards-compatible manner.
> What this tells me without knowing the exact reason is that they thought
> "Oh, if we just return ENOSYS then the workload or glibc will just
> always be able to fallback to fstat() or fstatat()". Which ultimately is
> the exact same thing that containers often assume.
>
> So really, just skipping on various system calls isn't going to work.
> You can't just implement new system calls and forget about the rest
> unless you know exactly what workloads your architecure will run on.
>
> Please implement fstat() or fstatat() and stop inventing hacks for
> statx() to make weird sandboxing rules work, please.
We have already provided fstat(at) on LoongArch for a while by
unconditionally doing statx and translating the returned structure --
see the [glibc] and [golang] [golang-2] implementations for example --
without fallbacks because we know that the old syscalls don't exist. So
if we effectively back out the kernel-side change (removing fstat) we
must arrange for the various syscall makers to be able to fallback to
fstat too.
(The glibc code seems self-adapting to presence of newfstatat, but Go
could need more care. Though a simple rebuild of libc is enough for the
Chromium sandbox to work without code changes on their side.)
[glibc]: https://sourceware.org/pipermail/libc-alpha/2022-May/138958.html
[golang]: https://go.dev/cl/407694
[golang-2]: https://go.dev/cl/411378
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: Arnd Bergmann @ 2024-02-26 13:46 UTC (permalink / raw)
To: Christian Brauner
Cc: Xi Ruoyao, Icenowy Zheng, Huacai Chen, WANG Xuerui, linux-api,
Kees Cook, Xuefeng Li, Jianmin Lv, Xiaotian Wu, WANG Rui,
Miao Wang, loongarch@lists.linux.dev, Linux-Arch,
Linux Kernel Mailing List
In-Reply-To: <20240226-graustufen-hinsehen-6c578a744806@brauner>
On Mon, Feb 26, 2024, at 14:32, Christian Brauner wrote:
> On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
>> On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
>
> What this tells me without knowing the exact reason is that they thought
> "Oh, if we just return ENOSYS then the workload or glibc will just
> always be able to fallback to fstat() or fstatat()". Which ultimately is
> the exact same thing that containers often assume.
>
> So really, just skipping on various system calls isn't going to work.
> You can't just implement new system calls and forget about the rest
> unless you know exactly what workloads your architecure will run on.
>
> Please implement fstat() or fstatat() and stop inventing hacks for
> statx() to make weird sandboxing rules work, please.
Do you mean we should add fstat64_time64() for all architectures
then? Would use use the same structure layout as statx for this,
the 64-bit version of the 'struct stat' layout from
include/uapi/asm-generic/stat.h, or something new that solves
the same problems?
I definitely don't want to see a new time32 API added to
mips64 and the 32-bit architectures, so the existing stat64
interface won't work as a statx replacement.
Arnd
^ permalink raw reply
* Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: Christian Brauner @ 2024-02-26 13:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Xi Ruoyao, Icenowy Zheng, Huacai Chen, WANG Xuerui, linux-api,
Kees Cook, Xuefeng Li, Jianmin Lv, Xiaotian Wu, WANG Rui,
Miao Wang, loongarch@lists.linux.dev, Linux-Arch,
Linux Kernel Mailing List
In-Reply-To: <20240226-graustufen-hinsehen-6c578a744806@brauner>
On Mon, Feb 26, 2024 at 02:32:09PM +0100, Christian Brauner wrote:
> On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
> > On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
> > > On Mon, 2024-02-26 at 07:56 +0100, Arnd Bergmann wrote:
> > >> On Mon, Feb 26, 2024, at 07:03, Icenowy Zheng wrote:
> > >> > 在 2024-02-25星期日的 15:32 +0800，Xi Ruoyao写道：
> > >> > > On Sun, 2024-02-25 at 14:51 +0800, Icenowy Zheng wrote:
> > >> > > > My idea is this problem needs syscalls to be designed with deep
> > >> > > > argument inspection in mind; syscalls before this should be
> > >> > > > considered
> > >> > > > as historical error and get fixed by resotring old syscalls.
> > >> > >
> > >> > > I'd not consider fstat an error as using statx for fstat has a
> > >> > > performance impact (severe for some workflows), and Linus has
> > >> > > concluded
> > >> >
> > >> > Sorry for clearance, I mean statx is an error in ABI design, not fstat.
> > >
> > > I'm wondering why we decided to use AT_EMPTY_PATH/"" instead of
> > > "AT_NULL_PATH"/nullptr in the first place?
> >
> > Not sure, but it's hard to change now since the libc
> > implementation won't easily know whether using the NULL
> > path is safe on a given kernel. It could check the kernel
> > version number, but that adds another bit of complexity in
> > the fast path and doesn't work on old kernels with the
> > feature backported.
> >
> > > But it's not irrational to pass a path to syscall, as long as we still
> > > have the concept of file system (maybe in 2371 or some year we'll use a
> > > 128-bit UUID instead of path).
> > >
> > >> The problem I see with the 'use use fstat' approach is that this
> > >> does not work on 32-bit architectures, unless we define a new
> > >> fstatat64_time64() syscall, which is one of the things that statx()
> > >
> > > "fstat64_time64". Using statx for fstatat should be just fine.
> >
> > Right. It does feel wrong to have only an fstat() variant but not
> > fstatat() if we go there.
> >
> > > Or maybe we can just introduce a new AT_something to make statx
> > > completely ignore pathname but behave like AT_EMPTY_PATH + "".
> >
> > I think this is better than going back to fstat64_time64(), but
> > it's still not great because
> >
> > - all the reserved flags on statx() are by definition incompatible
> > with existing kernels that return -EINVAL for any flag they do
> > not recognize.
> >
> > - you still need to convince libc developers to actually use
> > the flag despite the backwards compatibility problem, either
> > with a fallback to the current behavior or a version check.
> >
> > Using the NULL path as a fallback would solve the problem with
> > seccomp, but it would not make the normal case any faster.
> >
> > >> was trying to avoid.
> > >
> > > Oops. I thought "newstat" should be using 64-bit time but it seems the
> > > "new" is not what I'd expected... The "new" actually means "newer than
> > > Linux 0.9"! :(
> > >
> > > Let's not use "new" in future syscall names...
> >
> > Right, we definitely can't ever succeed. On some architectures
> > we even had "oldstat" and "stat" before "newstat" and "stat64",
> > and on some architectures we mix them up. E.g. x86_64 has fstat()
> > and fstatat64() with the same structure but doesn't define
> > __NR_newfstat. On mips64, there is a 'newstat' but it has 32-bit
> > timestamps unlike all other 64-bit architectures.
> >
> > statx() was intended to solve these problems once and for all,
> > and it appears that we have failed again.
>
> New apis don't invalidate old apis necessarily. That's just not going to
> work in an age where you have containerized workloads.
>
> statx() is just the beginning of this. A container may have aritrary
> seccomp profiles that return ENOSYS or even EPERM for whatever reason
> for any new api that exists. So not implementing fstat() might already
> break container workloads.
>
> Another example: You can't just skip on implementing mount() and only
> implement the new mount api for example. Because tools that look for api
> simplicity and don't need complex setup will _always_ continue to use
> mount() and have a right to do so.
>
> And fwiw, mount() isn't fully inspectable by seccomp since forever. The
> list goes on and on.
>
> But let's look at the original mail. Why are they denying statx() and
> what's that claim about it not being able to be rewritten to something
> safe? Looking at:
>
> intptr_t SIGSYSFstatatHandler(const struct arch_seccomp_data& args,
> void* fs_denied_errno) {
> if (args.nr == __NR_fstatat_default) {
> if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
> args.args[3] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
> return syscall(__NR_fstat_default, static_cast<int>(args.args[0]),
> reinterpret_cast<default_stat_struct*>(args.args[2]));
> }
> return -reinterpret_cast<intptr_t>(fs_denied_errno);
> }
>
> What this does it to rewrite fstatat() to fstat() if it was made with
> AT_EMPTY_PATH and the path argument was "". That is easily doable for
> statx() because it has the exact same AT_EMPTY_PATH semantics that
> fstatat() has.
>
> Plus, they can even filter on mask and rewrite that to something that
> they think is safe. For example, STATX_BASIC_STATS which is equivalent
> to what any fstat() call returns. So it's pretty difficult to understand
> what their actual gripe with statx() is.
>
> It can't be that statx() passes a struct because fstatat() and fstat()
> do that too. So what exactly is that problem there?
>
> What this tells me without knowing the exact reason is that they thought
> "Oh, if we just return ENOSYS then the workload or glibc will just
> always be able to fallback to fstat() or fstatat()". Which ultimately is
> the exact same thing that containers often assume.
>
> So really, just skipping on various system calls isn't going to work.
> You can't just implement new system calls and forget about the rest
> unless you know exactly what workloads your architecure will run on.
>
> Please implement fstat() or fstatat() and stop inventing hacks for
> statx() to make weird sandboxing rules work, please.
And fwiw, if they rewrite fstatat() to fstat() then they must be
worrying about another thread racing and putting something in the second
argument (the path argument) after they have inspected the system call
arguments but before the system call continue.
But if that is their worry then a new flag to statx() won't help at all.
Because then they really want to use fstat(). IOW, one would have to add
fstatx() which brings us back to square one. I'm mostly going by that
code snippet of course.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox