Re: [PATCH v5 0/4] man2: udpate mm/userfaultfd manpages to latest

Hi Alex, > I applied all 4 patches (with a few minor fixes to 1/4 and 4/4 (cosmetic > fixes; some of them about the 80-col right margin)): > How big is your current queue of pending patches from other

man-pages-5.11 released

Gidday, Alex Colomar and I are proud to announce: man-pages-5.11 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from around 40 contributors. The release includes around 480 commits that changed 950 (about 90% of the) pages. With a 50k diff, this

Re: [PATCH v6] close_range.2: new page documenting close_range(2)

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: > &

Re: [PATCH v6] close_range.2: new page documenting close_range(2)

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)"

Re: [RFC v2] execve.2: SYNOPSIS: Document both glibc wrapper and kernel sycalls

Hey Alex, On 2/18/21 4:13 PM, Alejandro Colomar wrote: > Until now, the manual pages have (usually) documented only either > the glibc (or another library) wrapper for a syscall, or the > kernel syscall (this only when there's not a wrapper). > > Let's document both prototypes, which many times a

Re: [RFC] execve.2: SYNOPSIS: Document both glibc wrapper and kernel sycalls

Hi Alex, On 2/14/21 2:39 PM, Alejandro Colomar wrote: > Until now, the manual pages have (usually) documented only either > the glibc (or another library) wrapper for a syscall, or the raw > syscall (this only when there's not a wrapper). > > Let's document both prototypes, which many times are s

Re: [PATCH v3 1/1] process_madvise.2: Add process_madvise man page

Hello Suren, >> Thanks. I added a few words to clarify this.> > Any link where I can see the final version? Sure: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man2/process_madvise.2 Also rendered below. Thanks, Michael NAME process_madvise - give advice about use of

Re: [PATCH v3 1/1] process_madvise.2: Add process_madvise man page

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

Re: [PATCH v2] ipc.2: Fix prototype parameter types

Hi Alex, On 2/7/21 1:36 PM, Alejandro Colomar wrote: > The types for some of the parameters are incorrect > (different than the kernel). Fix them. > Below are shown the types that the kernel uses. Thanks. Patch applied. Cheers, Michael > .. > > .../linux$ grep_syscall ipc > ipc/syscall.c

Re: [PATCH v3 1/1] process_madvise.2: Add process_madvise man page

Hello Suren (and Minchan and Michal) Thank you for the revisions! I've applied this patch, and done a few light edits. However, I have a questions about undocumented pieces in *madvise(2)*, as well as one other question. See below. On 2/2/21 6:30 AM, Suren Baghdasaryan wrote: > Initial version

Re: [PATCH v2 1/1] process_madvise.2: Add process_madvise man page

Hello Suren, Thank you for the revisions! Just a few more comments: all pretty small stuff (many points that I overlooked the first time rround), since the page already looks pretty good by now. Again, thanks for the rendered version. As before, I've added my comments to the page source. On 1/29

Re: [PATCH v6] close_range.2: new page documenting close_range(2)

Hello Stephen, (and CHristian, please!) Thanks for your patch revision. I've merged it, and have done some light editing, but I still have a question: On 1/23/21 5:11 PM, Stephen Kitt wrote: [...] > +.SH ERRORS > +.TP > +.B EMFILE > +The per-process limit on the number of open file descriptor

Re: [PATCH 1/1] process_madvise.2: Add process_madvise man page

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

Re: [PATCH 1/1] process_madvise.2: Add process_madvise man page

Hello Suren, Thank you for writing this page! Some comments below. On Wed, 20 Jan 2021 at 21:36, Suren Baghdasaryan wrote: > > Initial version of process_madvise(2) manual page. Initial text was > extracted from [1], amended after fix [2] and more details added using > man pages of madvise(2) an

Re: [PATCH 5/5] Add manpage for fsconfig(2)

Hello David, Ping! Thanks, Michael On Mon, 24 Aug 2020 at 14:25, David Howells wrote: > > Add a manual page to document the fsconfig() system call. > > Signed-off-by: David Howells > --- > > man2/fsconfig.2 | 277 > +++ > 1 file changed,

Re: [PATCH 3/5] Add manpage for fspick(2)

Hello David, Ping! Thanks, Michael On Mon, 24 Aug 2020 at 14:25, David Howells wrote: > > Add a manual page to document the fspick() system call. > > Signed-off-by: David Howells > --- > > man2/fspick.2 | 180 > + > 1 file changed, 18

Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2)

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:

Re: [PATCH 2/5] Add manpages for move_mount(2)

Hello David, Ping! Thanks, Michael On Mon, 24 Aug 2020 at 14:24, David Howells wrote: > > Add manual pages to document the move_mount() system call. > > Signed-off-by: David Howells > --- > > man2/move_mount.2 | 267 > + > 1 file changed

Re: [PATCH 1/5] Add manpage for open_tree(2)

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).

Re: [PATCH v27 12/12] landlock: Add user and kernel documentation

Hello Mickaël, It would be great to have some manual pages for these system calls before release... Can you prepare something? Thanks, Michael On Thu, 21 Jan 2021 at 21:51, Mickaël Salaün wrote: > > From: Mickaël Salaün > > This documentation can be built with the Sphinx framework. > > Cc: Ja

Re: [PATCH] entry: Use different define for selector variable in SUD

ld be used in the two parts of the API, as is fixed in this patch by Gabriel. Acked-my: Michael Kerrisk Cheers, Michael > Cc: Linux API > Suggested-by: Michael Kerrisk (man-pages) > Signed-off-by: Gabriel Krisman Bertazi > --- > .../admin-guide/syscall-user-d

Re: [PATCH] getcpu.2: Document glibc wrapper instead of kernel syscall

Hi Alex, On 12/30/20 10:41 PM, Alejandro Colomar wrote: > The glibc wrapper doesn't provide the third argument. > Simplify the info about the (unused) kernel parameter > to the minimum that is useful. > > kernels <=2.6.23 are EOL since a long time ago. > > The old info is commented out instead o

Re: [PATCH v5] close_range.2: new page documenting close_range(2)

Hello Stephen, Thank you for your revisions! I still have a few comments. On 12/21/20 8:46 PM, Stephen Kitt wrote: > This documents close_range(2) based on information in > 278a5fbaed89dacd04e9d052f4594ffd0e0585de, > 60997c3d45d9a67daf01c56d805ae4fec37e0bd8, and > 582f1fb6b721facf04848d2ca57f3446

man-pages-5.10 is released

Gidday, For this release, Alejandro (Alex) Colomar has joined me as a comaintainer and we are proud to announce: man-pages-5.10 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from around 25 contributors. The release includes just over 150 commit

Re: [PATCH v2] close_range.2: new page documenting close_range(2)

On 12/10/20 1:24 AM, Alejandro Colomar (man-pages) wrote: > Hi Stephen, > > A few more comments below. > > Michael, please have a look at them too. > > Christian, do you have any program that you used to test the syscall > that could be added as an example program to the page? > > Thanks, > >

Re: [patch] close_range.2: new page documenting close_range(2)

On 12/9/20 10:47 AM, Alejandro Colomar (man-pages) wrote: >>> +descriptors in >>> +.B /proc/self/fd/ > > By reading proc.5, I think this should s/.B/.I/, right mtk? > >>> +and calling >>> +.BR close (2) >>> +on each one. >>> +.BR close_range () >>> +can take care of this without requiring >>> +.

Re: [patch] close_range.2: new page documenting close_range(2)

Hello Stephen Thank you for writing this page! Some comments/questions below. On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote: > > This documents close_range(2) based on information in > 278a5fbaed89dacd04e9d052f4594ffd0e0585de and > 60997c3d45d9a67daf01c56d805ae4fec37e0bd8. (Thanks for noting

Linux man-pages maintainership adjustments

Gidday, Anyone following linux-man@ in the last few months will have noticed that Alejandro (Alex) Colomar has become rather active in the project. Alex has kindly volunteered to take up some of the work of maintaining the project. In practice, that means he will be reviewing and merging some of t

Re: [PATCH] subpage_prot.2: SYNOPSIS: Fix return type: s/long/int/

Hi Alex, On 11/28/20 12:44 AM, Alejandro Colomar wrote: > The Linux kernel uses 'int' instead of 'long' for the return type. > As glibc provides no wrapper, use the same type the kernel uses. Thanks. Patch applied. Cheers, Michael > .. > > $ grep -n wrapper man-pages/man2/subpage_prot.2 >

Re: [PATCH] spu_create.2: Clarify that one of the prototypes is the current one

Hi ALex, On 11/26/20 7:32 PM, Alejandro Colomar wrote: > The current Linux kernel only provides a definition of 'spu_create()'. > It has 4 parameters, the last being 'int neighbor_fd'. > > Before Linux 2.6.23, there was an older prototype, > which didn't have this last parameter. > > Move that o

Re: [PATCH v2 2/4] x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ

Hey Dave Marin, On 11/26/20 6:44 PM, Borislav Petkov wrote: > On Thu, Nov 19, 2020 at 11:02:35AM -0800, Chang S. Bae wrote: >> Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for >> use by all architectures with sigaltstack(2). Over time, the hardware state >> size grew, but t

Re: set_thread_area.2: csky architecture undocumented

Hi Alex, On 11/23/20 10:31 PM, Alejandro Colomar (man-pages) wrote: > Hi Michael, > > SYNOPSIS >#include > >#if defined __i386__ || defined __x86_64__ ># include > >int get_thread_area(struct user_desc *u_info); >int set_thread_area(struct user_desc *u_

Re: [PATCH] set_tid_address.2: SYNOPSIS: Fix set_tid_address() return type

Hi Alex, On 11/23/20 10:59 PM, Alejandro Colomar wrote: > The Linux kernel uses 'pid_t' instead of 'long' for the return type. > As glibc provides no wrapper, use the same types the kernel uses. > > $ sed -n 34,36p man-pages/man2/set_tid_address.2 > .PP > .IR Note : > There is no glibc wrapper fo

Re: [PATCH] restart_syscall.2: SYNOPSIS: Fix restart_syscall() return type

Hi Alex, On 11/23/20 9:34 PM, Alejandro Colomar wrote: > The Linux kernel uses 'long' instead of 'int' for the return type. > As glibc provides no wrapper, use the same types the kernel uses. > > $ grep -rn 'SYSCALL_DEFINE.*(restart_syscall' > kernel/signal.c:2891:SYSCALL_DEFINE0(restart_syscall)

Re: set_thread_area.2: csky architecture undocumented

Hello Alex, On Mon, 23 Nov 2020 at 22:31, Alejandro Colomar (man-pages) wrote: > > Hi Michael, > > SYNOPSIS >#include > >#if defined __i386__ || defined __x86_64__ ># include > >int get_thread_area(struct user_desc *u_info); >int set_thread_area(struct us

Re: [PATCH] lseek.2: SYNOPSIS: Use correct types

Hi Alex, On Sat, 21 Nov 2020 at 18:45, Alejandro Colomar (man-pages) wrote: > > Hi Michael, > > I'm a bit lost in all the *lseek* pages. > > You had a good read some months ago, so you may know it better. > I don't know which of those functions come from the kernel, > and which come from glibc (i

Re: [PATCH] lseek.2: SYNOPSIS: Use correct types

[Adding libc-alpha@ here, so someone might correct me if I make a misstep] Hello Alex, On Sat, 21 Nov 2020 at 18:34, Alejandro Colomar wrote: > > The Linux kernel uses 'unsigned int' instead of 'int' > for 'fd' and 'whence'. > As glibc provides no wrapper, use the same types the kernel uses. I

Re: For review: seccomp_user_notif(2) manual page [v2]

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

man-pages-5.09 is released

Gidday, The Linux man-pages maintainer proudly announces: man-pages-5.09 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from more than 40 people, with just over 500 commits making changes to nearly 600 pages. Nine new pages have been added (six o

Re: For review: seccomp_user_notif(2) manual page [v2]

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

Re: For review: seccomp_user_notif(2) manual page [v2]

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

Re: For review: seccomp_user_notif(2) manual page [v2]

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

Re: For review: seccomp_user_notif(2) manual page [v2]

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 >

Re: [PATCH 2/2] futex.2: Use appropriate types

Hi Alex, On 10/30/20 2:46 PM, Alejandro Colomar wrote: > BTW, apparently the kernel doesn't use 'const' for 'utime' > ('timeout' in the manual page), > but effectively, it doesn't modify it, AFAICS. > > Should the kernel use 'const'? > Is there a reason for the kernel not using 'const'? > Should

Re: [PATCH 1/2] futex.2: srcfix

On 10/30/20 1:39 PM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar Hi Alex, I've applied this patch, but would prefer to avoid such patches in the future. Nothing is actually broken in the old version, so I tend to regard such patches as unnecessary chur,. Thanks, Michael > ---

Re: [PATCH 2/2] futex.2: Use appropriate types

On 10/30/20 1:39 PM, Alejandro Colomar wrote: > The Linux kernel uses the following: > > kernel/futex.c:3778: > SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val, > struct __kernel_timespec __user *, utime, u32 __user *, uaddr2, > u32, val3) > > Since there

Re: For review: seccomp_user_notif(2) manual page [v2]

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

Re: For review: seccomp_user_notif(2) manual page [v2]

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

Re: [PATCH v3] getdents.2: Use appropriate types

On 10/29/20 3:10 PM, Alejandro Colomar wrote: > getdents(): > This function has no glibc wrapper. > As such, we should use the same types the Linux kernel uses: > Use 'long' as the return type. > > getdents64(): > The glibc wrapper uses: > ssize_t getdents64(int, void *, size_t); > > Signed-off-b

Re: For review: seccomp_user_notif(2) manual page [v2]

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

Re: For review: seccomp_user_notif(2) manual page [v2]

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

Re: [PATCH v2] getdents.2: Use appropriate types

Hi Alex, On Thu, 29 Oct 2020 at 14:42, Alejandro Colomar wrote: > > getdents(): > This function has no glibc wrapper. > As such, we should use the same types the Linux kernel uses: > Use 'long' as the return type. > > getdents64(): > The glibc wrapper uses ssize_t for the return type, > and 'size

Re: [PATCH v2] perf_event_open.2: update the man page with CAP_PERFMON related information

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

Re: [PATCH v2] perf_event_open.2: update the man page with CAP_PERFMON related information

Hello Alexey, On 10/27/20 5:48 PM, Alexey Budankov wrote: > > Extend perf_event_open 2 man page with the information about > CAP_PERFMON capability designed to secure performance monitoring > and observability operation in a system according to the principle > of least privilege [1] (POSIX IEEE 1

Re: [PATCH 1/2] system_data_types.7: Add 'off_t'

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

Re: [PATCH 1/2] system_data_types.7: Add 'off_t'

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

Inconsistent capability requirements for prctl_set_mm_exe_file()

Hello Nicolas, Cyrill, and others, @Nicolas, your commit ebd6de6812387a changed the capability requirements for the prctl_set_mm_exe_file() operation from ns_capable(CAP_SYS_ADMIN) to ns_capable(CAP_SYS_ADMIN) || ns_capable(CAP_CHECKPOINT_RESTORE). That's fine I guess, but while looki

Re: [PATCH v1] perf_event_open.2: update the man page with CAP_PERFMON related information

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page [v2]

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

For review: seccomp_user_notif(2) manual page [v2]

Hi all (and especially Tycho and Sargun), Following review comments on the first draft (thanks to Jann, Kees, Christian and Tycho), I've made a lot of changes to this page. I've also added a few FIXMEs relating to outstanding API issues. I'd like a second pass review of the page before I release i

Re: For review: seccomp_user_notif(2) manual page

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: > [...] >>>>

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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: >

Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2)

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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

Re: Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs

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

Re: Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs

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

Re: Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs

[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

Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs

Hello Linus, Between Linux 5.4 and 5.5 a regression was introduced in the operation of the epoll EPOLLET flag. From some manual bisecting, the regression appears to have been introduced in commit 1b6b26ae7053e4914181eedf70f2d92c12abda8a Author: Linus Torvalds Date: S

Re: [PATCH 2/2] off_t.3: New link to system_data_types(7)

On 10/6/20 12:12 AM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar Thanks, Alex. Patch applied. Cheers, Michael > --- > man3/off_t.3 | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 man3/off_t.3 > > diff --git a/man3/off_t.3 b/man3/off_t.3 > new file mode 100644 >

Re: [PATCH 1/2] system_data_types.7: Add 'off_t'

On 10/6/20 12:12 AM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar Hi Alex, Thanks, patch applied. And I trimmed the "See also" a little. I'd hold off on documenting loff_t and off64_t for the moment. As you note in another mail, the *lseek* man page situation is a bit of a mess.

Re: Navigational corrections

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

Re: [PATCH v4 1/2] system_data_types.7: Add 'void *'

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

Re: Navigational corrections

Hi Alex, > > > > The question of 'void *' is an interesting one. It is something > > like a fundamental C type, and not something that comes from POSIX. > > But, it does appear in POSIX APIs and often details of using > > the type are not well understood. So, as a matter of practicality, >

Re: [PATCH v5 2/2] void.3: New link to system_data_types(7)

Hello Alex, On 10/2/20 9:28 PM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar Patch applied. And, I think we're now at a sync point. Thanks, Michael > --- > man3/void.3 | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 man3/void.3 > > diff --git a/man3/void.3 b/m

Re: [PATCH v5 1/2] system_data_types.7: Add 'void *'

Hello Alex, On 10/2/20 9:28 PM, Alejandro Colomar wrote: > Signed-off-by: Alejandro Colomar Patch applied. Thanks, Michael > system_data_types.7: void *: Add info about generic function parameters and > return value > > Reported-by: Paul Eggert > Reported-by: David Laight > Signed-off-by

Navigational corrections (was: Re: [PATCH v2 1/2] system_data_types.7: Add 'void *')

n Wakely wrote: >>> > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) >>> > wrote: >>> >> >>> >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely >>> wrote: >>> >>> >>> >>> On Fri, 2 Oct

Re: [PATCH v4 1/2] system_data_types.7: Add 'void *'

On 10/2/20 10:27 PM, Alejandro Colomar wrote: > Hi Paul, > > On 2020-10-02 22:14, Paul Eggert wrote: > > On 10/2/20 11:38 AM, Alejandro Colomar wrote: > > > >> .I void * > >> > >> renders with a space in between. > > > > That's odd, as "man(7)" says "All of the arguments will be printed nex

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

Hi Alex, On 10/2/20 10:48 AM, Alejandro Colomar wrote: > Hi Michael, > > On 2020-10-02 10:24, Alejandro Colomar wrote: >> On 2020-10-01 19:32, Paul Eggert wrote: >> > For 'void *' you should also mention that one cannot use arithmetic on >> > void * pointers, so they're special in that way too.

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote: > > On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc > wrote: > > However, it might be good that someone starts a page called > > 'type_qualifiers(7)' or something like that. > > Who is this for? Who is trying to learn C from man pages? S

Re: For review: seccomp_user_notif(2) manual page

On 10/1/20 3:52 AM, Jann Horn wrote: [...] > I guess this is a nice point in favor of Michael's usual complaint > that if there are no man pages for a feature by the time the feature > lands upstream, there's a higher chance that the UAPI will suck > forever... Thanks for saving me the trouble o

Re: For review: seccomp_user_notif(2) manual page

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

Re: For review: seccomp_user_notif(2) manual page

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

For review: seccomp_user_notif(2) manual page

Hi Tycho, Sargun (and all), I knew it would be a big ask, but below is kind of the manual page I was hoping you might write [1] for the seccomp user-space notification mechanism. Since you didn't (and because 5.9 adds various new pieces such as SECCOMP_ADDFD_FLAG_SETFD and SECCOMP_IOCTL_NOTIF_ADD

Re: [PATCH 12/24] getgrent_r.3: Use sizeof() to get buffer size (instead of hardcoding macro name)

> 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

Re: [PATCH 22/24] membarrier.2: Note that glibc does not provide a wrapper

On 9/27/20 10:05 PM, Alejandro Colomar wrote: > Hi Branden, > > * G. Branden Robinson via linux-man: > > 1) > > > .EX > > .B int fstat(int \c > > .IB fd , \~\c > > .B struct stat *\c > > .IB statbuf ); > > .EE > > 2) > > > .EX > > .BI "int fstat(int " fd ", struct stat *" statbuf ); >

Re: [PATCH 22/24] membarrier.2: Note that glibc does not provide a wrapper

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

Re: [PATCH] man/statx: Add STATX_ATTR_DAX

Hello Ira, On 9/28/20 6:42 PM, Ira Weiny wrote: > On Mon, May 04, 2020 at 05:20:16PM -0700, 'Ira Weiny' wrote: >> From: Ira Weiny >> >> Linux 5.8 is slated to have STATX_ATTR_DAX support. >> >> https://lore.kernel.org/lkml/20200428002142.404144-4-ira.we...@intel.com/ >> https://lore.kernel.org/lk

Re: [PATCH 12/24] getgrent_r.3: Use sizeof() to get buffer size (instead of hardcoding macro name)

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: >>>

Re: [PATCH 12/24] getgrent_r.3: Use sizeof() to get buffer size (instead of hardcoding macro name)

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

Re: [PATCH 22/24] membarrier.2: Note that glibc does not provide a wrapper

Hi Branden, On 9/21/20 4:36 PM, G. Branden Robinson wrote: > At 2020-09-11T12:58:08+, Walter Harms wrote: >> the groff commands are ducument in man 7 groff >> .nf No filling or adjusting of output-lines. >> .fi Fill output lines >> >> (for me) a typical use is like this: >> .nf >>

Re: [PATCH 12/24] getgrent_r.3: Use sizeof() to get buffer size (instead of hardcoding macro name)

On 9/15/20 12:03 PM, Stefan Puiu wrote: > Hi, > > On Fri, Sep 11, 2020 at 6:28 PM Alejandro Colomar > wrote: >> >> Hi Stefan, >> >> On 2020-09-11 16:35, Stefan Puiu wrote: >> > Hi, >> > >> > On Fri, Sep 11, 2020 at 12:15 AM Alejandro Colomar >> > wrote: >> >> >> >> Signed-off-by: Alejandro

Re: [PATCH v5 1/3] open: add close_range()

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   2   3   4   5   6   7   8   9   10   >