ng patches from others?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
below.
Cheers,
Michael
Changes in man-pages-5.11
Released: 2021-03-21, Munich
New and rewritten pages
---
close_range.2
Stephen Kitt, Michael Kerrisk [Christian Brauner]
New page documenting close_range(2)
process_madvise
On 3/9/21 8:53 PM, Stephen Kitt wrote:
> Hi Michael,
>
> On Thu, 28 Jan 2021 21:50:23 +0100, "Michael Kerrisk (man-pages)"
> wrote:
>> Thanks for your patch revision. I've merged it, and have
>> done some light editing, but I still have a question:
>
&
Hello Stephen and Christian,
Late follow-up, I'm afraid...
On 1/29/21 11:00 AM, Christian Brauner wrote:
> On Thu, Jan 28, 2021 at 11:10:40PM +0100, Stephen Kitt wrote:
>> Hello Michael,
>>
>> On Thu, 28 Jan 2021 21:50:23 +0100, "Michael Kerrisk (man-pages)"
membarrier(int " cmd ", int " flags );
> +.BI "int syscall(SYS_membarrier, int " cmd ", int " flags );
> .EE
> .in
> .SH CONFORMING TO
> @@ -322,9 +321,6 @@ Examples where
> .BR membarrier ()
> can be useful include implementations
> of Read-Copy-Update libraries and garbage collectors.
> -.PP
> -Glibc does not provide a wrapper for this system call; call it using
> -.BR syscall (2).
> .SH EXAMPLES
> Assuming a multithreaded application where "fast_path()" is executed
> very frequently, and where "slow_path()" is executed infrequently, the
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Glibc wrapper function: */
> .B #include
> .PP
> -.BI "int execve(const char *" pathname ", char *const " argv [],
> -.BI " char *const " envp []);
> +.BI "int execve(const char *" pathname ",
> +.BI " char
de a wrapper for this system call; call it us‐
ing syscall(2).
SEE ALSO
madvise(2), pidfd_open(2), process_vm_readv(2),
process_vm_write(2)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Tr
Hello Suren,
On 2/2/21 11:12 PM, Suren Baghdasaryan wrote:
> Hi Michael,
>
> On Tue, Feb 2, 2021 at 2:45 AM Michael Kerrisk (man-pages)
> wrote:
>>
>> Hello Suren (and Minchan and Michal)
>>
>> Thank you for the revisions!
>>
>> I've applie
an2/ipc.2
> index 6589ffae6..a36e895a2 100644
> --- a/man2/ipc.2
> +++ b/man2/ipc.2
> @@ -27,9 +27,8 @@
> ipc \- System V IPC system calls
> .SH SYNOPSIS
> .nf
> -.BI "int ipc(unsigned int " call ", int " first ", int " second \
> -"
> changes in v2:
> - Changed description of MADV_COLD per Michal Hocko's suggestion
> - Applied fixes suggested by Michael Kerrisk
> changes in v3:
> - Added Michal's Reviewed-by
> - Applied additional fixes suggested by Michael Kerrisk
>
> NAME
> process_ma
en Baghdasaryan
> ---
> changes in v2:
> - Changed description of MADV_COLD per Michal Hocko's suggestion
> - Appled fixes suggested by Michael Kerrisk
>
> NAME
> process_madvise - give advice about use of memory to a process
s/-/\-/
>
&g
se the limit on the number
of open file descriptors has been reached? I mean: no new
FDs are being opened, so how can we go over the limit. I think
the cause of this error is something else, but what is it?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc
Hello Suren,
On 1/28/21 7:40 PM, Suren Baghdasaryan wrote:
> On Thu, Jan 28, 2021 at 4:24 AM Michael Kerrisk (man-pages)
> wrote:
>>
>> Hello Suren,
>>
>> Thank you for writing this page! Some comments below.
>
> Thanks for the review!
> Couple question
d by
> +.I iovec
> +is outside the accessible address space of the process pid.
s/process pid./
the process referred to by
.IR pidfd .
/
> +.TP
> +.B EINVAL
> +.I flags
> +is not 0.
> +.TP
> +.B EINVAL
> +The sum of the
> +.I iov_len
> +values of
> +.I iovec
> +overflows a ssize_t value.
.I ssize_t
> +.TP
> +.B EINVAL
> +.I vlen
> +is too large.
> +.TP
> +.B ENOMEM
> +Could not allocate memory for internal copies of the
> +.I iovec
> +structures.
> +.TP
> +.B EPERM
> +The caller does not have permission to access the address space of the
> process
> +.I pidfd.
.IR pidfd .
> +.TP
> +.B ESRCH
> +No process with ID
> +.I pidfd
> +exists.
Should this maybe be:
[[
The target process does not exist (i.e., it has terminated and
been waited on).
]]
See pidfd_send_signal(2).
Also, is an EBADF error possible? Again, see pidfd_send_signal(2).
> +.SH VERSIONS
> +Since Linux 5.10,
Better: This system call first appeared in Linux 5.10.
> +.\" commit ecb8ac8b1f146915aa6b96449b66dd48984caacc
> +support for this system call is optional,
s/support/Support/
> +depending on the setting of the
> +.B CONFIG_ADVISE_SYSCALLS
> +configuration option.
> +.SH SEE ALSO
> +.BR madvise (2),
> +.BR pidofd_open(2),
> +.BR process_vm_readv (2),
> +.BR process_vm_write (2)
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
er to a filesystem configuration context.
> +.TP
> +.B EINVAL
> +One of the source parameters referred to an invalid superblock.
> +.TP
> +.B ELOOP
> +Too many links encountered during pathname resolution.
> +.TP
> +.B ENAMETOOLONG
> +A path name was longer than
> +.BR
privileges.
> +.SH CONFORMING TO
> +These functions are Linux-specific and should not be used in programs
> intended
> +to be portable.
> +.SH VERSIONS
> +.BR fsopen "(), " fsmount "() and " fspick ()
> +were added to Linux in kernel 5.2.
> +.SH EXAMPLES
> +To illustrate the process, here's an example whereby this can be used to
> +reconfigure a filesystem:
> +.PP
> +.in +4n
> +.nf
> +sfd = fspick(AT_FDCWD, "/mnt", FSPICK_NO_AUTOMOUNT | FSPICK_CLOEXEC);
> +fsconfig(sfd, FSCONFIG_SET_FLAG, "ro", NULL, 0);
> +fsconfig(sfd, FSCONFIG_SET_STRING, "user_xattr", "false", 0);
> +fsconfig(sfd, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0);
> +.fi
> +.in
> +.PP
> +.SH NOTES
> +Glibc does not (yet) provide a wrapper for the
> +.BR fspick "()"
> +system call; call it using
> +.BR syscall (2).
> +.SH SEE ALSO
> +.BR mountpoint (1),
> +.BR fsconfig (2),
> +.BR fsopen (2),
> +.BR path_resolution (7),
> +.BR mount (8)
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hello David,
Ping!
Thanks,
Michael
On Fri, 16 Oct 2020 at 08:50, Michael Kerrisk (man-pages)
wrote:
>
> Hi David,
>
> Another ping for these five patches please!
>
> Cheers,
>
> Michael
>
> On Fri, 11 Sep 2020 at 14:44, Michael Kerrisk (man-pages)
> wrote:
P
> +This would move the object mounted on "/a" to "/b". It can also be used in
> +conjunction with
> +.BR open_tree "(2) or " open "(2) with " O_PATH :
> +.PP
> +.RS
> +.nf
> +fd = open_tree(AT_FDCWD, "/mnt", 0);
> +move_mount(fd, "", AT_FDCWD, "/mnt2", MOVE_MOUNT_F_EMPTY_PATH);
> +move_mount(fd, "", AT_FDCWD, "/mnt3", MOVE_MOUNT_F_EMPTY_PATH);
> +move_mount(fd, "", AT_FDCWD, "/mnt4", MOVE_MOUNT_F_EMPTY_PATH);
> +.fi
> +.RE
> +.PP
> +This would attach the path point for "/mnt" to fd, then it would move the
> +mount to "/mnt2", then move it to "/mnt3" and finally to "/mnt4".
> +.PP
> +It can also be used to attach new mounts:
> +.PP
> +.RS
> +.nf
> +sfd = fsopen("ext4", FSOPEN_CLOEXEC);
> +fsconfig(sfd, FSCONFIG_SET_STRING, "source", "/dev/sda1", 0);
> +fsconfig(sfd, FSCONFIG_SET_FLAG, "user_xattr", NULL, 0);
> +fsconfig(sfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
> +mfd = fsmount(sfd, FSMOUNT_CLOEXEC, MOUNT_ATTR_NODEV);
> +move_mount(mfd, "", AT_FDCWD, "/home", MOVE_MOUNT_F_EMPTY_PATH);
> +.fi
> +.RE
> +.PP
> +Which would open the Ext4 filesystem mounted on "/dev/sda1", turn on user
> +extended attribute support and create a mount object for it. Finally, the
> new
> +mount object would be attached with
> +.BR move_mount ()
> +to "/home".
> +.SH SEE ALSO
> +.BR fsmount (2),
> +.BR fsopen (2),
> +.BR open_tree (2)
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hello David,
Ping!
Thanks,
Michael
On Thu, 27 Aug 2020 at 13:01, Michael Kerrisk (man-pages)
wrote:
>
> Hello David,
>
> Can I ask that you please reply to each of my mails, rather than
> just sending out a new patch series (which of course I would also
> like you to do).
+/proc/self/ns/, cannot currently be restricted. For now, these kind of
> special
> +paths are then always allowed. Future Landlock evolutions will enable to
> +restrict such paths with dedicated ruleset flags.
> +
> +Questions and answers
> +=
> +
> +Wh
Hello all,
On Sat, 2 Jan 2021 at 00:55, Gabriel Krisman Bertazi
wrote:
>
> Michael Kerrisk suggested that, from an API perspective, it is a bad
> idea to share the PR_SYS_DISPATCH_ defines between the prctl operation
> and the selector variable. Therefore, define two new constants
.\" x86: ignore the sys_getcpu() tcache parameter
-In earlier kernels,
-if this argument was non-NULL,
+In Linux 2.6.23 and earlier, if the
+.I tcache
+argument was non-NULL,
then it specified a pointer to a caller-allocated buffer in thread-local
storage that was used to provide a cachi
: %s ...\en", argv[0]);
> +exit(EXIT_FAILURE);
> +}
> +
> +for (int i = 2; i < argc; i++) {
> +if (open(argv[i], O_RDONLY) == -1) {
> +perror(argv[i]);
> +exit(EXIT_FAILURE);
> +}
> +}
> +
> +if (syscall(__NR_close_range, 3, ~0U, CLOSE_RANGE_UNSHARE) == -1) {
Line too long.
Alternatively, what about s/CLOSE_RANGE_UNSHARE/0/? Or it
considered best practice to always use CLOSE_RANGE_UNSHARE?
> +perror("close_range");
> +exit(EXIT_FAILURE);
> +}
> +
> +execve(argv[1], newargv, newenviron);
> +perror("execve");
> +exit(EXIT_FAILURE);
> +}
> +.EE
> +.in
> +.PP
> +We can use the second program to exec the first as follows:
> +.PP
> +.in +4n
> +.EX
> +.RB "$" " make listopen close_range"
Perhaps we don't really need the preceding line?
> +.RB "$" " ./close_range ./listopen /dev/null /dev/zero"
> +FD 0 is open.
> +FD 1 is open.
> +FD 2 is open.
> +.EE
> +.in
> +.PP
> +Removing the call to
> +.BR close_range ()
> +will show different output,
> +with the file descriptors for the named files still open.
> +.SH SEE ALSO
> +.BR close (2)
>
> base-commit: b5dae3959625f5ff378e9edf9139057d1c06bb55
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Changes in man-pages-5.10
Newly documented interfaces in existing pages
-
access.2
Michael Kerrisk
Document faccessat2()
faccessat2() was added in Linux 5.8 and enables a fix to
-git a/man2/close_range.2 b/man2/close_range.2
>> new file mode 100644
>> index 0..403142b33
>> --- /dev/null
>> +++ b/man2/close_range.2
[...]
>> +.SH USE CASES
>
> This section is unconventional. Please move that text to one of the
> traditional
.BR close_range ()
>>> +can take care of this without requiring
>>> +.B /proc
>
> By reading proc.5, I think this should s/.B/.I/, right mtk?
Yes to both. Pathnames are formatted with .I.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
take a guess */
for (fd = 0; fd < maxfd; fd++)
close(fd);
I think it's fine to mention the use of a /proc as an (inferior and)
alternative way of doing this. I'm just not sure that "commonly" is
correct.
> +descriptors in
> +.B /proc/self/fd/
> +and calling
> +.BR close (2)
> +on each one.
> +.BR close_range ()
> +can take care of this without requiring
> +.B /proc
> +and with a single system call, which provides significant performance
> +benefits.
> +.SH SEE ALSO
> +.BR close (2)
>
> base-commit: b5dae3959625f5ff378e9edf9139057d1c06bb55
> --
> 2.20.1
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
one day I will return to being just a
contributor and no longer the maintainer.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
; index b38ba718f..d6f016665 100644
> --- a/man2/subpage_prot.2
> +++ b/man2/subpage_prot.2
> @@ -32,7 +32,7 @@
> subpage_prot \- define a subpage protection for an address range
> .SH SYNOPSIS
> .nf
> -.BI "long subpage_prot(unsigned long " addr ", unsigned
, mode_t " mode ","
.BI " int " neighbor_fd ");"
.fi
@@ -89,6 +88,12 @@ for a full list of the possible
values.
.PP
The
+.I neighbor_fd
+is used only when the
+.B SPU_CREATE_AFFINITY_SPU
+flag is specified; see below.
+.PP
+The
.I flags
argument can be zero or any bitwise OR-ed
combination of the following constants:
@@ -264,6 +269,14 @@ See
.UR http://www.bsc.es\:/projects\:/deepcomputing\:/linuxoncell/
.UE
for the recommended libraries.
+.PP
+Prior to the addition of the
+.B SPU_CREATE_AFFINITY_SPU
+flag in Linux 2.6.23, the
+.BR spu_create ()
+system call took only three arguments (i.e., there was no
+.I neighbor_fd
+argument).
.SH EXAMPLES
See
.BR spu_run (2)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
ough reason to document it.
>
> Adding Michael.
Commit 94b07c1f8c39 was your, Dave. Might I convince you to write a
patch for getauxval(3)?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
- #elif defined __mips__
> + #elif defined(__mips__ || __csky__)
>
> and then change the rest of the text to add csky when appropriate.
> Am I correct?
AFAICT, you are correct. I think the reason that csky is missing is
that the architecture was added after this manual p
d8..b18b8efef 100644
> --- a/man2/set_tid_address.2
> +++ b/man2/set_tid_address.2
> @@ -29,7 +29,7 @@ set_tid_address \- set pointer to thread ID
> .nf
> .B #include
> .PP
> -.BI "long set_tid_address(int *" tidptr );
> +.BI "pid_t set_tid_address(int *"
tart_syscall \- restart a system call after interruption by a stop signal
> .SH SYNOPSIS
> -.B int restart_syscall(void);
> +.B long restart_syscall(void);
> .PP
> .IR Note :
> There is no glibc wrapper for this system call; see NOTES.
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
gt; - #elif defined __mips__
> + #elif defined(__mips__ || __csky__)
>
> and then change the rest of the text to add csky when appropriate.
> Am I correct?
As far as I can tell, you are correct.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
pe needs to be updated, please do so.
> Especially, have a look at lseek64(3),
> which I suspect needs the same changes I propose in that patch.
I think that no changes to the types are needed in lseek64(3). But
maybe some of the info in this mail should be captured in that manual
page.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
gic either.)
Thanks,
Michael
PS By the way, be aware that the code of many wrapper functions is
autogenerated from "syscalls.list" files in the glibc source, for
example, sysdeps/unix/sysv/linux/syscalls.list. This isn't the case
for lseek(), though, as far as I can see; I think th
Hello Sargun,
Thanks for your reply!
On 11/2/20 9:07 AM, Sargun Dhillon wrote:
> On Sat, Oct 31, 2020 at 9:27 AM Michael Kerrisk (man-pages)
> wrote:
>>
>> Hello Sargun,
>>
>> Thanks for your reply.
>>
>> On 10/30/20 9:27 PM, Sargun Dhillon wrote:
&g
Alejandro Colomar, Michael Kerrisk
A new page documenting a wide range of system data types.
kernel_lockdown.7
David Howells, Heinrich Schuchardt [Michael Kerrisk]
New page documenting the Kernel Lockdown feature
Newly documented interfaces in existing pages
Hello Sargun,
Thanks for your reply.
On 10/30/20 9:27 PM, Sargun Dhillon wrote:
> On Thu, Oct 29, 2020 at 09:37:21PM +0100, Michael Kerrisk (man-pages)
> wrote:
[...]
>>> I think I commented in another thread somewhere that the
>>> supervisor is not notified if
On 10/30/20 8:20 PM, Jann Horn wrote:
> On Thu, Oct 29, 2020 at 8:14 PM Michael Kerrisk (man-pages)
> wrote:
>> On 10/29/20 2:42 AM, Jann Horn wrote:
>>> As discussed at
>>> <https://lore.kernel.org/r/CAG48ez0m4Y24ZBZCh+Tf4ORMm9_q4n7VOzpGjwGF7_Fe8EQH=q...@mail.gm
On 10/30/20 8:14 PM, Jann Horn wrote:
> On Thu, Oct 29, 2020 at 3:19 PM Michael Kerrisk (man-pages)
> wrote:
>> On 10/29/20 2:42 AM, Jann Horn wrote:
>>> On Mon, Oct 26, 2020 at 10:55 AM Michael Kerrisk (man-pages)
>>> wrote:
>>>>static
On 10/30/20 8:24 PM, Jann Horn wrote:
> On Thu, Oct 29, 2020 at 8:53 PM Michael Kerrisk (man-pages)
> wrote:
>> On 10/29/20 4:26 PM, Christian Brauner wrote:
>>> I like this manpage. I think this is the most comprehensive explanation
>>> of any seccomp feature
>
; atomically performs the equivalent of:
>> @@ -1794,7 +1795,7 @@ fwait(int *futexp)
>> while (1) {
>>
>> /* Is the futex available? */
>> -const int one = 1;
>> + const uint32_t one = 1;
>> if
SYNOPSIS
> .nf
> .PP
> -.B "#include "
> -.B "#include "
> +.B #include
> +.B #include
> .PP
> .BI "int futex(int *" uaddr ", int " futex_op ", int " val ,
> .BI " const struct timespec *" timeou
+const uint32_t one = 1;
> if (atomic_compare_exchange_strong(futexp, &one, 0))
> break; /* Yes */
>
> @@ -1811,13 +1812,13 @@ fwait(int *futexp)
> so that if the peer is blocked in fpost(), it can proceed. */
>
> static void
> -fpost(int *
Hello Sargun,,
On 10/29/20 9:53 AM, Sargun Dhillon wrote:
> On Mon, Oct 26, 2020 at 10:55:04AM +0100, Michael Kerrisk (man-pages) wrote:
[...]
>>ioctl(2) operations
>>The following ioctl(2) operations are provided to support seccomp
>>user-space notif
Hello Christian
Thanks for taking a look at the page.
On 10/29/20 4:26 PM, Christian Brauner wrote:
> On Mon, Oct 26, 2020 at 10:55:04AM +0100, Michael Kerrisk (man-pages) wrote:
>> Hi all (and especially Tycho and Sargun),
>>
>> Following review comments on the first draft
char buf[BUF_SIZE];
> struct linux_dirent *d;
> char d_type;
> @@ -301,7 +301,7 @@ main(int argc, char *argv[])
>
> printf("\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- nread=%d
> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\en", nread);
> printf("inode#file typ
Hello Jann,
On 10/29/20 2:42 AM, Jann Horn wrote:
> On Mon, Oct 26, 2020 at 10:55 AM Michael Kerrisk (man-pages)
> wrote:
>>static bool
>>getTargetPathname(struct seccomp_notif *req, int notifyFd,
>> char *path, size_t len)
>&g
Hello Jann,
On 10/29/20 2:42 AM, Jann Horn wrote:
> On Mon, Oct 26, 2020 at 10:55 AM Michael Kerrisk (man-pages)
> wrote:
>>static bool
>>getTargetPathname(struct seccomp_notif *req, int notifyFd,
>> char *path, size_t len)
>&g
ot;inode#file type d_reclen d_off d_name\en");
> -for (int bpos = 0; bpos < nread;) {
> +for (long bpos = 0; bpos < nread;) {
> d = (struct linux_dirent *) (buf + bpos);
> printf("%8ld ", d\->d_ino);
> d_type = *(buf + bpos + d\->d_reclen \- 1);
> --
> 2.28.0
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
On Tue, 27 Oct 2020 at 18:10, Alexey Budankov
wrote:
>
>
> On 27.10.2020 19:57, Michael Kerrisk (man-pages) wrote:
> > Hello Alexey,
> >
> > On 10/27/20 5:48 PM, Alexey Budankov wrote:
> >>
> >> Extend perf_event_open 2 man page with the information
ERFMON
> +rather than the much more powerful
> +.B CAP_SYS_ADMIN
> +excludes chances to misuse credentials and makes operations more secure.
> +.B CAP_SYS_ADMIN
> +usage for secure system performance monitoring and observability
> +is discouraged with respect to
> +.B CAP_PERFMON
> +capability.
Thank you for adding the above piece. That point of course
really needs to be emphasized!
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hi Alex,
On Tue, 27 Oct 2020 at 16:25, Alejandro Colomar wrote:
>
>
>
> On 2020-10-27 14:47, Michael Kerrisk (man-pages) wrote:
> > On 10/27/20 11:23 AM, Alejandro Colomar wrote:
> >> Hi Michael,
> >>
> >> On 2020-10-07 08:53, Michael Kerrisk
On 10/27/20 11:23 AM, Alejandro Colomar wrote:
> Hi Michael,
>
> On 2020-10-07 08:53, Michael Kerrisk (man-pages) wrote:
>> On 10/6/20 12:12 AM, Alejandro Colomar wrote:
>>> Signed-off-by: Alejandro Colomar
>>
>> Hi Alex,
>>
>> Thanks, patch applie
since the situation is odd
and surprising.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hi Alexei,
Would you be able to refresh this patch and resend please?
Thnks,
Michael
On Mon, 24 Aug 2020 at 22:17, Alexey Budankov
wrote:
>
> Hi Michael,
>
> On 23.08.2020 20:28, Michael Kerrisk (man-pages) wrote:
> > Hello Alexey,
> >
> > Could you look at the
On 10/26/20 4:54 PM, Jann Horn wrote:
> On Sun, Oct 25, 2020 at 5:32 PM Michael Kerrisk (man-pages)
> wrote:
[...]
>> I tried applying the patch below to vanilla 5.9.0.
>> (There's one typo: s/ENOTCON/ENOTCONN).
>>
>> It seems not to work though; when I send a
Hi Tycho,
Thanks for getting back to me.
On Mon, 26 Oct 2020 at 14:54, Tycho Andersen wrote:
>
> On Mon, Oct 26, 2020 at 10:55:04AM +0100, Michael Kerrisk (man-pages) wrote:
> > Hi all (and especially Tycho and Sargun),
> >
> > Following review comments on the first dra
│ │
│I mean, it's not like seccomp doesn't already expose │
│weirdness with syscall restarts. Not even arm64 │
│compat agrees[3] with arm32 in this regard. :( │
└─────────┘
Hi Jann,
On 10/26/20 10:32 AM, Jann Horn wrote:
> On Sat, Oct 24, 2020 at 2:53 PM Michael Kerrisk (man-pages)
> wrote:
>> On 10/17/20 2:25 AM, Jann Horn wrote:
>>> On Fri, Oct 16, 2020 at 8:29 PM Michael Kerrisk (man-pages)
>>> wrote:
> [...]
>>>>
Hello Kees,
On 10/26/20 1:19 AM, Kees Cook wrote:
> On Thu, Oct 15, 2020 at 01:24:03PM +0200, Michael Kerrisk (man-pages) wrote:
>> On 10/1/20 1:39 AM, Kees Cook wrote:
>>> I'll comment more later, but I've run out of time today and I didn't see
>>> anyo
n wrote:
>>>>> On Wed, Sep 30, 2020 at 10:34:51PM +0200, Michael Kerrisk (man-pages)
>>>>> wrote:
>>>>>> On 9/30/20 5:03 PM, Tycho Andersen wrote:
>>>&g
Hello Jann,
On 10/17/20 2:25 AM, Jann Horn wrote:
> On Fri, Oct 16, 2020 at 8:29 PM Michael Kerrisk (man-pages)
> wrote:
>> On 10/15/20 10:32 PM, Jann Horn wrote:
>>> On Thu, Oct 15, 2020 at 1:24 PM Michael Kerrisk (man-pages)
>>> wrote:
>>>> On 9/30
Hello Jann,
Thanks for your reply!
On 10/15/20 10:32 PM, Jann Horn wrote:
> On Thu, Oct 15, 2020 at 1:24 PM Michael Kerrisk (man-pages)
> wrote:
>> On 9/30/20 5:53 PM, Jann Horn wrote:
>>> On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
>>> wrote:
>
Hi David,
Another ping for these five patches please!
Cheers,
Michael
On Fri, 11 Sep 2020 at 14:44, Michael Kerrisk (man-pages)
wrote:
>
> Hi David,
>
> A ping for these five patches please!
>
> Cheers,
>
> Michael
>
> On Wed, 2 Sep 2020 at 22:14, Michae
Hello Christian,
On 10/1/20 2:36 PM, Christian Brauner wrote:
> [I'm on vacation so I'll just give this a quick glance for now.]
>
> On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Tycho, Sargun (and all),
>>
>> I knew it
Hi Jann,
So, first off, thank you for the detailed review. I really
appreciate it! I've changed various pieces, and still have
a few questions below.
On 9/30/20 5:53 PM, Jann Horn wrote:
> On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
> wrote:
>> I knew it would
Hello Kees,
On 10/1/20 1:39 AM, Kees Cook wrote:
> On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote:
>> [...] I did :-)
>
> Yay! Thank you!
You're welcome :-)
>> [...]
>>Overview
>>In conventional usage of a
n Wed, Sep 30, 2020 at 05:53:46PM +0200, Jann Horn via Containers wrote:
>>>>> On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
>>>>> wrote:
>>>>>> NOTES
>>>>>>The file descriptor returned when seccom
Hi Tycho,
Ping on the question below!
Thanks,
Michael
On 10/1/20 9:45 AM, Michael Kerrisk (man-pages) wrote:
> On 10/1/20 1:03 AM, Tycho Andersen wrote:
>> On Wed, Sep 30, 2020 at 10:34:51PM +0200, Michael Kerrisk (man-pages) wrote:
>>> Hi Tycho,
>>>
>>> T
Hello Linus,
On 10/13/20 12:30 AM, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages)
> wrote:
>>
>> I don't think this is correct. The epoll(7) manual page
>> sill carries the text written long ago by Davide Libenzi,
>> th
On 10/12/20 10:52 PM, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages)
> wrote:
>>
>> [CC += Davide]
>
> I'm not sure how active Davide is any more..
Yep, I know. But just in case.
>> I don't think this is correct. The
[CC += Davide]
Hello Linus,
Thanks for your quick reply.
On 10/12/20 9:25 PM, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 11:40 AM Michael Kerrisk (man-pages)
> wrote:
>>
>> Between Linux 5.4 and 5.5 a regression was introduced in the operation
>> of the epoll
a byte to pipe()
3: FAIL: ret = 0; EXPECTED: ret = 1, events = [ EPOLLIN ]
Closing write end of pipe()
4: OK: ret = 1, events = [ EPOLLIN EPOLLHUP ]
Thanks,
Michael
=
/* pipe_epollet_test.c
Copyright (c) 2020, Michael Kerrisk
Licensed under GNU
gt; new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/off_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
preadv (2),
> +.BR truncate (2),
> +.BR fseeko (3),
> +.BR getdirentries (3),
> +.BR lockf (3),
> +.BR posix_fallocate (3)
> +.\".PP TODO: loff_t, off64_t
> +.\"See also the
> +.\".I loff_t
> +.\"and
> +.\".I off64_t
> +.\"
On 10/6/20 12:08 AM, Alejandro Colomar wrote:
> Hi Michael,
>
> On 2020-10-03 13:39, Michael Kerrisk (man-pages) wrote:
>> Hi Alex,
> [...]
>>
>> off_t would be great.
>>
>> In case you are looking for some other candidates, some others
>> that I w
On 10/3/20 9:48 AM, G. Branden Robinson wrote:
> At 2020-10-03T09:10:14+0200, Michael Kerrisk (man-pages) wrote:
>> On 10/2/20 10:27 PM, Alejandro Colomar wrote:
>>> On 2020-10-02 22:14, Paul Eggert wrote:
>>> > On 10/2/20 11:38 AM, Alejandro Colomar
y now start writing about off_t and related types,
> which were the ones that made me want this page.
off_t would be great.
In case you are looking for some other candidates, some others
that I would be interested to see go into the page would be
fd_set
clock_t
clockid_t
and probably dev_t
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
diff --git a/man3/void.3 b/man3/void.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/void.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UN
t; Compatibility between function pointers and void * hasn't always been so.
> Document when that was added to POSIX.
>
> Reported-by: Michael Kerrisk
> Signed-off-by: Alejandro Colomar
>
> system_data_types.7: void *: wfix
>
> Reported-by: Jonathan Wakely
> Reported-b
x27;t have
[u]int_fastN_t
[u]int_leastN_t
in the page. They are C details that have nothing to with POSIX,
the kernel, or libc. Could you send me a patch to remove these
from the page? And again, my apologies for not being focused
enough on the big picture sooner.
I don't think 'void
here that text in man(7) comes from. However, for clarity
I would normally also use quotes in this case.
> Michael, you might want to have a look at it.
>
> I'll also add Branden, who might have something to say about it.
Yes, maybe Branden can add some insight.
Thanks,
Michael
to this type in the future.
Actually, I would rather prefer one patch series, rather than
patches on patches please. It also makes review of the overall
'void *' text easier if it's all one patch. So, If you could
squash the patches together and resubmit, that would be helful.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
] Mind you, man-pages trayed over the line already very many years
ago with operators(7), because who ever remembers all of the C
operator precedences.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
saving me the trouble of saying that (again).
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
On 10/1/20 1:03 AM, Tycho Andersen wrote:
> On Wed, Sep 30, 2020 at 10:34:51PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Tycho,
>>
>> Thanks for taking time to look at the page!
>>
>> On 9/30/20 5:03 PM, Tycho Andersen wrote:
>>> On Wed, Sep 30, 2020
Hi Tycho,
Thanks for taking time to look at the page!
On 9/30/20 5:03 PM, Tycho Andersen wrote:
> On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote:
>>2. In order that the supervisor process can obtain notifications
>> using the
{
int sockPair[2];
setbuf(stdout, NULL);
if (argc < 2) {
fprintf(stderr, "At least one pathname argument is required\n");
exit(EXIT_FAILURE);
> 2.- Use sizeof() everywhere, and the macro for the initializer.
>
> pros:
> - It is valid as long as the buffer is an array.
> cons:
> - If the code gets into a function, and the buffer is then a pointer,
>it will definitively produce a silent bug.
Sigh! I just did exactly the last point
e: grep :)
> I agree it's visually somewhat harder, but grepping is way easier.
I'd say number 2 also. But, visually, it's the least difficult
for me.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hi Branden,
On 9/27/20 7:46 AM, G. Branden Robinson wrote:
> At 2020-09-24T10:06:23+0200, Michael Kerrisk (man-pages) wrote:
>> Thanks for the interesting history, Branden!
>
> Hi, Michael. And you're welcome! I often wonder if I test people's
> patience with my inf
etadata are transferred together.
>> +.PP
>> +A DAX file may support being mapped with the MAP_SYNC flag, which enables a
>> +program to use CPU cache flush instructions to persist CPU store operations
>> +without an explicit
>> +.BR fsync(2).
>> +See
>> +.BR mmap(2)
>> +for more information.
>> .SH RETURN VALUE
>> On success, zero is returned.
>> On error, \-1 is returned, and
>> --
>> 2.25.1
>>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
On 9/24/20 11:35 AM, Alejandro Colomar wrote:
> Hi,
>
> On 2020-09-23 22:35, Michael Kerrisk (man-pages) wrote:
>> On 9/15/20 12:03 PM, Stefan Puiu wrote:
>>> Hi,
>>>
>>> On Fri, Sep 11, 2020 at 6:28 PM Alejandro Colomar
>>> wrote:
>>>
Hi Alex,
[..]
> I was reverting the 3 patches I introduced (they changed from solution 1
> to solution 2), and also was grepping for already existing solution 2 in
> the pages (it seems that solution 2 was a bit more extended than
> solution 1).
Just so I can refresh my cache, which commits were
ve models like the IBM
> Executive even featured true proportional type.
Thanks for the interesting history, Branden!
>From time toi time I wonder if the function prototypes in
the SYNOPSIS should also be inside .EX/.EE. Your thoughts?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
d easy to copy/paste in your code. I'd settle for easy
> enough, not perfect or completely foolproof. If you need to look up
> obscure gcc features to understand an example, that's not very
> helpful. So I'd be more inclined to prefer version 1 above. But let's
> se
Hey Christian,
Could we please have a manual page for the close_range(2) syscall
that's about to land in 5.9?
Thanks,
Michael
On Wed, 3 Jun 2020 at 12:24, Michael Kerrisk (man-pages)
wrote:
>
> Hi Christian,
>
> Could we have a manual page for this API (best before it'
1 - 100 of 1161 matches
Mail list logo
