Re: [REPOST][RFC][PATCH] sysctl: Remove the sysctl system call

On 10/3/19 11:05 PM, Kees Cook wrote: > On Thu, Oct 03, 2019 at 03:44:32PM -0500, Eric W. Biederman wrote: >> >> This system call has been deprecated almost since it was introduced, and none >> of the common distributions enable it. The only indication that I can find >> that >> anyone might

Re: pivot_root(".", ".") and the fchdir() dance

Hello Eric, On 9/30/19 2:42 PM, Eric W. Biederman wrote: "Michael Kerrisk (man-pages)" writes: Hello Eric, A ping on my question below. Could you take a look please? Thanks, Michael The concern from our conversation at the container mini-summit was that there is a pathology

Re: pivot_root(".", ".") and the fchdir() dance

Hello Eric, A ping on my question below. Could you take a look please? Thanks, Michael The concern from our conversation at the container mini-summit was that there is a pathology if in your initial mount namespace all of the mounts are marked MS_SHARED like systemd does (and is

Re: For review: pidfd_send_signal(2) manual page

Hello Christian, On 9/25/19 3:53 PM, Christian Brauner wrote: > On Wed, Sep 25, 2019 at 03:46:26PM +0200, Michael Kerrisk (man-pages) wrote: >> On 9/24/19 11:53 PM, Christian Brauner wrote: >>> On Tue, Sep 24, 2019 at 11:00:03PM +0200, Michael Kerrisk (man-pages) wrote: &g

Re: For review: pidfd_send_signal(2) manual page

On 9/25/19 3:51 PM, Florian Weimer wrote: > * Michael Kerrisk: > >>If these conditions don't hold true, then the child process should >>instead be created using clone(2) with the CLONE_PID flag. > > I think this should be CLONE_PIDFD. Thanks Florian. Fixed. Cheers, Michael

Re: For review: pidfd_send_signal(2) manual page

On 9/24/19 11:53 PM, Christian Brauner wrote: > On Tue, Sep 24, 2019 at 11:00:03PM +0200, Michael Kerrisk (man-pages) wrote: >> Hello Christian, >> >>>>> If you're the parent of the process you can do this without CLONE_PIDFD: >>>>> pid =

Re: For review: pidfd_send_signal(2) manual page

Hello Daniel, On 9/24/19 11:08 PM, Daniel Colascione wrote: > On Tue, Sep 24, 2019 at 2:00 PM Michael Kerrisk (man-pages) > wrote: >> >> Hello Christian, >> >>>>> If you're the parent of the process you can do this without CLONE_PIDFD: >>>>&g

Re: For review: pidfd_send_signal(2) manual page

Hello Christian, >>> If you're the parent of the process you can do this without CLONE_PIDFD: >>> pid = fork(); >>> pidfd = pidfd_open(); >>> ret = pidfd_send_signal(pidfd, 0, NULL, 0); >>> if (ret < 0 && errno == ESRCH) >>> /* pidfd refers to another, recycled process */ >> >> Although there

Re: For review: pidfd_send_signal(2) manual page

Hello Christian, On 9/23/19 4:23 PM, Christian Brauner wrote: > On Mon, Sep 23, 2019 at 01:26:34PM +0200, Florian Weimer wrote: >> * Michael Kerrisk: >> >>> SYNOPSIS >>>int pidfd_send_signal(int pidfd, int sig, siginfo_t info, >>> unsigned int flags); >> >>

Re: For review: pidfd_send_signal(2) manual page

Hello Florian, On 9/23/19 1:26 PM, Florian Weimer wrote: > * Michael Kerrisk: > >> SYNOPSIS >>int pidfd_send_signal(int pidfd, int sig, siginfo_t info, >> unsigned int flags); > > This probably should reference a header for siginfo_t. Thanks. I added:

Re: For review: pidfd_send_signal(2) manual page

On 9/23/19 1:31 PM, Daniel Colascione wrote: > On Mon, Sep 23, 2019 at 2:12 AM Michael Kerrisk (man-pages) > wrote: >>The pidfd_send_signal() system call allows the avoidance of race >>conditions that occur when using traditional interfaces (such a

Re: For review: pidfd_send_signal(2) manual page

On 9/23/19 11:27 PM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Christian and all, >> >> Below, I have the rendered version of the current draft of >> the pidfd_send_signal(2) manual page that I have written. >>

Re: For review: pidfd_open(2) manual page

Hello Florian, On 9/23/19 10:41 PM, Florian Weimer wrote: > * Michael Kerrisk: > static int pidfd_open(pid_t pid, unsigned int flags) { return syscall(__NR_pidfd_open, pid, flags); } >>> >>> Please call this function something else

Re: For review: pidfd_send_signal(2) manual page

Hello Christian, On 9/23/19 4:29 PM, Christian Brauner wrote: > On Mon, Sep 23, 2019 at 11:12:00AM +0200, Michael Kerrisk (man-pages) wrote: >> Hello Christian and all, >> >> Below, I have the rendered version of the current draft of >> the pidfd_send_signal(2) manu

Re: For review: pidfd_open(2) manual page

Hello Daniel, Than you for reviewing the page! On 9/23/19 1:26 PM, Daniel Colascione wrote: > On Mon, Sep 23, 2019 at 3:53 AM Florian Weimer wrote: >> >> * Michael Kerrisk: >> >>> SYNOPSIS >>>int pidfd_open(pid_t pid, unsigned int flags); >> >> Should this mention for pid_t? >> >>>

Re: For review: pidfd_open(2) manual page

Hello Christian, On 9/23/19 4:47 PM, Christian Brauner wrote: > On Mon, Sep 23, 2019 at 12:53:09PM +0200, Florian Weimer wrote: >> * Michael Kerrisk: >> >>> SYNOPSIS >>>int pidfd_open(pid_t pid, unsigned int flags); >> >> Should this mention for pid_t? >> >>> ERRORS >>>EINVAL

Re: For review: pidfd_open(2) manual page

Hello Christian, On 9/23/19 4:38 PM, Christian Brauner wrote: > On Mon, Sep 23, 2019 at 11:11:53AM +0200, Michael Kerrisk (man-pages) wrote: >> Hello Christian and all, >> >> Below, I have the rendered version of the current draft of >> the pidfd_open(2) manu

Re: For review: pidfd_open(2) manual page

Hello Florian, Thanks for taking a look at this page. On 9/23/19 12:53 PM, Florian Weimer wrote: > * Michael Kerrisk: > >> SYNOPSIS >>int pidfd_open(pid_t pid, unsigned int flags); > > Should this mention for pid_t? Seems reasonable. I added this. >> ERRORS >>EINVAL flags is

For review: rewritten pivot_root(2) manual page

Hello all, I'm looking for review input for the pivot_root(2) manual page, which I have substantially rewritten. The original page was written 19 years ago, and has seen little revision since that time. It contains a number of errors. Even at the time it was first released, the manual page

Re: pivot_root(".", ".") and the fchdir() dance

Hello Eric, On 9/15/19 8:17 PM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Eric, >> >> On 9/11/19 1:06 AM, Eric W. Biederman wrote: >>> "Michael Kerrisk (man-pages)" writes: >>> >>&

For review: pidfd_send_signal(2) manual page

Hello Christian and all, Below, I have the rendered version of the current draft of the pidfd_send_signal(2) manual page that I have written. The page source can be found in a Git branch at: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=draft_pidfd I would be pleased to

For review: pidfd_open(2) manual page

Hello Christian and all, Below, I have the rendered version of the current draft of the pidfd_open(2) manual page that I have written. The page source can be found in a Git branch at: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=draft_pidfd I would be pleased to receive

Re: pivot_root(".", ".") and the fchdir() dance

Hello Eric, On 9/11/19 1:06 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Christian, >> >>>> All: I plan to add the following text to the manual page: >>>> >>>>new_root and put_old may be

Re: pivot_root(".", ".") and the fchdir() dance

Hello Christian, >> All: I plan to add the following text to the manual page: >> >>new_root and put_old may be the same directory. In particular, >>the following sequence allows a pivot-root operation without need‐ >>ing to create and remove a temporary directory: >>

Re: pivot_root(".", ".") and the fchdir() dance

Hello Eric, On 9/10/19 1:40 AM, Eric W. Biederman wrote: [...] >>> I have just spotted this conversation and I expect if you are going >>> to use this example it is probably good to document what is going >>> on so that people can follow along. >> >> (Sounds reasonable.) >> > chdir(rootfs)

Re: pivot_root(".", ".") and the fchdir() dance

Hello Eric, Thanks for chiming in; I should have thought to CC you at the start. I have a question or two, below. On Mon, 9 Sep 2019 at 12:40, Eric W. Biederman wrote: > > "Michael Kerrisk (man-pages)" writes: > > > Hello Philipp, > > > > On Tue, 6 Aug

Re: pivot_root(".", ".") and the fchdir() dance

Hello Aleksa, On 8/5/19 3:37 PM, Aleksa Sarai wrote: > On 2019-08-05, Michael Kerrisk (man-pages) wrote: >> On 8/5/19 12:36 PM, Aleksa Sarai wrote: >>> On 2019-08-01, Michael Kerrisk (man-pages) wrote: >>>> I'd like to add some documentation about the pivot_root(&

Re: pivot_root(".", ".") and the fchdir() dance

Hello Philipp, On Tue, 6 Aug 2019 at 10:12, Philipp Wendler wrote: > > Hello Michael, hello Aleksa, > > Am 05.08.19 um 14:29 schrieb Michael Kerrisk (man-pages): > > > On 8/5/19 12:36 PM, Aleksa Sarai wrote: > >> On 2019-08-01, Michael Kerrisk (man-pages) wro

Re: pivot_root(".", ".") and the fchdir() dance

[CC += Werner Almesberger, original author of both the system call and the manual page.] Hello Aleksa, Thank you for your responses. See below. On 8/5/19 12:36 PM, Aleksa Sarai wrote: > On 2019-08-01, Michael Kerrisk (man-pages) wrote: >> I'd like to add some documentat

man-pages-5.02 is released

Gidday, The Linux man-pages maintainer proudly announces: man-pages-5.02 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from 28 people, with around 120 commits making changes to over 50 pages. Tarball download:

Re: [patch] setxattr.2: Add ERANGE to 'ERRORS' section

Hello Finn, On 7/31/19 9:53 PM, Finn O'Leary wrote: > Hi, > > Both the Ext2 filesystem handler and the Ext4 filesystem handler will > return the ERANGE error code. Ext2 will return it if the name or value > is > too long to be able to be stored, Ext4 will return it if the name is too > long.

pivot_root(".", ".") and the fchdir() dance

Hi Serge, Andy, et al, I've been looking at doing some updates for the rather inaccurate pivot_root(2) manual page, and I noticed this 2014 commit in LXC [[commit 2d489f9e87fa0cccd8a1762680a43eeff2fe1b6e Author: Serge Hallyn Date: Sat Sep 20 03:15:44 2014 + pivot_root: switch to a

Re: Error (?) in man page for ppoll(2)

>> +The timeout value expressed in >> +.IR *ip >> +is invalid (nragtive). > ^^^ > > Typo. Otherwise, I approve of the patch. Thanks! Fixed. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming

Re: Error (?) in man page for ppoll(2)

Hello Alan, On 7/21/19 5:32 PM, Alan Stern wrote: > Here are two extracts from the man page for ppoll(2) (from the > man-pages 4.16 package; the 5.01 version is the same): > >Specifying a negative value in timeout means an infinite timeout. > > >Other than the difference in the

man-pages-5.01 is released

Gidday, The Linux man-pages maintainer proudly announces: man-pages-5.01 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from just over 20 people, with just over 70 commits making changes to around 40 pages. Tarball download:

Re: [PATCH 1/2] splice.2: Note EAGAIN can occur when called on nonblocking file descriptors

Hello Slavomir, On 4/12/19 9:02 AM, Slavomir Kaslev wrote: Signed-off-by: Slavomir Kaslev Thanks! Applied. Cheers, Michael --- man2/splice.2 | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/man2/splice.2 b/man2/splice.2 index 57988d9d6..af3fa4e74 100644 ---

Re: [PATCH 2/2] tee.2: Note EAGAIN can occur when called on nonblocking file descriptors

Hello again Slavomir, On 4/12/19 9:02 AM, Slavomir Kaslev wrote: Signed-off-by: Slavomir Kaslev Thanks! Applied. Cheers, Michael --- man2/tee.2 | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/man2/tee.2 b/man2/tee.2 index 7bb0d3a31..03d043b46 100644 ---

man-pages-5.00 is released

Gidday, After a long gap, the Linux man-pages maintainer proudly announces: man-pages-5.00 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from around 130 contributors. More than 600 commits changed near 400 pages. 3 new pages were added, and

Re: [PATCH 2/2] seccomp.2: document userspace notification

On 3/1/19 4:19 PM, Tycho Andersen wrote: > On Fri, Mar 01, 2019 at 04:16:27PM +0100, Michael Kerrisk (man-pages) wrote: >> Hello Tycho, >> >> On 3/1/19 3:53 PM, Tycho Andersen wrote: >>> On Thu, Feb 28, 2019 at 01:52:19PM +0100, Michael Kerrisk (man-pages) wrote: >

Re: [PATCH 2/2] seccomp.2: document userspace notification

Hello Tycho, On 3/1/19 3:53 PM, Tycho Andersen wrote: > On Thu, Feb 28, 2019 at 01:52:19PM +0100, Michael Kerrisk (man-pages) wrote: >>> +a notification will be sent to this fd. See "Userspace Notification" below >>> for >> >> s/fd/file descriptor/ th

Re: [PATCH 2/2] seccomp.2: document userspace notification

On 3/1/19 3:53 PM, Tycho Andersen wrote: > On Thu, Feb 28, 2019 at 02:25:55PM +0100, Michael Kerrisk (man-pages) wrote: >>> 7. The monitoring process can use the information in the >>>'struct seccomp_notif' to make a determination about the >>>system call be

Re: [PATCH 2/2] seccomp.2: document userspace notification

> 7. The monitoring process can use the information in the >'struct seccomp_notif' to make a determination about the >system call being made by the target process. This >structure includes a 'data' field that is the same >'struct seccomp_data' that is passed to a BPF filter. > >

Re: [PATCH 2/2] seccomp.2: document userspace notification

[widening CC to the same scope as the code patches] Hello Tycho, Sorry for the late response on this. Could you amend/rebase your patches in light of the below please. And anyone's comment on my "big picture" text at the foot of this mail would be very welcome. On 12/13/18 1:11 AM, Tycho

Re: [PATCH man-pages] Add rseq manpage

On 12/6/18 3:42 PM, Mathieu Desnoyers wrote: > [ Michael, rseq(2) was merged into 4.18. Can you have a look at this > patch which adds rseq documentation to the man-pages project ? ] Hi Matthieu Sorry for the long delay. I've merged this page into a private branch and have done quite a lot of

Re: [PATCH] ptrace.2: Improve clarity for multi-threaded tracers

Hi Niklas, Do you plan to revise this patch in the light of Dmitry's comments? Thanks, Michael On Sun, 17 Feb 2019 at 23:15, Dmitry V. Levin wrote: > > Hi, > > On Sun, Feb 17, 2019 at 05:34:46PM +0100, Niklas Hambüchen wrote: > > Until now, the man page said: > > > > Attachment and

Re: [PATCH] procfd_signal.2: document procfd_signal syscall

Hello Christian, On 11/19/18 11:32 AM, Christian Brauner wrote: > Signed-off-by: Christian Brauner > --- > Changelog: > v1: > - patch introduced > --- > man2/procfd_signal.2 | 147 +++ > 1 file changed, 147 insertions(+) > create mode 100644

Re: [PATCH] procfd_signal.2: document procfd_signal syscall

Hello Christian, On 11/19/18 11:32 AM, Christian Brauner wrote: > Signed-off-by: Christian Brauner > --- > Changelog: > v1: > - patch introduced > --- > man2/procfd_signal.2 | 147 +++ > 1 file changed, 147 insertions(+) > create mode 100644

Re: Official Linux system wrapper library?

On 11/11/18 9:17 AM, Willy Tarreau wrote: > On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: >> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a >> longstanding example. > > This one was a sad read and shows that applications will

Re: Official Linux system wrapper library?

On 11/11/18 9:17 AM, Willy Tarreau wrote: > On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: >> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a >> longstanding example. > > This one was a sad read and shows that applications will

Re: Official Linux system wrapper library?

[adding in glibc folk for comment] On 11/10/18 7:52 PM, Daniel Colascione wrote: > Now that glibc is basically not adding any new system call wrappers, > how about publishing an "official" system call glue library as part of > the kernel distribution, along with the uapi headers? I don't think >

Re: Official Linux system wrapper library?

[adding in glibc folk for comment] On 11/10/18 7:52 PM, Daniel Colascione wrote: > Now that glibc is basically not adding any new system call wrappers, > how about publishing an "official" system call glue library as part of > the kernel distribution, along with the uapi headers? I don't think >

Cgroups v2 bug: incorrect reporting in "domain threaded" cgroup.procs file

Hello Tejun, I've discovered what looks to be a bug in the reporting of PIDs in the cgroup.procs file in the "domain threaded" node at the root of a threaded subtree. The following demo is on vanilla kernel 4.19. Suppose we have the following multithreaded process: $ ps -L 654 PID LWP TTY

Cgroups v2 bug: incorrect reporting in "domain threaded" cgroup.procs file

Hello Tejun, I've discovered what looks to be a bug in the reporting of PIDs in the cgroup.procs file in the "domain threaded" node at the root of a threaded subtree. The following demo is on vanilla kernel 4.19. Suppose we have the following multithreaded process: $ ps -L 654 PID LWP TTY

Re: [PATCH -next v2 0/3] sysvipc: introduce STAT_ANY commands

Hello Davidlohr, On 3/20/18 7:55 PM, Davidlohr Bueso wrote: > On Thu, 15 Feb 2018, Davidlohr Bueso wrote: > >> Once (if) merged, I will submit the necesary manpage updates. But I'm >> thinking something like: > > Hi Michael, here are the updated manpage entries. As always, please feel > free to

Re: [PATCH -next v2 0/3] sysvipc: introduce STAT_ANY commands

Hello Davidlohr, On 3/20/18 7:55 PM, Davidlohr Bueso wrote: > On Thu, 15 Feb 2018, Davidlohr Bueso wrote: > >> Once (if) merged, I will submit the necesary manpage updates. But I'm >> thinking something like: > > Hi Michael, here are the updated manpage entries. As always, please feel > free to

Re: Cgroup v2 thread mode oddity: "domain invalid" cgroup with threaded controller enabled

Hi Tejun On Wed, 17 Oct 2018 at 18:20, Tejun Heo wrote: > > Hello, Michael. > > Sorry about the delay. > > On Thu, Oct 04, 2018 at 09:40:57PM +0200, Michael Kerrisk (man-pages) wrote: > > This seems odd. x/y is now of "domain invalid" type with a contr

Re: Cgroup v2 thread mode oddity: "domain invalid" cgroup with threaded controller enabled

Hi Tejun On Wed, 17 Oct 2018 at 18:20, Tejun Heo wrote: > > Hello, Michael. > > Sorry about the delay. > > On Thu, Oct 04, 2018 at 09:40:57PM +0200, Michael Kerrisk (man-pages) wrote: > > This seems odd. x/y is now of "domain invalid" type with a contr

Re: Cgroup v2 thread mode oddity: "domain invalid" cgroup with threaded controller enabled

Hello Tejun, A ping on the below... Thanks, Michael On 10/04/2018 09:40 PM, Michael Kerrisk (man-pages) wrote: > Hello Tejun, > > Suppose we have the following scenario: > > x [d](pids) > y [dt](pids) > p [t] > q [t] > r [t]

Re: Cgroup v2 thread mode oddity: "domain invalid" cgroup with threaded controller enabled

Hello Tejun, A ping on the below... Thanks, Michael On 10/04/2018 09:40 PM, Michael Kerrisk (man-pages) wrote: > Hello Tejun, > > Suppose we have the following scenario: > > x [d](pids) > y [dt](pids) > p [t] > q [t] > r [t]

Cgroup v2 thread mode oddity: "domain invalid" cgroup with threaded controller enabled

Hello Tejun, Suppose we have the following scenario: x [d](pids) y [dt](pids) p [t] q [t] r [t] z [d] Here, x/y is a "domain threaded root" with a threaded controller (the 'pids' controller) enabled. (In this scenario, there are no member processes in any

Cgroup v2 thread mode oddity: "domain invalid" cgroup with threaded controller enabled

Hello Tejun, Suppose we have the following scenario: x [d](pids) y [dt](pids) p [t] q [t] r [t] z [d] Here, x/y is a "domain threaded root" with a threaded controller (the 'pids' controller) enabled. (In this scenario, there are no member processes in any

Re: Cgroup v2 bug: "domain invalid" node can't be converted to "threaded"

Hello Tejun, On 10/04/2018 08:20 PM, Tejun Heo wrote: > Hello, > > On Thu, Oct 04, 2018 at 08:14:55PM +0200, Michael Kerrisk (man-pages) wrote: >> On 10/02/2018 11:07 PM, Tejun Heo wrote: >>> Hello, Michael. >>> >>> Great catch. Can you pleas

Re: Cgroup v2 bug: "domain invalid" node can't be converted to "threaded"

Hello Tejun, On 10/04/2018 08:20 PM, Tejun Heo wrote: > Hello, > > On Thu, Oct 04, 2018 at 08:14:55PM +0200, Michael Kerrisk (man-pages) wrote: >> On 10/02/2018 11:07 PM, Tejun Heo wrote: >>> Hello, Michael. >>> >>> Great catch. Can you pleas

Re: Cgroup v2 bug: "domain invalid" node can't be converted to "threaded"

p/a/b/c/cgroup.type > sh: echo: write error: Operation not supported > > This patch fixes the problem by > > * Moving the opencoded ->dom_cgrp save and restoration in > cgroup_enable_threaded() into cgroup_{save|restore}_control() so > that mulitple cgrou

Re: Cgroup v2 bug: "domain invalid" node can't be converted to "threaded"

p/a/b/c/cgroup.type > sh: echo: write error: Operation not supported > > This patch fixes the problem by > > * Moving the opencoded ->dom_cgrp save and restoration in > cgroup_enable_threaded() into cgroup_{save|restore}_control() so > that mulitple cgrou

Re: [PATCH v7 0/6] seccomp trap to userspace

Hi Kees, On Sat, 29 Sep 2018 at 00:35, Kees Cook wrote: > > On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages) > wrote: > > Hi Tycho, > > > > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: > >> > >> On Fri, Sep 28, 2018 at

Re: [PATCH v7 0/6] seccomp trap to userspace

Hi Kees, On Sat, 29 Sep 2018 at 00:35, Kees Cook wrote: > > On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages) > wrote: > > Hi Tycho, > > > > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: > >> > >> On Fri, Sep 28, 2018 at

Re: [PATCH v7 0/6] seccomp trap to userspace

Hi Tycho, On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: > > On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: > > Hi Tycho, > > > > On 09/27/2018 05:11 PM, Tycho Andersen wrote: > > > Hi all, > > > > > > Here's v7 of the seccomp trap to userspace set. There are

Re: [PATCH v7 0/6] seccomp trap to userspace

Hi Tycho, On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: > > On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: > > Hi Tycho, > > > > On 09/27/2018 05:11 PM, Tycho Andersen wrote: > > > Hi all, > > > > > > Here's v7 of the seccomp trap to userspace set. There are

Cgroup v2 bug: "domain invalid" node can't be converted to "threaded"

Hello Tejun, While experimenting with cgroups, we've found what looks to be a bug. I eventually simplified this to what I think are the minimum steps to demonstrate the issue. The following shell session demonstrates the issue: [Kernel was booted with cgroup_no_v1=all] # cd

Cgroup v2 bug: "domain invalid" node can't be converted to "threaded"

Hello Tejun, While experimenting with cgroups, we've found what looks to be a bug. I eventually simplified this to what I think are the minimum steps to demonstrate the issue. The following shell session demonstrates the issue: [Kernel was booted with cgroup_no_v1=all] # cd

man-pages-4.16 is released

Gidday, The Linux man-pages maintainer proudly announces: man-pages-4.16 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from 29 contributors. Around 160 commits changed 62 pages. Tarball download:

man-pages-4.16 is released

Gidday, The Linux man-pages maintainer proudly announces: man-pages-4.16 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from 29 contributors. Around 160 commits changed 62 pages. Tarball download:

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

Jann, Micha, On 04/16/2018 11:11 PM, Michal Hocko wrote: > On Mon 16-04-18 22:17:40, Jann Horn wrote: >> On Mon, Apr 16, 2018 at 9:57 PM, Michal Hocko wrote: >>> On Mon 16-04-18 21:30:09, Jann Horn wrote: On Mon, Apr 16, 2018 at 9:18 PM, Michal Hocko

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

Jann, Micha, On 04/16/2018 11:11 PM, Michal Hocko wrote: > On Mon 16-04-18 22:17:40, Jann Horn wrote: >> On Mon, Apr 16, 2018 at 9:57 PM, Michal Hocko wrote: >>> On Mon 16-04-18 21:30:09, Jann Horn wrote: On Mon, Apr 16, 2018 at 9:18 PM, Michal Hocko wrote: >>> [...] > Yes, reasonably

Re: [PATCH RFC v5] pidns: introduce syscall translate_pid

On 04/05/2018 09:02 AM, Konstantin Khlebnikov wrote: > On 05.04.2018 01:29, Eric W. Biederman wrote: >> Nagarathnam Muthusamy writes: >> >>> On 04/04/2018 12:11 PM, Konstantin Khlebnikov wrote: Each process have different pids, one for each pid namespace it

Re: [PATCH RFC v5] pidns: introduce syscall translate_pid

On 04/05/2018 09:02 AM, Konstantin Khlebnikov wrote: > On 05.04.2018 01:29, Eric W. Biederman wrote: >> Nagarathnam Muthusamy writes: >> >>> On 04/04/2018 12:11 PM, Konstantin Khlebnikov wrote: Each process have different pids, one for each pid namespace it belongs. When interaction

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

On 04/12/2018 09:24 PM, John Hubbard wrote: > On 04/12/2018 12:18 PM, Jann Horn wrote: >> On Thu, Apr 12, 2018 at 8:59 PM, John Hubbard <jhubb...@nvidia.com> wrote: >>> On 04/12/2018 11:49 AM, Jann Horn wrote: >>>> On Thu, Apr 12, 2018 at 8:37 PM, Michael

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

On 04/12/2018 09:24 PM, John Hubbard wrote: > On 04/12/2018 12:18 PM, Jann Horn wrote: >> On Thu, Apr 12, 2018 at 8:59 PM, John Hubbard wrote: >>> On 04/12/2018 11:49 AM, Jann Horn wrote: >>>> On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pag

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

Hi John, On 12 April 2018 at 20:33, John Hubbard wrote: > On 04/12/2018 08:39 AM, Jann Horn wrote: >> Clarify that MAP_FIXED is appropriate if the specified address range has >> been reserved using an existing mapping, but shouldn't be used otherwise. >> >> Signed-off-by:

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

Hi John, On 12 April 2018 at 20:33, John Hubbard wrote: > On 04/12/2018 08:39 AM, Jann Horn wrote: >> Clarify that MAP_FIXED is appropriate if the specified address range has >> been reserved using an existing mapping, but shouldn't be used otherwise. >> >> Signed-off-by: Jann Horn >> --- >>

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

Hello Jann, On 04/12/2018 05:39 PM, Jann Horn wrote: > Clarify that MAP_FIXED is appropriate if the specified address range has > been reserved using an existing mapping, but shouldn't be used otherwise. > > Signed-off-by: Jann Horn > --- > man2/mmap.2 | 19

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

Hello Jann, On 04/12/2018 05:39 PM, Jann Horn wrote: > Clarify that MAP_FIXED is appropriate if the specified address range has > been reserved using an existing mapping, but shouldn't be used otherwise. > > Signed-off-by: Jann Horn > --- > man2/mmap.2 | 19 +++ > 1 file

Re: [PATCH manpages] membarrier.2: New membarrier commands introduced in 4.16

On 04/12/2018 02:20 PM, Mathieu Desnoyers wrote: > - On Apr 12, 2018, at 7:42 AM, Michael Kerrisk mtk.manpa...@gmail.com > wrote: > > Hi Michael, > > [...] >> >> I have applied the above patch, and done quite a bit of tweaking, and >> pushed the results to the git repo. >> >> I would be

Re: [PATCH manpages] membarrier.2: New membarrier commands introduced in 4.16

On 04/12/2018 02:20 PM, Mathieu Desnoyers wrote: > - On Apr 12, 2018, at 7:42 AM, Michael Kerrisk mtk.manpa...@gmail.com > wrote: > > Hi Michael, > > [...] >> >> I have applied the above patch, and done quite a bit of tweaking, and >> pushed the results to the git repo. >> >> I would be

Re: [PATCH manpages] membarrier.2: New membarrier commands introduced in 4.16

Hello Mathieu, On 12 February 2018 at 20:55, Mathieu Desnoyers wrote: > Document the following membarrier commands introduced in 4.16: > - MEMBARRIER_CMD_GLOBAL_EXPEDITED (the old enum label > MEMBARRIER_CMD_SHARED is now an alias to preserve header backward >

Re: [PATCH manpages] membarrier.2: New membarrier commands introduced in 4.16

Hello Mathieu, On 12 February 2018 at 20:55, Mathieu Desnoyers wrote: > Document the following membarrier commands introduced in 4.16: > - MEMBARRIER_CMD_GLOBAL_EXPEDITED (the old enum label > MEMBARRIER_CMD_SHARED is now an alias to preserve header backward > compatibility), > -

Re: [PATCH v2] readv.2, io_submit.2: Document RWF_APPEND added in Linux 4.16

On 04/06/2018 03:51 PM, Jürg Billeter wrote: > Signed-off-by: Jürg Billeter Thanks, Jürg. Patch applied. Cheers, Michael > --- > Changes since version 1: > - Explain offset handling > > man2/io_submit.2 | 13 + > man2/readv.2 | 17 + > 2

Re: [PATCH v2] readv.2, io_submit.2: Document RWF_APPEND added in Linux 4.16

On 04/06/2018 03:51 PM, Jürg Billeter wrote: > Signed-off-by: Jürg Billeter Thanks, Jürg. Patch applied. Cheers, Michael > --- > Changes since version 1: > - Explain offset handling > > man2/io_submit.2 | 13 + > man2/readv.2 | 17 + > 2 files changed, 30

Re: [PATCH] mmap.2: document new MAP_FIXED_NOREPLACE flag

Hi Jann, On 04/11/2018 06:40 PM, Jann Horn wrote: > On Wed, Apr 11, 2018 at 6:36 PM, Michal Hocko wrote: >> On Wed 11-04-18 17:37:46, Jann Horn wrote: >>> On Wed, Apr 11, 2018 at 2:04 PM, wrote: From: Michal Hocko 4.17+

Re: [PATCH] mmap.2: document new MAP_FIXED_NOREPLACE flag

Hi Jann, On 04/11/2018 06:40 PM, Jann Horn wrote: > On Wed, Apr 11, 2018 at 6:36 PM, Michal Hocko wrote: >> On Wed 11-04-18 17:37:46, Jann Horn wrote: >>> On Wed, Apr 11, 2018 at 2:04 PM, wrote: From: Michal Hocko 4.17+ kernels offer a new MAP_FIXED_NOREPLACE flag which allows

Re: [PATCH] mmap.2: document new MAP_FIXED_NOREPLACE flag

On 04/11/2018 06:40 PM, Jann Horn wrote: > On Wed, Apr 11, 2018 at 6:36 PM, Michal Hocko wrote: >> On Wed 11-04-18 17:37:46, Jann Horn wrote: >>> On Wed, Apr 11, 2018 at 2:04 PM, wrote: From: Michal Hocko 4.17+ kernels offer

Re: [PATCH] mmap.2: document new MAP_FIXED_NOREPLACE flag

On 04/11/2018 06:40 PM, Jann Horn wrote: > On Wed, Apr 11, 2018 at 6:36 PM, Michal Hocko wrote: >> On Wed 11-04-18 17:37:46, Jann Horn wrote: >>> On Wed, Apr 11, 2018 at 2:04 PM, wrote: From: Michal Hocko 4.17+ kernels offer a new MAP_FIXED_NOREPLACE flag which allows the caller

Re: [PATCH] mmap.2: document new MAP_FIXED_NOREPLACE flag

Hello Michal, On 04/11/2018 02:04 PM, mho...@kernel.org wrote: > From: Michal Hocko > > 4.17+ kernels offer a new MAP_FIXED_NOREPLACE flag which allows the caller to > atomicaly probe for a given address range. > > [wording heavily updated by John Hubbard

Re: [PATCH] mmap.2: document new MAP_FIXED_NOREPLACE flag

Hello Michal, On 04/11/2018 02:04 PM, mho...@kernel.org wrote: > From: Michal Hocko > > 4.17+ kernels offer a new MAP_FIXED_NOREPLACE flag which allows the caller to > atomicaly probe for a given address range. > > [wording heavily updated by John Hubbard ] > Signed-off-by: Michal Hocko

Re: [PATCH] readv.2, io_submit.2: Document RWF_APPEND added in Linux 4.16

Hello Jürg Thanks for the patch, but there are some details that are unexplained in the text and in the kernel commit message. Does the use of these flags change the file offset? The text should make this point explicit. Presumably, when using this flag for pwritev2(), the 'offset' argument of

Re: [PATCH] readv.2, io_submit.2: Document RWF_APPEND added in Linux 4.16

Hello Jürg Thanks for the patch, but there are some details that are unexplained in the text and in the kernel commit message. Does the use of these flags change the file offset? The text should make this point explicit. Presumably, when using this flag for pwritev2(), the 'offset' argument of

Re: A "domain invalid" cgroup *can* sometimes have member tasks

Hi Tehjun, On 21 February 2018 at 00:01, Tejun Heo wrote: > On Tue, Feb 20, 2018 at 11:35:47AM -0800, Tejun Heo wrote: >> Hmm... nr_populated_domain_children check should have caught that >> condition and rejected it. Will look into what's going on. > > Ah, okay, I was

Re: A "domain invalid" cgroup *can* sometimes have member tasks

Hi Tehjun, On 21 February 2018 at 00:01, Tejun Heo wrote: > On Tue, Feb 20, 2018 at 11:35:47AM -0800, Tejun Heo wrote: >> Hmm... nr_populated_domain_children check should have caught that >> condition and rejected it. Will look into what's going on. > > Ah, okay, I was special-casing the first

A "domain invalid" cgroup *can* sometimes have member tasks

Hello Tejun According to Documentation/cgroup-v2.txt, a "domain invalid" cgroup can't have member tasks. And indeed this is generally not permitted. However, someone recently showed me a scenario where a "domain invalid" cgroup can have member processes. See the following example: # mkdir -p

<    1   2   3   4   5   6   7   8   9   10   >