Hi Dave,
On 9 December 2015 at 16:48, Dave Hansen wrote:
> Hi Michael,
>
> Thanks for all the comments! I'll fix most of it when I post a new
> version of the manpage, but I have a few general questions.
>
> On 12/09/2015 03:08 AM, Michael Kerrisk (man-pages) wrote:
>>
Hi Dave,
On 7 December 2015 at 17:44, Dave Hansen wrote:
> On 12/04/2015 10:50 PM, Michael Kerrisk (man-pages) wrote:
>> On 12/04/2015 02:15 AM, Dave Hansen wrote:
>>> From: Dave Hansen
>>>
>>> mprotect_key() is just like mprotect, except it also takes
Hi Dave,
On 7 December 2015 at 17:44, Dave Hansen <d...@sr71.net> wrote:
> On 12/04/2015 10:50 PM, Michael Kerrisk (man-pages) wrote:
>> On 12/04/2015 02:15 AM, Dave Hansen wrote:
>>> From: Dave Hansen <dave.han...@linux.intel.com>
>>>
>>> mpro
Hi Dave,
On 9 December 2015 at 16:48, Dave Hansen <d...@sr71.net> wrote:
> Hi Michael,
>
> Thanks for all the comments! I'll fix most of it when I post a new
> version of the manpage, but I have a few general questions.
>
> On 12/09/2015 03:08 AM, Michael K
PERF_SAMPLE_BRANCH_CALL_STACK
Vince Weaver
4.1 adds aux_watermark
Vince Weaver
Add possibility of EBUSY error
prctl.2
Andy Lutomirski [Kees Cook, Serge Hallyn]
Document operations for ambient capabilities
Michael Kerrisk
Rework PR_CAP_AMBIENT text
Note that arg4
PERF_SAMPLE_BRANCH_CALL_STACK
Vince Weaver
4.1 adds aux_watermark
Vince Weaver
Add possibility of EBUSY error
prctl.2
Andy Lutomirski [Kees Cook, Serge Hallyn]
Document operations for ambient capabilities
Michael Kerrisk
Rework PR_CAP_AMBIENT text
Note that arg4
(vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));
>
> /* newflags >> 4 shift VM_MAY% in place of VM_% */
> @@ -443,3 +452,18 @@ out:
> up_write(>mm->mmap_sem);
> return error;
> }
> +
> +SYSCALL_DEFINE3(mprotect, unsigned long, start
Hi Andrea,
On 09/11/2015 10:47 AM, Michael Kerrisk (man-pages) wrote:
> On 05/14/2015 07:30 PM, Andrea Arcangeli wrote:
>> Add documentation.
>
> Hi Andrea,
>
> I do not recall... Did you write a man page also for this new system call?
No response to my last mail, so I'll
e grace period. Its implementation will likely depend on reading
> the cpu_curr()->mm without holding each CPU's rq lock.
>
> This patch adds the system call to x86 and to asm-generic.
>
> [1] http://urcu.so
>
> Signed-off-by: Mathieu Desnoyers
> Reviewed-by: Paul E. M
and execution of programs by root" .)
> +.TP
> +.B SECBIT_NO_CAP_AMBIENT_RAISE
> +Setting this flag disallows
> +.BR PR_CAP_AMBIENT_RAISE .
> .PP
> Each of the above "base" flags has a companion "locked" flag.
> Setting any of the "locked" flags is
s.com>
> Reviewed-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> Reviewed-by: Josh Triplett <j...@joshtriplett.org>
> CC: KOSAKI Motohiro <kosaki.motoh...@jp.fujitsu.com>
> CC: Steven Rostedt <rost...@goodmis.org>
> CC: Nicholas Miell <nmi...@com
e the subsection
> .IR "Capabilities and execution of programs by root" .)
> +.TP
> +.B SECBIT_NO_CAP_AMBIENT_RAISE
> +Setting this flag disallows
> +.BR PR_CAP_AMBIENT_RAISE .
> .PP
> Each of the above "base" flags has a companion "locked&qu
Hi Andrea,
On 09/11/2015 10:47 AM, Michael Kerrisk (man-pages) wrote:
> On 05/14/2015 07:30 PM, Andrea Arcangeli wrote:
>> Add documentation.
>
> Hi Andrea,
>
> I do not recall... Did you write a man page also for this new system call?
No response to my last mail, so I'll
return error;
> }
> +
> +SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
> + unsigned long, prot)
> +{
> + return do_mprotect_pkey(start, len, prot, -1);
> +}
> +
> +SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
> +
; a66734297f78707ce39d756b656bfae861d53f62
> +.\" 7911d3f7af14a614617e38245fedf98a724e46a9
> +the behavior has changed, so that 1 now means only allow access
> +to processes with active perf events, with 2 indicating the old
> +allow-anyone-access behavior.
> .TP
> .IR /sys/bus/eve
t; bed5b25ad9c8a2f5d735ef0bc746ec870c01c1b0
> +Returned if another event already has exclusive
> +access to the PMU.
> +.TP
> .B EFAULT
> Returned if the
> .I attr
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming
ction
> +addresses in the AUX buffer with the proper executable.
> +
> +.in +4n
> +.nf
> +struct {
> +struct perf_event_header header;
> +u32 pid;
> +u32 tid;
> +};
> +.fi
> +.RS
> +.TP
> +.I pid
> +process id of the thread starting an instruction tr
rted.
> +.TP
> +.IR "aux_watermark" " (since Linux 4.1)"
> +.\" commit 1a5941312414c71dece6717da9a0fa1303127afa
> +This specifies how much data is required to trigger a
> +.B PERF_RECORD_AUX
> +sample.
> .SS Reading results
> Once a
> .BR perf_e
the aux update.
> .B PERF_AUX_FLAG_TRUNCATED
> if set then the data returned was truncated to fit the available
> buffer size.
> +.TP
> +.B PERF_AUX_FLAG_OVERWRITE
> +.\" commit 2023a0d2829e521fe6ad6b9907f3f90bfbf57142
> +if set then the data returned has overwritte
> +.TP
> +.I flags
> +describes the aux update.
> +.RS
> +.TP
> +.B PERF_AUX_FLAG_TRUNCATED
> +if set then the data returned was truncated to fit the available
> +buffer size.
> +.RE
> +.RE
> .RE
> .SS Overflow handling
> Events can be set to notify when a t
ust be a power of two.
> +These values are then passed to mmap in order to map the AUX buffer.
> +Pages in the AUX buffer are included as part of the user mlock
> +rlimit as well as the
> +.I perf_event_mlock_kb
> +allowance.
> +
> +The
> +.IR aux_head " and &q
0cb97c3d3272f8631ef17f8f0f
> +Contains the offset of the location in the mmap buffer
> +where perf sample data begins.
> +.TP
> +.IR data_size " (since Linux 4.1)"
> +.\" commit e8c6deac69629c0cb97c3d3272f8631ef17f8f0f
> +Contains the size of the perf sample region within
was created by
> +a previous
> +.BR bpf (2)
> +system call.
> .SS Using prctl
> A process can enable or disable all the event groups that are
> attached to it using the
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Prog
8b3493394d42e51cf70 +Branch is
> part of a hardware generated call stack. +This requires hardware
> support, currently only found +on Intel x86 Haswell or newer. .RE
>
> .TP -- To unsubscribe from this list: send the line "unsubscribe
> linux-man" in the body of a message t
oint event.
> +You need
> +.B CAP_SYS_ADMIN
> +privileges to use this ioctl.
> +
> +The argument is a BPF program file descriptor that was created by
> +a previous
> +.BR bpf (2)
> +system call.
> .SS Using prctl
> A process can enable or disable all the event groups
ite unread data.
> +.TP
> +.IR data_offset " (since Linux 4.1)"
> +.\" commit e8c6deac69629c0cb97c3d3272f8631ef17f8f0f
> +Contains the offset of the location in the mmap buffer
> +where perf sample data begins.
> +.TP
> +.IR data_size " (since Linux 4.1)"
&
2c44b1936bb3b135a3fac8b3493394d42e51cf70 +Branch is
> part of a hardware generated call stack. +This requires hardware
> support, currently only found +on Intel x86 Haswell or newer. .RE
>
> .TP -- To unsubscribe from this list: send the line "unsubscribe
> linux-man" in the bod
eds to be set to the desired buffer size.
> +The desired offset and size must be page aligned, and the size
> +must be a power of two.
> +These values are then passed to mmap in order to map the AUX buffer.
> +Pages in the AUX buffer are included as part of the user mlock
> +rlimit as well as the
" and " aux_tail
> ring buffer pointers have the same behavior and ordering
> @@ -2476,6 +2485,10 @@ describes the aux update.
> .B PERF_AUX_FLAG_TRUNCATED
> if set then the data returned was truncated to fit the available
> buffer size.
> +.TP
> +.B PERF_AUX_FLAG_OVERWRI
+.TP
> +.I aux_offset
> +offset in the AUX mmap region where the new data begins.
> +.TP
> +.I aux_size
> +size of the data made available.
> +.TP
> +.I flags
> +describes the aux update.
> +.RS
> +.TP
> +.B PERF_AUX_FLAG_TRUNCATED
> +if set then the data returned was trunc
CLOCK_MONOTONIC , CLOCK_MONOTONIC_RAW , CLOCK_REALTIME ,
> .BR CLOCK_BOOTTIME ", and " CLOCK_TAI
> currently supported.
> +.TP
> +.IR "aux_watermark" " (since Linux 4.1)"
> +.\" commit 1a5941312414c71dece6717da9a0fa1303127afa
> +This specifies how much d
can be disabled by echoing 0 to the file.
> +
> +As of Linux 4.0
> +.\" a66734297f78707ce39d756b656bfae861d53f62
> +.\" 7911d3f7af14a614617e38245fedf98a724e46a9
> +the behavior has changed, so that 1 now means only allow access
> +to processes with active perf events, wit
.I pid
> is not valid.
> .TP
> +.BR EBUSY " (since Linux 4.1)"
> +.\" bed5b25ad9c8a2f5d735ef0bc746ec870c01c1b0
> +Returned if another event already has exclusive
> +access to the PMU.
> +.TP
> .B EFAULT
> Returned if the
> .I attr
>
--
Mic
u32 tid;
> +};
> +.fi
> +.RS
> +.TP
> +.I pid
> +process id of the thread starting an instruction trace.
> +.TP
> +.I tid
> +thread id of the thread starting an instruction trace.
> +.RE
> .RE
> .SS Overflow handling
> Events can be set to notify when a thres
On 08/19/2015 03:40 PM, Thomas Gleixner wrote:
> On Wed, 5 Aug 2015, Darren Hart wrote:
>> On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
>>> .\" FIXME XXX = Start of adapted Hart/Guniguntala text =
>>> .\" The
Hello Thomas,
Thanks for the follow up!
Some open questions below are marked with the string ###.
On 08/19/2015 04:17 PM, Thomas Gleixner wrote:
> On Sat, 8 Aug 2015, Michael Kerrisk (man-pages) wrote:
>>>>FUTEX_CMP_REQUEUE (since Linux 2.6.7)
>>>>
Hello Thomas,
Thanks for the follow up!
Some open questions below are marked with the string ###.
On 08/19/2015 04:17 PM, Thomas Gleixner wrote:
> On Sat, 8 Aug 2015, Michael Kerrisk (man-pages) wrote:
>>>>FUTEX_CMP_REQUEUE (since Linux 2.6.7)
>>>>
On 08/19/2015 03:40 PM, Thomas Gleixner wrote:
> On Wed, 5 Aug 2015, Darren Hart wrote:
>> On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
>>> .\" FIXME XXX = Start of adapted Hart/Guniguntala text =
>>> .\" The
; uattr, unsigned int, siz
> case BPF_PROG_LOAD:
> err = bpf_prog_load();
> break;
> + case BPF_PROG_DUMP:
> + err = bpf_prog_dump(, uattr);
> + break;
> default:
> err = -EIN
> +CAP_SYS_ADMIN) != 0)
> + return -EACCES;
> +
> /*
> * Make sure we cannot change seccomp or nnp state via TSYNC
> * while another thread is in the middle of calling exec.
> @@ -875,6 +982,8 @@ static long
t; +
> static int __init register_sk_filter_ops(void)
> {
> bpf_register_prog_type(_filter_type);
> bpf_register_prog_type(_cls_type);
> bpf_register_prog_type(_act_type);
> + bpf_register_prog_type(_type);
>
> return 0;
> }
> --
> 2
gt; + if (cur->prog == prog) {
> + if (!cur->prev)
> + ret = -ENOENT;
> + else
> + ret = bpf_prog_set(fd, cur->prev->prog);
> + break;
&
will not fail
> +with
> +.B ENOMEM
> +if the area cannot be populated.
> .SH SEE ALSO
> .BR brk (2),
> .BR getpagesize (2),
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/train
ng incoming userfaults. After sending each page of
> +course the bitmap is updated accordingly. It's also useful to avoid
> +sending the same page twice (in case the userfault is read by the
> +postcopy thread just before UFFDIO_COPY|ZEROPAGE runs in the migration
> +thread).
> --
>
+.TP
> +.B SECBIT_NO_CAP_AMBIENT_RAISE
> +Setting this flag disallows
> +.BR PR_CAP_AMBIENT_RAISE .
> .PP
> Each of the above "base" flags has a companion "locked" flag.
> Setting any of the "locked" flags is irreversible,
> @@ -1079,8 +1098,9 @@ correspo
we seek
> +over it when receiving incoming userfaults. After sending each page of
> +course the bitmap is updated accordingly. It's also useful to avoid
> +sending the same page twice (in case the userfault is read by the
> +postcopy thread just before UFFDIO_COPY|ZEROPAGE runs in the migrat
execution of programs by root" .)
> +.TP
> +.B SECBIT_NO_CAP_AMBIENT_RAISE
> +Setting this flag disallows
> +.BR PR_CAP_AMBIENT_RAISE .
> .PP
> Each of the above "base" flags has a companion "locked" flag.
> Setting any of the "locked" flags is
BR mremap ()
> +call will make a best effort to populate the new area but will not fail
> +with
> +.B ENOMEM
> +if the area cannot be populated.
> .SH SEE ALSO
> .BR brk (2),
> .BR getpagesize (2),
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.
d int, siz
> case BPF_PROG_LOAD:
> err = bpf_prog_load();
> break;
> + case BPF_PROG_DUMP:
> + err = bpf_prog_dump(, uattr);
> + break;
> default:
> err = -EINVAL;
>
c int __init register_sk_filter_ops(void)
> {
> bpf_register_prog_type(_filter_type);
> bpf_register_prog_type(_cls_type);
> bpf_register_prog_type(_act_type);
> + bpf_register_prog_type(_type);
>
> return 0;
> }
> --
> 2.1.4
>
ECCOMP_MODE_FILTER)
> + return -EINVAL;
> +
> + prog = bpf_prog_get(fd);
> + if (IS_ERR(prog)) {
> + ret = PTR_ERR(prog);
> + goto out;
> + }
> +
> + for (cur = child->seccomp.filter; cur; cur = cur->prev) {
> +
CAP_SYS_ADMIN) != 0)
> + return -EACCES;
> +
> /*
> * Make sure we cannot change seccomp or nnp state via TSYNC
> * while another thread is in the middle of calling exec.
> @@ -875,6 +982,8 @@ static long do_seccomp
VAL;
>>
>> + /*
>> +* Installing a seccomp filter requires that the task has
>> + * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
>> +* This avoids scenarios where unprivileged tasks can affect the
>> +* behavi
Hi Kees,
On 08/27/2015 06:32 AM, Kees Cook wrote:
> On Wed, Aug 26, 2015 at 6:42 PM, Michael Kerrisk (man-pages)
> wrote:
>> Hello Kees, Will,
>>
>> In recent times I've been asked a couple of questions about seccomp(),
>> and it seems like it would be wort
Hi Kees,
On 08/27/2015 06:32 AM, Kees Cook wrote:
> On Wed, Aug 26, 2015 at 6:42 PM, Michael Kerrisk (man-pages)
> <mtk.manpa...@gmail.com> wrote:
>> Hello Kees, Will,
>>
>> In recent times I've been asked a couple of questions about seccomp(),
>> and
>> + /*
>> +* Installing a seccomp filter requires that the task has
>> +* CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
>> +* This avoids scenarios where unprivileged tasks can affect the
>> +* behavior of p
which filter rule causes
the sandboxed program to fail. Is this correct, or is there another
reason?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list
which filter rule causes
the sandboxed program to fail. Is this correct, or is there another
reason?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list
t see how O_BENEATH could be a
"file *status* flag"), your patch should also add O_BENEATH to the
list in that paragraph.
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 is correct (I can't see how O_BENEATH could be a
file *status* flag), your patch should also add O_BENEATH to the
list in that paragraph.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org
pages
---
dladdr.3
Michael Kerrisk
New page documenting dladdr() and dladdr1()
Relocate/rewrite dladdr() text formerly contained in dlopen(3).
Add documentation of dladdr1().
dlinfo.3
Michael Kerrisk
New page describing dlinfo(3
pages
---
dladdr.3
Michael Kerrisk
New page documenting dladdr() and dladdr1()
Relocate/rewrite dladdr() text formerly contained in dlopen(3).
Add documentation of dladdr1().
dlinfo.3
Michael Kerrisk
New page describing dlinfo(3
Hi Darren,
Some of my comments below will refer to the reply I just sent
to tglx (and the list) a few minutes ago.
On 08/06/2015 12:21 AM, Darren Hart wrote:
> On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hello all,
>>
>
> Michael, thank y
FIFO order.
>>
>> Maybe don't mention the effects of SCHED_OTHER, order by nice value is
>> 'wrong'.
>
> Indeed.
>
>> Also, this code seems to use plist, which means it won't do the right
>> thing for SCHED_DEADLINE either.
>>
>> Do we want to go
PM, Thomas Gleixner wrote:
> On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
>>FUTEX_CLOCK_REALTIME (since Linux 2.6.28)
>> This option bit can be employed only with the
>> FUTEX_WAIT_BITSET and F
wrote:
On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
FUTEX_CLOCK_REALTIME (since Linux 2.6.28)
This option bit can be employed only with the
FUTEX_WAIT_BITSET and FUTEX_WAIT_REQUEUE_PI operations.
If this option is set
that?
I think so.
So, no change to this piece of text then?
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 unsubscribe from this list: send the line unsubscribe linux
Hi Darren,
Some of my comments below will refer to the reply I just sent
to tglx (and the list) a few minutes ago.
On 08/06/2015 12:21 AM, Darren Hart wrote:
On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
Hello all,
Michael, thank you for your diligence
On 07/29/2015 06:21 AM, Darren Hart wrote:
> On Tue, Jul 28, 2015 at 09:11:41PM -0700, Darren Hart wrote:
>> On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
>>> On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
>>
>> ...
>>
>>
On 07/29/2015 06:21 AM, Darren Hart wrote:
On Tue, Jul 28, 2015 at 09:11:41PM -0700, Darren Hart wrote:
On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
...
FUTEX_REQUEUE (since Linux 2.6.0)
.\ FIXME(Torvald
On 07/28/2015 07:52 PM, Davidlohr Bueso wrote:
> On Tue, 2015-07-28 at 09:44 +0200, Michael Kerrisk (man-pages) wrote:
>> Maybe you still have some further improvements for the paragraph?
>
> Nah, this is fine enough. Looks good.
Okay. Thanks. I added a Reviewed-by: for you.
C
Hi David,
On 07/28/2015 05:16 AM, Davidlohr Bueso wrote:
> On Mon, 2015-07-27 at 13:10 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi David,
>>
>> On 03/31/2015 04:45 PM, Davidlohr Bueso wrote:
>>> On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
ry point.
Thanks. Added.
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
Hi David,
On 07/28/2015 05:16 AM, Davidlohr Bueso wrote:
On Mon, 2015-07-27 at 13:10 +0200, Michael Kerrisk (man-pages) wrote:
Hi David,
On 03/31/2015 04:45 PM, Davidlohr Bueso wrote:
On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
The condition is represented by the futex
On 07/28/2015 07:52 PM, Davidlohr Bueso wrote:
On Tue, 2015-07-28 at 09:44 +0200, Michael Kerrisk (man-pages) wrote:
Maybe you still have some further improvements for the paragraph?
Nah, this is fine enough. Looks good.
Okay. Thanks. I added a Reviewed-by: for you.
Cheers,
Michael
,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 07/27/2015 04:17 PM, Heinrich Schuchardt wrote:
> instruction. A thread maybe unable
>
> to << missing word
>
> acquire a lock because it is
> already acquired by another thread. It then may pass the lock's
> flag as futex word and the value representing the acquired state
> as the expected
Hello all,
>From a draft sent out in March, I got a few useful comments that
I've now incorporated into this draft. And I got some complaints
from people who did not want to read groff source. My point
was that there are a bunch of FIXMEs in the page source that I
wanted people to look at...
elays?
Many of the pages that talk about system calls that have timeouts
carry similar language, since people often have confusions about what time
timeout (e.g., that it's an upper limit, not a minimum; or that it's precise
to some very small granularity). Why do you think the language here is a
problem?
On 04/15/2015 12:28 PM, Torvald Riegel wrote:
> On Tue, 2015-04-14 at 23:40 +0200, Thomas Gleixner wrote:
>> On Sat, 28 Mar 2015, Peter Zijlstra wrote:
>>> On Sat, Mar 28, 2015 at 09:53:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>>> So, please take a look at
-1 and set errno to indi‐
cate the cause of the error.
>>EINVAL The operation in futex_op is one of those that employs a
>> time???
>> out, but the supplied timeout argument was invalid (tv_sec
>> was
>> less than zero, or tv_
;word", you should probably state right away that
> futexes are only 32bit.
So, I made the opening sentence here:
The condition is represented by the futex word, which is an
address in memory supplied to the futex() system call, and the
32-bit value at this memory
On 03/31/2015 03:48 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>> When executing a futex operation that requests to block a thread,
>> the kernel will only block if the futex word has the value that the
>> calling thread supplied as expected va
f time and energy at a certain point. And also got a little
disheartened that I got more people complaining about groff markup
than actually looked looked at the FIXMEs in the page source :-).
I'll try to reboot the process.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://ww
by the futex word, which is an
address in memory supplied to the futex() system call, and the
32-bit value at this memory location.
Okay?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training
was
less than zero, or tv_nsec was not less than 1000,000,000).
1,000...?
Fixed.
Thanks for the comments!
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 03/31/2015 03:48 AM, Rusty Russell wrote:
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes:
When executing a futex operation that requests to block a thread,
the kernel will only block if the futex word has the value that the
calling thread supplied as expected value.
The load
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
Hello all,
From a draft sent out in March, I got a few useful comments that
I've now incorporated into this draft. And I got some complaints
from people who did not want to read groff source. My point
was that there are a bunch of FIXMEs in the page source that I
wanted people to look at...
On 04/15/2015 12:28 PM, Torvald Riegel wrote:
On Tue, 2015-04-14 at 23:40 +0200, Thomas Gleixner wrote:
On Sat, 28 Mar 2015, Peter Zijlstra wrote:
On Sat, Mar 28, 2015 at 09:53:21AM +0100, Michael Kerrisk (man-pages) wrote:
So, please take a look at the page below. At this point,
I would most
confusions about what time
timeout (e.g., that it's an upper limit, not a minimum; or that it's precise
to some very small granularity). Why do you think the language here is a
problem?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX
On 07/27/2015 04:17 PM, Heinrich Schuchardt wrote:
instruction. A thread maybe unable
to missing word
acquire a lock because it is
already acquired by another thread. It then may pass the lock's
flag as futex word and the value representing the acquired state
as the expected value to a
provided below, and of course available in Git.
Cheers,
Michael
.\" Copyright (C) 2015 Alexei Starovoitov
.\" and Copyright (C) 2015 Michael Kerrisk
.\"
.\" %%%LICENSE_START(VERBATIM)
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual
Hello David,
On 23 July 2015 at 22:52, David Rientjes wrote:
> On Thu, 23 Jul 2015, Michael Kerrisk (man-pages) wrote:
>
>> >> Should we also add a similar comment for the mmap offset? Currently
>> >> the man page says:
>> >>
>> >> &
Hello David,
On 23 July 2015 at 22:52, David Rientjes rient...@google.com wrote:
On Thu, 23 Jul 2015, Michael Kerrisk (man-pages) wrote:
Should we also add a similar comment for the mmap offset? Currently
the man page says:
offset must be a multiple of the page size as returned
work,
which I've marked with FIXMEs. Could you take a look at these please?
Current page source provided below, and of course available in Git.
Cheers,
Michael
.\ Copyright (C) 2015 Alexei Starovoitov a...@kernel.org
.\ and Copyright (C) 2015 Michael Kerrisk mtk.manpa...@gmail.com
A selection of changes in this release that may be interesting
for readers of this list is shown below.
Cheers,
Michael
Changes in man-pages-4.01
New and rewritten pages
---
bpf.2
Alexei Starovoitov, Michael Kerrisk [Daniel
Hi Daniel,
On 07/23/2015 02:47 PM, Daniel Borkmann wrote:
> On 07/23/2015 01:23 PM, Michael Kerrisk (man-pages) wrote:
> ...
>>> Btw, a user obviously can close() the map fds if he
>>> wants to, but ultimatively they're freed when the program unloads.
>>
&
ents of mmap() and munmap() differ somewhat from the
requirements for mappings that use the native system page size.
For mmap(), offset must be a multiple of the underlying huge page
size. The system automatically aligns length to be a multiple of
the underlying
On 07/23/2015 12:03 AM, David Rientjes wrote:
> On Wed, 22 Jul 2015, Michael Kerrisk (man-pages) wrote:
>
>>> diff --git a/man2/mmap.2 b/man2/mmap.2
>>> --- a/man2/mmap.2
>>> +++ b/man2/mmap.2
>>> @@ -383,6 +383,10 @@ All pages containing a par
1101 - 1200 of 2778 matches
Mail list logo
