[dropping Lennart into CC]
Hello Tejun,
On 12/04/2017 10:47 PM, Tejun Heo wrote:
> Hello, Michael.
>
> On Mon, Dec 04, 2017 at 10:35:13PM +0100, Michael Kerrisk (man-pages) wrote:
>> I was trying to do some simple testing ot the CPU controller
>> that is merged into 4.15
[dropping Lennart into CC]
Hello Tejun,
On 12/04/2017 10:47 PM, Tejun Heo wrote:
> Hello, Michael.
>
> On Mon, Dec 04, 2017 at 10:35:13PM +0100, Michael Kerrisk (man-pages) wrote:
>> I was trying to do some simple testing ot the CPU controller
>> that is merged into 4.15
ite error: Invalid argument
What am I missing> I presume I'm missing something obvious, although
nothing jumped out at me as I read the cgroups-v2.txt file.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Tr
ite error: Invalid argument
What am I missing> I presume I'm missing something obvious, although
nothing jumped out at me as I read the cgroups-v2.txt file.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Tr
or to my experiencing this
> with 9p, the only
> time I've ever experienced it was on HPC clusters with who knows what
> code providing the network filesystem). If it is indeed the case that
> an EINTR return from stat() and similar is illegal and should be considered
> a kernel bug, a statement to that extent all I'm looking for here.
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
gt; with 9p, the only
> time I've ever experienced it was on HPC clusters with who knows what
> code providing the network filesystem). If it is indeed the case that
> an EINTR return from stat() and similar is illegal and should be considered
> a kernel bug, a statement to that extent all I'm looking for here.
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Released: 2017-11-26, Paris
New and rewritten pages
---
pthread_spin_init.3
Michael Kerrisk [Peter Zijlstra, Thomas Gleixner, Zack Weinberg,
Florian Weimer]
New page describing pthread_spin_init(3) and pthread_spin_destroy(3
Released: 2017-11-26, Paris
New and rewritten pages
---
pthread_spin_init.3
Michael Kerrisk [Peter Zijlstra, Thomas Gleixner, Zack Weinberg,
Florian Weimer]
New page describing pthread_spin_init(3) and pthread_spin_destroy(3
ged, 450 insertions(+), 22 deletions(-)
> create mode 100644 tools/testing/selftests/process_vmsplice/Makefile
> create mode 100644
> tools/testing/selftests/process_vmsplice/process_vmsplice_test.c
>
> --
> 2.7.4
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
e 100644 tools/testing/selftests/process_vmsplice/Makefile
> create mode 100644
> tools/testing/selftests/process_vmsplice/process_vmsplice_test.c
>
> --
> 2.7.4
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
lly less racy
> and more of what is actually trying to be implemented with the userspace
> pieces.
>
> I just wanted to point out that TIOCGPTPEER while being the interface
> that it would have been nice had we had since the beginning (and would
> have avoided all of the problems)
acy
> and more of what is actually trying to be implemented with the userspace
> pieces.
>
> I just wanted to point out that TIOCGPTPEER while being the interface
> that it would have been nice had we had since the beginning (and would
> have avoided all of the problems) is actually not
Hello Miklos,
On 20 November 2017 at 10:22, Miklos Szeredi <mszer...@redhat.com> wrote:
> On Mon, Nov 20, 2017 at 10:07 AM, Michael Kerrisk (man-pages)
> <mtk.manpa...@gmail.com> wrote:
>
>> But, the problem is that the existing description is at best misleading:
>
Hello Miklos,
On 20 November 2017 at 10:22, Miklos Szeredi wrote:
> On Mon, Nov 20, 2017 at 10:07 AM, Michael Kerrisk (man-pages)
> wrote:
>
>> But, the problem is that the existing description is at best misleading:
>>
>> (2) parent ID: the ID of t
about what's happening there?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
about what's happening there?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hi Miklos,
Sorry for the slow follow-up.
On 14 November 2017 at 17:16, Miklos Szeredi <mszer...@redhat.com> wrote:
> On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages)
> <mtk.manpa...@gmail.com> wrote:
>> Hi Miklos, Ram
>>
>> Thanks for your com
Hi Miklos,
Sorry for the slow follow-up.
On 14 November 2017 at 17:16, Miklos Szeredi wrote:
> On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Miklos, Ram
>>
>> Thanks for your comments. A question below.
>>
>> On 13 November
quot; FIXME See if the following syscalls make it into Linux 4.15 or later
+.\" .BR cpu_opv (2),
+.\" .BR rseq (2)
.SH NOTES
A memory barrier instruction is part of the instruction set of
architectures with weakly-ordered memory models.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
using private expedited
+commands.
.SH VERSIONS
The
.BR membarrier ()
@@ -162,6 +184,10 @@ system call was added in Linux 4.3.
.SH CONFORMING TO
.BR membarrier ()
is Linux-specific.
+.\" .SH SEE ALSO
+.\" FIXME See if the following syscalls make it into Linux 4.15 or later
+.\
+++
> man2/membarrier.2 | 75 +++---
> man2/rseq.2 | 268
> 3 files changed, 626 insertions(+), 14 deletions(-)
> create mode 100644 man2/cpu_opv.2
> create mode 100644 man2/rseq.2
+++
> man2/membarrier.2 | 75 +++---
> man2/rseq.2 | 268
> 3 files changed, 626 insertions(+), 14 deletions(-)
> create mode 100644 man2/cpu_opv.2
> create mode 100644 man2/rseq.2
Hi Kees!
On 18 November 2017 at 21:52, Kees Cook <keesc...@chromium.org> wrote:
> On Sat, Nov 18, 2017 at 12:04 PM, Michael Kerrisk (man-pages)
> <mtk.manpa...@gmail.com> wrote:
>> Hi Kees,
>>
>> I came up with the following text (patch below) to describe th
Hi Kees!
On 18 November 2017 at 21:52, Kees Cook wrote:
> On Sat, Nov 18, 2017 at 12:04 PM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Kees,
>>
>> I came up with the following text (patch below) to describe the
>> SECCOMP_RET_KILL_PROCESS action that you added
s value results in immediate termination of the thread
that made the system call.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
s value results in immediate termination of the thread
that made the system call.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
uot;H. Peter Anvin" <h...@zytor.com>
> CC: Ben Maurer <bmau...@fb.com>
> CC: Steven Rostedt <rost...@goodmis.org>
> CC: Josh Triplett <j...@joshtriplett.org>
> CC: Linus Torvalds <torva...@linux-foundation.org>
> CC: Andrew Morton <a...@linux-f
gt; CC: "Paul E. McKenney"
> CC: Peter Zijlstra
> CC: Paul Turner
> CC: Thomas Gleixner
> CC: Andrew Hunter
> CC: Andy Lutomirski
> CC: Andi Kleen
> CC: Dave Watson
> CC: Chris Lameter
> CC: Ingo Molnar
> CC: "H. Peter Anvin"
> CC: Ben Ma
Hi Miklos, Ram
Thanks for your comments. A question below.
On 13 November 2017 at 09:11, Miklos Szeredi <mszer...@redhat.com> wrote:
> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai <linux...@us.ibm.com> wrote:
>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pa
Hi Miklos, Ram
Thanks for your comments. A question below.
On 13 November 2017 at 09:11, Miklos Szeredi wrote:
> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai wrote:
>> On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>> Hello Ram,
>>>
>
the mountinfo file, and does not
appear in field (1) in the mountinfo file in any other
mount namespace. (In the initial mount namespace,
this hidden ID has the value 0.)
]]
With best regards,
Michael
--
Michael Kerrisk
Linux man-pa
the mountinfo file, and does not
appear in field (1) in the mountinfo file in any other
mount namespace. (In the initial mount namespace,
this hidden ID has the value 0.)
]]
With best regards,
Michael
--
Michael Kerrisk
Linux man-pa
Hello Stas,
On 6 November 2017 at 23:28, Stas Sergeev <s...@list.ru> wrote:
> 07.11.2017 01:26, Michael Kerrisk (man-pages) пишет:
>>
>> Hello Stas,
>>
>> Ping on the below?
>
> Hi, the change with the "not recommended" warning
> looks good to
Hello Stas,
On 6 November 2017 at 23:28, Stas Sergeev wrote:
> 07.11.2017 01:26, Michael Kerrisk (man-pages) пишет:
>>
>> Hello Stas,
>>
>> Ping on the below?
>
> Hi, the change with the "not recommended" warning
> looks good to me.
> Acked-by:
Hello Stas,
Ping on the below?
Cheers,
Michael
On 10/30/2017 01:38 PM, Michael Kerrisk (man-pages) wrote:
> On 05/24/2017 10:12 PM, Stas Sergeev wrote:
>> Hello,
>>
>> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>>>> Could you please point and cit
Hello Stas,
Ping on the below?
Cheers,
Michael
On 10/30/2017 01:38 PM, Michael Kerrisk (man-pages) wrote:
> On 05/24/2017 10:12 PM, Stas Sergeev wrote:
>> Hello,
>>
>> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>>>> Could you please point and cit
previous
> iteration. After a few pre-dump operations, a process is stopped and
> dumped finally. The pre-dump operations allow to significantly decrease
> a process downtime, when a process is migrated to another host.
>
> Cc: Alexander Viro <v...@zeniv.linux.org.uk>
> Cc
t; iteration. After a few pre-dump operations, a process is stopped and
> dumped finally. The pre-dump operations allow to significantly decrease
> a process downtime, when a process is migrated to another host.
>
> Cc: Alexander Viro
> Cc: Arnd Bergmann
> Cc: Pavel Emelyanov
> Cc:
On 05/24/2017 10:12 PM, Stas Sergeev wrote:
> Hello,
>
> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>>> Could you please point and cite the spec that says
>>> exactly this?
>> I take your point: the text of the spec could be more precise. It
>> doe
On 05/24/2017 10:12 PM, Stas Sergeev wrote:
> Hello,
>
> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>>> Could you please point and cite the spec that says
>>> exactly this?
>> I take your point: the text of the spec could be more precise. It
>> doe
Hi Walter,
On 10/30/2017 11:21 AM, walter harms wrote:
>
>
> Am 30.10.2017 11:04, schrieb Michael Kerrisk (man-pages):
>> [So, things fell on the floor, a while back.]
>>
>> On 05/25/2017 11:17 AM, Stas Sergeev wrote:
>>> 24.05.2017 14:09, Michael Kerrisk
Hi Walter,
On 10/30/2017 11:21 AM, walter harms wrote:
>
>
> Am 30.10.2017 11:04, schrieb Michael Kerrisk (man-pages):
>> [So, things fell on the floor, a while back.]
>>
>> On 05/25/2017 11:17 AM, Stas Sergeev wrote:
>>> 24.05.2017 14:09, Michael Kerrisk
[So, things fell on the floor, a while back.]
On 05/25/2017 11:17 AM, Stas Sergeev wrote:
> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>> One could do this I suppose, but I read POSIX differently from
>> you and, more importantly, SS_ONSTACK breaks portability on
&g
[So, things fell on the floor, a while back.]
On 05/25/2017 11:17 AM, Stas Sergeev wrote:
> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>> One could do this I suppose, but I read POSIX differently from
>> you and, more importantly, SS_ONSTACK breaks portability on
&g
nt the kernel from automatically allocating pages and filling
> +holes in sparse files when the hole is accessed thru mapped address.
> +.PP
> +The
> +.B UFFD_FEATURE_SIGBUS
> +feature is implicitly inherited through fork() if used in combination with
> +.BR UFFD_FEATURE_FORK .
> +
&g
s in sparse files when the hole is accessed thru mapped address.
> +.PP
> +The
> +.B UFFD_FEATURE_SIGBUS
> +feature is implicitly inherited through fork() if used in combination with
> +.BR UFFD_FEATURE_FORK .
> +
> +.PP
> Details of the various
> .BR ioctl (2)
> operations can be found in
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
ding of ACPI tables.
> .P
> The use of ACPI error injection.
> .P
> The specification of the ACPI RDSP address.
> .P
> The use of ACPI custom methods.
> .RE
> .P
> The following facilities are restricted:
> .P
> .RS
> Only validly signed modules may be loaded.
> .P
> Only validly signed binaries may be kexec'd.
> .P
> Only validly signed device firmware may be loaded.
> .P
> Only validly signed wifi databases may be use.
> .P
> Unencrypted hibernation/suspend to swap are disallowed as the kernel image is
> saved to a medium that can then be accessed.
> .P
> Use of debugfs is not permitted as this allows a whole range of actions
> including direct configuration of, access to and driving of hardware.
> .RE
> .\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> .SH SEE ALSO
> .ad l
> .nh
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
ding of ACPI tables.
> .P
> The use of ACPI error injection.
> .P
> The specification of the ACPI RDSP address.
> .P
> The use of ACPI custom methods.
> .RE
> .P
> The following facilities are restricted:
> .P
> .RS
> Only validly signed modules may be loaded.
> .P
> Only validly signed binaries may be kexec'd.
> .P
> Only validly signed device firmware may be loaded.
> .P
> Only validly signed wifi databases may be use.
> .P
> Unencrypted hibernation/suspend to swap are disallowed as the kernel image is
> saved to a medium that can then be accessed.
> .P
> Use of debugfs is not permitted as this allows a whole range of actions
> including direct configuration of, access to and driving of hardware.
> .RE
> .\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> .SH SEE ALSO
> .ad l
> .nh
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hi Rik,
Thanks for the blazingly fast response :-)
On 9 October 2017 at 21:08, Rik van Riel <r...@redhat.com> wrote:
> On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Rik,
>>
>> I have a follow-up question re wipe-on-fork. What are the se
Hi Rik,
Thanks for the blazingly fast response :-)
On 9 October 2017 at 21:08, Rik van Riel wrote:
> On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Rik,
>>
>> I have a follow-up question re wipe-on-fork. What are the semantics
>> fo
we do an exec(), my assumption is that the flag is
cleared for the address range, but it would be good to have
confirmation.
Thanks,
Michael
On 19 September 2017 at 21:21, Rik van Riel <r...@redhat.com> wrote:
> On Tue, 2017-09-19 at 21:07 +0200, Michael Kerrisk (man-pages) wrote:
&g
we do an exec(), my assumption is that the flag is
cleared for the address range, but it would be good to have
confirmation.
Thanks,
Michael
On 19 September 2017 at 21:21, Rik van Riel wrote:
> On Tue, 2017-09-19 at 21:07 +0200, Michael Kerrisk (man-pages) wrote:
>
>> Thank
On 27 September 2017 at 17:03, Andy Lutomirski <l...@amacapital.net> wrote:
> On Tue, Sep 26, 2017 at 12:00 PM, Alexey Dobriyan <adobri...@gmail.com> wrote:
>> On Mon, Sep 25, 2017 at 09:42:58AM +0200, Michael Kerrisk (man-pages) wrote:
>>> [Not sure why origi
On 27 September 2017 at 17:03, Andy Lutomirski wrote:
> On Tue, Sep 26, 2017 at 12:00 PM, Alexey Dobriyan wrote:
>> On Mon, Sep 25, 2017 at 09:42:58AM +0200, Michael Kerrisk (man-pages) wrote:
>>> [Not sure why original author is not in CC; added]
>>>
>>> He
Hi Mike,
On 25 September 2017 at 18:33, Mike Kravetz <mike.krav...@oracle.com> wrote:
> On 09/20/2017 12:25 AM, Michael Kerrisk (man-pages) wrote:
[...]
>> I've applied this, and added Reviewed-by tags for Florian and Jann.
>> But, I think it's also worth noting the
Hi Mike,
On 25 September 2017 at 18:33, Mike Kravetz wrote:
> On 09/20/2017 12:25 AM, Michael Kerrisk (man-pages) wrote:
[...]
>> I've applied this, and added Reviewed-by tags for Florian and Jann.
>> But, I think it's also worth noting the older, now disallowed, behav
On 25 September 2017 at 14:36, Michal Hocko <mho...@kernel.org> wrote:
> On Wed 20-09-17 09:25:42, Michael Kerrisk wrote:
> [...]
>> BUGS
>>Before Linux 4.14, if old_size was zero and the mapping referred
>>to by old_address was a privat
On 25 September 2017 at 14:36, Michal Hocko wrote:
> On Wed 20-09-17 09:25:42, Michael Kerrisk wrote:
> [...]
>> BUGS
>>Before Linux 4.14, if old_size was zero and the mapping referred
>>to by old_address was a private mapping (mmap(2) MAP_PR
+TEST(pid_max)
> +{
> + int *pid;
> + unsigned int n;
> + int ret, p;
> + int old_pidmax;
> +
> + old_pidmax = write_pidmax(5);
> +
> + do_forks(4);
> +
> + p = fork();
> +
> + if (p == 0)
> + pause();
> +
> + ret = pidmap_full(, );
> + kill(p, SIGKILL);
> +
> + EXPECT_LE(0, ret);
> + EXPECT_LE(1, n);
> + if (ret < 0 || n <= 0)
> + goto exit;
> + EXPECT_EQ(p, pid[n - 1]);
> +exit:
> + write_pidmax(old_pidmax);
> +}
> +
> +void sigquit_h(int sig)
> +{
> + assert(sig == SIGQUIT);
> + if (getgid() != getpid())
> + exit(0);
> +}
> +
> +TEST(compare_proc)
> +{
> + pid_t pid;
> +
> + if (unshare(CLONE_NEWNS | CLONE_NEWPID) == -1)
> + return;
> +
> + pid = fork();
> +
> + if (pid == 0) {
> + pid_t p;
> + int i = 0;
> +
> + signal(SIGQUIT, sigquit_h);
> +
> + mount("none", "/", NULL, MS_REC | MS_PRIVATE, NULL);
> + mount("none", "/proc", NULL, MS_REC | MS_PRIVATE, NULL);
> + mount("proc", "/proc", "proc",
> + MS_NOSUID | MS_NODEV | MS_NOEXEC, NULL);
> +
> + while (i < 150) {
> + i++;
> +
> + p = fork();
> +
> + if (p == -1) {
> + umount("/proc");
> + return;
> + }
> + if (p == 0) {
> + pause();
> + return;
> + }
> + }
> +
> + int *pids, *pids_proc;
> + unsigned int n = 0;
> + unsigned int n_proc = 0;
> + int ret, ret_proc;
> +
> + ret = pidmap_full(, );
> +
> + ret_proc = pidmap_proc(_proc, _proc);
> + qsort(pids_proc, n_proc, sizeof(int), compare);
> +
> + EXPECT_LE(0, ret);
> + if (ret < 0 || ret_proc < 0)
> + goto exit;
> +
> + EXPECT_EQ(n_proc, n);
> + if (n != n_proc)
> + goto exit;
> +
> + for (int i = 0; i < n; i++) {
> + EXPECT_EQ(pids_proc[i], pids[i]);
> + if (pids_proc[i] != pids[i])
> + break;
> + }
> +exit:
> + free(pids_proc);
> + free(pids);
> + umount("/proc");
> + kill(-getpid(), SIGQUIT);
> + }
> + wait(NULL);
> +}
> +
> +TEST_HARNESS_MAIN
> diff --git a/tools/testing/selftests/pidmap/pidmap.h
> b/tools/testing/selftests/pidmap/pidmap.h
> new file mode 12
> index ..3abbde34fee9
> --- /dev/null
> +++ b/tools/testing/selftests/pidmap/pidmap.h
> @@ -0,0 +1 @@
> +../../../../include/uapi/linux/pidmap.h
> \ No newline at end of file
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
pid = fork();
> +
> + if (pid == 0)
> + exit(0);
> + waitpid(pid, NULL, 0);
> + }
> +}
> +
> +TEST(pid_max)
> +{
> + int *pid;
> + unsigned int n;
> + int ret, p;
> + int old_pidmax;
> +
> + old
size_t size1, size2, i;
> + int ret1, ret2;
> +
> + ret1 = fdmap_full(1, , );
> + ret2 = fdmap_proc(1, , );
> + ASSERT_EQ(ret2, ret1);
> + ASSERT_EQ(size2, size1);
> + for (i = 0; i < size1; i++)
> + ASSERT_EQ(fds2[i], fds1[i]);
> + free(fds1);
> + free(fds2);
> +}
> +
> +TEST(zero) {
> + int *fds, i;
> + size_t size;
> + int ret;
> +
> + ret = fdmap_proc(0, , );
> + ASSERT_EQ(0, ret);
> + for (i = 0; i < size; i++)
> + close(fds[i]);
> + free(fds);
> + fds = NULL;
> +
> + ret = fdmap_full(0, , );
> + ASSERT_EQ(0, ret);
> + ASSERT_EQ(0, size);
> +}
> +
> +TEST(more_fds) {
> + int *fds1, *fds2, ret1, ret2;
> + size_t size1, size2, i;
> +
> + struct rlimit rlim = {
> + .rlim_cur = 60,
> + .rlim_max = 60
> + };
> + ASSERT_EQ(0, setrlimit(RLIMIT_NOFILE, ));
> + for (int i = 0; i < 50; i++)
> + dup(0);
> +
> + ret1 = fdmap_full(0, , );
> + ret2 = fdmap_proc(0, , );
> + ASSERT_EQ(ret2, ret1);
> + ASSERT_EQ(size2, size1);
> + for (i = 0; i < size1; i++)
> + ASSERT_EQ(fds2[i], fds1[i]);
> + free(fds1);
> + free(fds2);
> +}
> +
> +TEST(child) {
> + int pipefd[2];
> + int *fds1, *fds2, ret1, ret2, i;
> + size_t size1, size2;
> + char byte = 0;
> + pid_t pid;
> +
> + ASSERT_NE(-1, pipe(pipefd));
> + pid = fork();
> + ASSERT_NE(-1, pid);
> + if (!pid) {
> + read(pipefd[0], , 1);
> + close(pipefd[0]);
> + close(pipefd[1]);
> + exit(0);
> + }
> +
> + ret1 = fdmap_full(0, , );
> + ret2 = fdmap_proc(0, , );
> + ASSERT_EQ(ret2, ret1);
> + ASSERT_EQ(size2, size1);
> + for (i = 0; i < size1; i++)
> + ASSERT_EQ(fds2[i], fds1[i]);
> + free(fds1);
> + free(fds2);
> +
> + write(pipefd[1], , 1);
> + close(pipefd[0]);
> + close(pipefd[1]);
> + waitpid(pid, NULL, 0);
> +}
> +
> +TEST_HARNESS_MAIN
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
+ for (i = 0; i < size1; i++)
> + ASSERT_EQ(fds2[i], fds1[i]);
> + free(fds1);
> + free(fds2);
> +}
> +
> +TEST(init) {
> + int *fds1, *fds2;
> + size_t size1, size2, i;
> + int ret1, ret2;
> +
> + ret1 = fdmap_full(1, , );
> +
; +.I .
> +
> +For details on encoding huge page sizes not included in the header file,
> +see the discussion of the similarly named constants in
> +.BR mmap (2).
> +
> .PP
> Unused bits in
> .I flags
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
+.B MFD_HUGETLB
> +to select alternative hugetlb page sizes (respectively, 2 MB, 1 GB, ...)
> +on systems that support multiple hugetlb page sizes. Definitions for known
> +huge page sizes are included in the header file
> +.I .
> +
> +For details on encoding huge page sizes not
ons (since the intention of mremap() is to
create a new mapping based on the original mapping). Since Linux
4.14, mremap() fails with the error EINVAL in this scenario.
Does that seem okay?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
to by old_address was a private mapping (mmap(2) MAP_PRIVATE),
mremap() created a new private mapping unrelated to the original
mapping. This behavior was unintended and probably unexpected in
user-space applications (since the intention of mremap() is to
create a
+.TP
> +.BR MADV_KEEPONFORK " (since Linux 4.14)"
> +Undo the effect of an earlier
> +.BR MADV_WIPEONFORK .
> .SH RETURN VALUE
> On success,
> .BR madvise ()
> @@ -457,6 +476,18 @@ or
> but the kernel was not configured with
> .BR CONFIG_KSM .
> .TP
&g
.
> .SH RETURN VALUE
> On success,
> .BR madvise ()
> @@ -457,6 +476,18 @@ or
> but the kernel was not configured with
> .BR CONFIG_KSM .
> .TP
> +.B EINVAL
> +.I advice
> +is
> +.BR MADV_FREE
> +or
> +.BR MADV_WIPEONFORK
> +but the specified address range includes file, Huge TLB,
> +.BR MAP_SHARED ,
> +or
> +.BR VM_PFNMAP
> +ranges.
> +.TP
> .B EIO
> (for
> .BR MADV_WILLNEED )
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
l
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
> CC: Michael Kerrisk <mtk.manpa...@gmail.com>
> CC: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> Link:
> https://stackoverflow.com/questions/45970525/is-the-example-in-the-membarrier-man-p
l
> Signed-off-by: Mathieu Desnoyers
> CC: Michael Kerrisk
> CC: Paul E. McKenney
> Link:
> https://stackoverflow.com/questions/45970525/is-the-example-in-the-membarrier-man-page-pointless-in-x86
> Link: https://lwn.net/Art
On 09/15/2017 12:25 AM, NeilBrown wrote:
> On Thu, Sep 14 2017, Michael Kerrisk (man-pages) wrote:
>
>> Hi Neil,
>>
>> On 25 August 2017 at 07:32, NeilBrown <ne...@suse.com> wrote:
>>>
>>> Expand on the relationship between fstatat() and the other
On 09/15/2017 12:25 AM, NeilBrown wrote:
> On Thu, Sep 14 2017, Michael Kerrisk (man-pages) wrote:
>
>> Hi Neil,
>>
>> On 25 August 2017 at 07:32, NeilBrown wrote:
>>>
>>> Expand on the relationship between fstatat() and the other
>&g
---
pthread_mutex_consistent.3
Yubin Ruan, Michael Kerrisk
New page documenting pthread_mutex_consistent(3)
pthread_mutexattr_getpshared.3
Michael Kerrisk
New page for pthread_mutexattr_getpshared(3) and
pthread_mutexattr_setpshared(3)
pthread_mutexattr_init.3
Michael Kerrisk
---
pthread_mutex_consistent.3
Yubin Ruan, Michael Kerrisk
New page documenting pthread_mutex_consistent(3)
pthread_mutexattr_getpshared.3
Michael Kerrisk
New page for pthread_mutexattr_getpshared(3) and
pthread_mutexattr_setpshared(3)
pthread_mutexattr_init.3
Michael Kerrisk
gt; If
> @@ -474,15 +494,6 @@ fields may be less portable.
> The interpretation differs between systems,
> and possibly on a single system when NFS mounts are involved.)
> .SH NOTES
> -On Linux,
> -.BR lstat ()
> -will generally not trigger automounter action, whereas
> -.
interpretation differs between systems,
> and possibly on a single system when NFS mounts are involved.)
> .SH NOTES
> -On Linux,
> -.BR lstat ()
> -will generally not trigger automounter action, whereas
> -.BR stat ()
> -will (but see the description of the
> -.BR fstatat ()
> -.B AT_NO_AUTOMOUNT
> -fag, above).
> -.\"
> .SS Timestamp fields
> Older kernels and older standards did not support nanosecond timestamp
> fields.
> --
> 2.14.0.rc0.dirty
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
a few possible fixes.
> There may be better / more consistent ways to fix the overflows and
> procfs bugs, but I figured I'd throw an RFC w/code out there for initial
> conversation. Suggestions welcome!
Thank for working on this. I have no improvements to suggest. The
patches all loo
There may be better / more consistent ways to fix the overflows and
> procfs bugs, but I figured I'd throw an RFC w/code out there for initial
> conversation. Suggestions welcome!
Thank for working on this. I have no improvements to suggest. The
patches all look sane to me. For the whol
ter action for direct automount
> points, though they may (prior to 4.14) for indirect automount
> points.
>
>
> The more precise details, that automount action for indirect automount
> points is not triggered when the 'browse' option is used, is probably
> not n
direct automount
> points, though they may (prior to 4.14) for indirect automount
> points.
>
>
> The more precise details, that automount action for indirect automount
> points is not triggered when the 'browse' option is used, is probably
> not necessary.
>
> Ian
e this
> +over
> +.BR open (2)
> +with the path provided by
> +.BR ptsname (3),
> +and similar library methods that have insecure APIs (since Linux 4.13).
> .PP
> The BSD ioctls
> .BR TIOCSTOP ,
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
e given
> +.BR open (2)-style
> +.IR flags ,
> +regardless of whether the path is accessible through the calling process's
> +mount namespaces.
> +
> +Security-conscious programs interacting with namespaces may wish to use this
> +over
> +.BR open (2)
> +with the path provided
pages
-
namespaces.7
Kirill Tkhai [Michael Kerrisk]
Document the /proc/[pid]/ns/pid_for_children file
Changes to individual pages
---
ldd.1
Michael Kerrisk
'objdump -p prog | grep NEEDED' doesn't give quite
pages
-
namespaces.7
Kirill Tkhai [Michael Kerrisk]
Document the /proc/[pid]/ns/pid_for_children file
Changes to individual pages
---
ldd.1
Michael Kerrisk
'objdump -p prog | grep NEEDED' doesn't give quite
f("sigwait signal: %d\n", signal);
> }
>
> sleep(1);
>
> printf("Unblock\n");
> sigprocmask(SIG_UNBLOCK, , NULL);
>
> sigpending();
> if (sigismember(, sig)) {
> /* This is not reached */
>
t;sigwait signal: %d\n", signal);
> }
>
> sleep(1);
>
> printf("Unblock\n");
> sigprocmask(SIG_UNBLOCK, , NULL);
>
> sigpending();
> if (sigismember(, sig)) {
> /* This is not reached */
> printf("Timer signal
Hello Stas,
On 05/24/2017 01:01 AM, Stas Sergeev wrote:
> 23.05.2017 15:26, Michael Kerrisk (man-pages) пишет:
>>>>> and posix seems to allow any
>>>>> other value for enable, which can be (on linux) SS_ONSTACK,
>>>>> not only 0.
>&g
Hello Stas,
On 05/24/2017 01:01 AM, Stas Sergeev wrote:
> 23.05.2017 15:26, Michael Kerrisk (man-pages) пишет:
>>>>> and posix seems to allow any
>>>>> other value for enable, which can be (on linux) SS_ONSTACK,
>>>>> not only 0.
>&g
Hello Stas,
On 23 May 2017 at 13:03, Stas Sergeev <s...@list.ru> wrote:
> 23.05.2017 13:35, Michael Kerrisk (man-pages) пишет:
>>
>> Hello Stas,
>
> Hi. :)
>
>
>>> Because I don't think we broke the existing code, or did we?
>>
>> Pro
Hello Stas,
On 23 May 2017 at 13:03, Stas Sergeev wrote:
> 23.05.2017 13:35, Michael Kerrisk (man-pages) пишет:
>>
>> Hello Stas,
>
> Hi. :)
>
>
>>> Because I don't think we broke the existing code, or did we?
>>
>> Probably not, but it see
Hello Stas,
On 05/23/2017 01:36 AM, Stas Sergeev wrote:
> 22.05.2017 23:38, Michael Kerrisk (man-pages) пишет:
>> Stas,
>>
>> I have attempted to document the SS_AUTODISARM feature that you added
>> in Linux 4.7.
>>
>> Could you please take a look at the SS_
Hello Stas,
On 05/23/2017 01:36 AM, Stas Sergeev wrote:
> 22.05.2017 23:38, Michael Kerrisk (man-pages) пишет:
>> Stas,
>>
>> I have attempted to document the SS_AUTODISARM feature that you added
>> in Linux 4.7.
>>
>> Could you please take a look at the SS_
siglongjmp(3),
sigsetjmp(3), signal(7)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
siglongjmp(3),
sigsetjmp(3), signal(7)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
y useful for setting or clearing the "read-only"
> +flag on a mount point without changing the underlying filesystem.
> +Specifying
> .IR mountflags
> as:
>
> MS_REMOUNT | MS_BIND | MS_RDONLY
>
> -Note that only the
> -.BR MS_RDONLY
> -setting of
ting or clearing the "read-only"
> +flag on a mount point without changing the underlying filesystem.
> +Specifying
> .IR mountflags
> as:
>
> MS_REMOUNT | MS_BIND | MS_RDONLY
>
> -Note that only the
> -.BR MS_RDONLY
> -setting of the bind mount can be c
be of interest
to readers on LKML is shown below.
Cheers,
Michael
Changes in man-pages-4.11
Released: 2017-05-03, Baden, Switzerland
New and rewritten pages
---
ioctl_userfaultfd.2
Michael Kerrisk, Mike Rapoport
New page describing
be of interest
to readers on LKML is shown below.
Cheers,
Michael
Changes in man-pages-4.11
Released: 2017-05-03, Baden, Switzerland
New and rewritten pages
---
ioctl_userfaultfd.2
Michael Kerrisk, Mike Rapoport
New page describing
On 05/02/2017 11:48 AM, Mike Rapoport wrote:
> On Mon, May 01, 2017 at 08:34:07PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Mike,
>>
>> On 05/01/2017 07:43 AM, Mike Rapoport wrote:
>>> Hi Michael,
>>>
>>> These updates pretty much complete th
On 05/02/2017 11:48 AM, Mike Rapoport wrote:
> On Mon, May 01, 2017 at 08:34:07PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Mike,
>>
>> On 05/01/2017 07:43 AM, Mike Rapoport wrote:
>>> Hi Michael,
>>>
>>> These updates pretty much complete th
401 - 500 of 2778 matches
Mail list logo
