above, when a new mount namespace is created, it inherits a
copy of the mount points from the mount namespace of the
process that created the new mount namespace. If the two mount
namespaces are owned by different user namespaces, then the new
mount namespace is considered less privileged.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
this gone. :)
>
> Reviewed-by: Kees Cook
And for the record, the manual page has since 2007 documented that
this system call is likely to go away in the future.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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
;>
>> For what it is worth. The sequence above without the change in mount
>> attributes will fail if it is necessary to change the mount attributes
>> as "." is both put_old as well as new_root.
>>
>> When I initially suggested the change I saw ".
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
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.
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 =
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
s already terminated by the time of
the pidfd_open() call, the returned file descriptor is guaranteed
to refer to the child because the parent has not yet waited on the
child (and therefore, the child's ID has not been recycled).
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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,
>>>
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 f
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
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.
>>
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);
>>
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
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
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 mentio
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
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.
>>
/* Parent falls through to here; wait for child */
if (wait(NULL) == -1)
errExit("wait");
exit(EXIT_SUCCESS);
}
SEE ALSO
chdir(2), chroot(2), mount(2), stat(2), initrd(4), mount_names‐
paces(7), pivot_root(8), switch_root(8)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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:
>>>
>>&
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
(pollfd.revents & POLLIN) ? "" : "not ");
exit(EXIT_SUCCESS);
}
SEE ALSO
clone(2), kill(2), pidfd_send_signal(2), poll(2), select(2),
epoll(7)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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
- The propagation type of new_root and its parent mount must not
be MS_SHARED; similarly, if put_old is an existing mount point,
its propagation type must not be MS_SHARED.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
n particular,
the following sequence allows a pivot-root operation without need‐
ing to create and remove a temporary directory:
chdir(new_root);
pivot_root(".", ".");
umount2(".", MNT_DETACH);
This sequence suc
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
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(&
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
[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
Dabbelt]
Document vDSO for RISCV
Changes to individual pages
---
pldd.1
G. Branden Robinson [Michael Kerrisk]
Document glibc's unbreakage of tool
After a longstanding breakage, pldd now works again (glibc 2.30).
execve.2
Michael Kerrisk
hat most of the filesystem xattr handler files mention ERANGE in some
> form. A suggested patch is below (I'm not 100% sure on the wording
> through).
Thanks. Patch applied, and I've done some rewording.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
from the pair
of mounts stacked at "/".
At least, in some separate tests that I've done, things seem to work
as I describe above without the use of the marked fchdir() calls. (My
tests omit the mount(MS_SLAVE) piece, since in my tests I do a
more-or-less equivalent step at an earlier point.
>> +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/
Li
m
+.BR ppoll ().
+.PP
See the description of
.BR pselect (2)
for an explanation of why
@@ -354,6 +365,12 @@ value exceeds the
.B RLIMIT_NOFILE
value.
.TP
+.B EINVAL
+.RB ( ppoll ())
+The timeout value expressed in
+.IR *ip
+is invalid (nragtive).
+.TP
.B ENOMEM
There was no space to allocate file desc
: 2019-05-09, Munich
Newly documented interfaces in existing pages
-
tsearch.3
Florian Weimer [Michael Kerrisk]
Document the twalk_r() function added in glibc 2.30
Changes to individual pages
---
bpf.2
Michael
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
---
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
---
Michael Kerrisk [Eugene Syromyatnikov]
New page that contains details of socket address families
There is too much detail in socket(2). Move most of it into
a new page instead.
bpf-helpers.7
Michael Kerrisk [Daniel Borkmann, Quentin Monnet]
Add new
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:
>
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
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
he syscall failed,
with 'errno' set to that value
* error == 0 ==> make it look like the syscall succeeded
and returned 'val'
Right?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
rrived at a decision about the target process's
system call, the monitoring process can inform the kernel
of its decision using the operation
ioctl(listenfd, SECCOMP_IOCTL_NOTIF_SEND, respptr)
where the third argument is a pointer to a
'struct seccomp_notif_resp'. [Some more details
needed here, but I still don't yet understand fully
the semantics of the 'error' and 'val' fields.]
I'd like to include text along the above lines at the start of
the "Userspace Notification" section. Could you take a look at
the above and let me know any errors, improved terminology, or
other improvements generally. I'll then work that text into
the 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/
─┘
CONFORMING TO
rseq() is Linux-specific.
┌─┐
│FIXME│
├─┤
│Is there any example code that can reasonably be │
│included in this manual page? Or some example code │
│that can be referred to?
lways mean "(one) thread",
> > never "a (possibly multithreaded) process".
> > Ptrace commands are always sent to
> > a specific tracee using a call of the form
> > @@ -2259,7 +2265,7 @@ or (on kernels before 2.6.26) be
> > .TP
> > .B ESRCH
> > The specified process does not exist, or is not currently being traced
> > -by the caller, or is not stopped
> > +by the calling thread, or is not stopped
> > (for requests that require a stopped tracee).
> > .SH CONFORMING TO
> > SVr4, 4.3BSD.
>
> I agree the current text can be made more clear on the subject,
> but, unfortunately, proposed change makes the description more confusing.
>
>
> --
> ldv
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
that follows it is not quite clear:
> +Note that an existing process might be a zombie,
> +a process that has terminated execution, but
> +has not yet been
> +.BR wait (2)ed
> +for.
Is it the case that using procfd_signal() with a file
descriptor that refers to a zombie will yield EINVAL?
If yes, this could be made clearer with the following:
.B ESRCH
The specified process no longer exists or is a process in the
zombie state (a process that has terminated execution, but
has not yet been
BR wait (2)ed
for).
> +.SH CONFORMING TO
> +This system call is Linux-specific.
> +.SH SEE ALSO
> +.BR kill (2),
> +.BR sigaction (2),
> +.BR sigprocmask (2),
> +.BR tgkill (2),
> +.BR pthread_sigqueue (3),
> +.BR rt_sigqueueinfo (2),
> +.BR sigqueue (3),
> +.BR signal (7)
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
that follows it is not quite clear:
> +Note that an existing process might be a zombie,
> +a process that has terminated execution, but
> +has not yet been
> +.BR wait (2)ed
> +for.
Is it the case that using procfd_signal() with a file
descriptor that refers to a zombie will yield EINVAL?
If yes, this could be made clearer with the following:
.B ESRCH
The specified process no longer exists or is a process in the
zombie state (a process that has terminated execution, but
has not yet been
BR wait (2)ed
for).
> +.SH CONFORMING TO
> +This system call is Linux-specific.
> +.SH SEE ALSO
> +.BR kill (2),
> +.BR sigaction (2),
> +.BR sigprocmask (2),
> +.BR tgkill (2),
> +.BR pthread_sigqueue (3),
> +.BR rt_sigqueueinfo (2),
> +.BR sigqueue (3),
> +.BR signal (7)
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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
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
ime
on the glibc project. Quite possibly, they just need some help to
add more (properly designed) wrappers faster.
Cheers,
Michael
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a
longstanding example.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/d
ime
on the glibc project. Quite possibly, they just need some help to
add more (properly designed) wrappers faster.
Cheers,
Michael
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a
longstanding example.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/d
p.procs
655
654
Your thoughts?
Thanks,
Michael
[1] https://www.spinics.net/lists/cgroups/msg20710.html
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
p.procs
655
654
Your thoughts?
Thanks,
Michael
[1] https://www.spinics.net/lists/cgroups/msg20710.html
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
/shm.
> .PP
> The caller can prevent or allow swapping of a shared
> memory segment with the following \fIcmd\fP values:
> @@ -287,7 +300,7 @@ operation returns the index of the highest used entry in
> the
> kernel's internal array recording information about all
> shared memory segments.
> (This information can be used with repeated
> -.B SHM_STAT
> +.B SHM_STAT or SHM_STAT_ANY
> operations to obtain information about all shared memory segments
> on the system.)
> A successful
> @@ -328,7 +341,7 @@ isn't accessible.
> \fIshmid\fP is not a valid identifier, or \fIcmd\fP
> is not a valid command.
> Or: for a
> -.B SHM_STAT
> +.B SHM_STAT or SHM_STAT_ANY
> operation, the index value specified in
> .I shmid
> referred to an array slot that is currently unused.
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
/shm.
> .PP
> The caller can prevent or allow swapping of a shared
> memory segment with the following \fIcmd\fP values:
> @@ -287,7 +300,7 @@ operation returns the index of the highest used entry in
> the
> kernel's internal array recording information about all
> shared memory segments.
> (This information can be used with repeated
> -.B SHM_STAT
> +.B SHM_STAT or SHM_STAT_ANY
> operations to obtain information about all shared memory segments
> on the system.)
> A successful
> @@ -328,7 +341,7 @@ isn't accessible.
> \fIshmid\fP is not a valid identifier, or \fIcmd\fP
> is not a valid command.
> Or: for a
> -.B SHM_STAT
> +.B SHM_STAT or SHM_STAT_ANY
> operation, the index value specified in
> .I shmid
> referred to an array slot that is currently unused.
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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
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
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]
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]
quot; cgroup, or add member processes
to the cgroup, or *enable controllers in the cgroup*. In fact, when
doing the
# echo threaded > x/z/cgroup.type
I had expected a write(2) error because the state of x/y should
(I thought) not be permitted.
Your thoughts?
Thanks,
Michael
--
Michael
quot; cgroup, or add member processes
to the cgroup, or *enable controllers in the cgroup*. In fact, when
doing the
# echo threaded > x/z/cgroup.type
I had expected a write(2) error because the state of x/y should
(I thought) not be permitted.
Your thoughts?
Thanks,
Michael
--
Michael
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
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
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
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
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
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
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,
> > >
> >
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,
> > >
> >
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 various minor
changes and bug fixes, but two major changes:
* We now pass fds to the tracee via an ioctl, and do it immediately when
the ioctl is called. For this we
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 various minor
changes and bug fixes, but two major changes:
* We now pass fds to the tracee via an ioctl, and do it immediately when
the ioctl is called. For this we
" from "domain invalid" to
"threaded", we get ENOTSUP on the write():
# echo threaded > mycgrp/a/b/c/cgroup.type
sh: echo: write error: Operation not supported
Your thoughts?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/d
" from "domain invalid" to
"threaded", we get ENOTSUP on the write():
# echo threaded > mycgrp/a/b/c/cgroup.type
sh: echo: write error: Operation not supported
Your thoughts?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/d
Hello Adam,
On 07/13/2018 10:58 PM, adam.manzana...@wdc.com wrote:
From: Adam Manzanares
The newly added IOCB_FLAG_IOPRIO aio_flag introduces
new behaviors and return values.
The details of this new feature are posted here:
https://lkml.org/lkml/2018/5/22/809
Thanks for this patch. I've
Hello Adam,
On 07/13/2018 10:58 PM, adam.manzana...@wdc.com wrote:
From: Adam Manzanares
The newly added IOCB_FLAG_IOPRIO aio_flag introduces
new behaviors and return values.
The details of this new feature are posted here:
https://lkml.org/lkml/2018/5/22/809
Thanks for this patch. I've
Signed-off-by: Wang Nan
Reviewed-by: Vince Weaver
Cc: Michael Kerrisk
---
man2/perf_event_open.2 | 24
1 file changed, 24 insertions(+)
diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index fade28c..561331c 100644
--- a/man2/perf_event_open.2
+++ b/man2
Signed-off-by: Wang Nan
Reviewed-by: Vince Weaver
Cc: Michael Kerrisk
---
man2/perf_event_open.2 | 24
1 file changed, 24 insertions(+)
diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index fade28c..561331c 100644
--- a/man2/perf_event_open.2
+++ b/man2
pages
-
membarrier.2
Mathieu Desnoyers [Michael Kerrisk]
Document new membarrier commands introduced in Linux 4.16
Document the following membarrier commands introduced in
Linux 4.16
pages
-
membarrier.2
Mathieu Desnoyers [Michael Kerrisk]
Document new membarrier commands introduced in Linux 4.16
Document the following membarrier commands introduced in
Linux 4.16
address ranges so people really have to be careful.
>
> I do not really care what is the form. I find the current wording quite
> informative and showing examples of how things might be broken. I do
> agree with your remark that "MAP_FIXED on preallocated ranges is safe"
> should be added. But MAP_FIXED is dangerous API and should have few big
> fat warnings.
So, at this stage, is any further patch needed to the text describing
MAP_FIXED/MAP_FIXED_REPLACE?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
ul.
>
> I do not really care what is the form. I find the current wording quite
> informative and showing examples of how things might be broken. I do
> agree with your remark that "MAP_FIXED on preallocated ranges is safe"
> should be added. But MAP_FIXED is dangerous API and should have few big
> fat warnings.
So, at this stage, is any further patch needed to the text describing
MAP_FIXED/MAP_FIXED_REPLACE?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
n can check this using the
+.I stat.st_dev
+and
.I stat.st_ino
-field returned by
+fields returned by
.BR stat (2).
The content of this symbolic link is a string containing
the namespace type and inode number as in the following example:
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
symbolic links.
-If two processes are in the same namespace, then the inode numbers of their
+If two processes are in the same namespace,
+then the device IDs and inode numbers of their
.IR /proc/[pid]/ns/xxx
symbolic links will be the same; an application can check this using the
+.I stat.st_dev
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
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
referred over
>> -.BR MAP_FIXED .
>> +that should be used instead; older kernels require the caller to use
>> +.I addr
>> +as a hint (without
>> +.BR MAP_FIXED )
>
> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
> behavior, in the MAP_FIXED
uld be used instead; older kernels require the caller to use
>> +.I addr
>> +as a hint (without
>> +.BR MAP_FIXED )
>
> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
> behavior, in the MAP_FIXED section. Maybe if you break up the
.BR MAP_FIXED .
> +that should be used instead; older kernels require the caller to use
> +.I addr
> +as a hint (without
> +.BR MAP_FIXED )
> +and take appropriate action if the kernel places the new mapping at a
> +different address.
> .TP
> .BR MAP_FIXED_NOREPLACE &qu
hat should be used instead; older kernels require the caller to use
> +.I addr
> +as a hint (without
> +.BR MAP_FIXED )
> +and take appropriate action if the kernel places the new mapping at a
> +different address.
> .TP
> .BR MAP_FIXED_NOREPLACE " (since Linux 4.17)
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 re
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 re
header backward
> compatibility),
> - MEMBARRIER_CMD_GLOBAL_EXPEDITED,
> - MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED,
> - MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE,
> - MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE.
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoy
ompatibility),
> - MEMBARRIER_CMD_GLOBAL_EXPEDITED,
> - MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED,
> - MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE,
> - MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE.
>
> Signed-off-by: Mathieu Desnoyers
> CC: Michael Kerrisk
> CC: Ingo Molnar
> CC
ded
> +to the end of the file. However, if the
> +.I offset
> +argument is \-1, the current file offset is updated.
> +This matches the behavior when the file is opened in append mode.
> .SH RETURN VALUE
> On success,
> .BR readv (),
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
the end of the file. However, if the
> +.I offset
> +argument is \-1, the current file offset is updated.
> +This matches the behavior when the file is opened in append mode.
> .SH RETURN VALUE
> On success,
> .BR readv (),
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
;> Please don't make it sound as if MAP_FIXED is always wrong.
>>
>> Well, this was suggested by John. I think, nobody is objecting that
>> MAP_FIXED has legitimate usecases. The above text just follows up on
>> the previous section which emphasises the potential memory c
think, nobody is objecting that
>> MAP_FIXED has legitimate usecases. The above text just follows up on
>> the previous section which emphasises the potential memory corruption
>> problems and it suggests that a new flag is safe with that regards.
>>
>> If you have specific wording that would be better I am open for changes.
>
> I guess I'd probably also want to change the previous text; so I
> should probably send a followup patch once this one has landed.
Okay -- I'm ready to take that piece now. Please send me a patch!
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 detecting a collision with a pre-existing
>>>> mapping)
>>>> +fall back to a "non-MAP_FIXED" type of behavior: they will return an
>>>> address that
>>>> +is different than the requested one. Therefore, backward-compatible
>>>> soft
" type of behavior: they will return an
>>>> address that
>>>> +is different than the requested one. Therefore, backward-compatible
>>>> software
>>>> +should check the returned address against the requested address.
>>>> .TP
>>>> .B MAP_GROWSDOWN
>>>> This flag is used for stacks.
>>>> @@ -487,6 +508,12 @@ is not a valid file descriptor (and
>>>> .B MAP_ANONYMOUS
>>>> was not set).
>>>> .TP
>>>> +.B EEXIST
>>>> +range covered by
>>>> +.IR addr ,
>>>> +.IR length
>>>> +is clashing with an existing mapping.
>>>
>>> Maybe add something like ", and MAP_FIXED_NOREPLACE was specified"? I
>>> think most manpages explicitly document which error conditions can be
>>> triggered by which flags.
>>
>> sure, no objection from me.
I've added the suggested piece from Jann to the EEXIST error description.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
201 - 300 of 2778 matches
Mail list logo
