Daniel Borkmann | 30 Jul 00:25 2015
Picon

[PATCH man v4] bpf.2: various updates/follow-ups to address some fixmes

A couple of follow-ups to the bpf(2) man-page, besides others:

 * Description of map data types
 * Explanation on eBPF tail calls and program arrays
 * Paragraph on tc holding ref of the eBPF program in the kernel
 * Updated ASCII image with tc ingress and egress invocations
 * __sync_fetch_and_add() and example usage mentioned on arrays
 * minor reword on the licensing and other minor fixups

Signed-off-by: Daniel Borkmann <daniel@...>
---
 v3->v4:
  - s/bpf (2)/bpf ()/, thanks Mike!
 v2->v3:
  - Feedback from Michael, thanks!
 v1->v2:
  - Reworded __sync_fetch_and_add sentence, hope that's better.

 man2/bpf.2 | 147 +++++++++++++++++++++++++++++++++++++------------------------
 1 file changed, 89 insertions(+), 58 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 2b96ebc..85b1631 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
 <at>  <at>  -51,42 +51,45  <at>  <at>  opcode extension provided by eBPF)
 and access shared data structures such as eBPF maps.
 .\"
 .SS Extended BPF Design/Architecture
-.\"
(Continue reading)

Mike Frysinger | 29 Jul 07:56 2015
Picon

[PATCH] bpf(2): fix func signature

Also add a missing period in the errno section.
---
 man2/bpf.2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 2b96ebc..d7e638c 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
 <at>  <at>  -30,7 +30,7  <at>  <at>  bpf - perform a command on an extended BPF map or program
 .nf
 .B #include <linux/bpf.h>
 .sp
-.BI "int bpf(int cmd, union bpf_attr *attr, unsigned int size);
+.BI "int bpf(int " cmd ", union bpf_attr *" attr ", unsigned int " size ");
 .SH DESCRIPTION
 The
 .BR bpf ()
 <at>  <at>  -969,7 +969,7  <at>  <at>  Cannot allocate sufficient memory.
 .TP
 .B EBADF
 .I fd
-is not an open file descriptor
+is not an open file descriptor.
 .TP
 .B EFAULT
 One of the pointers
--

-- 
2.4.4

(Continue reading)

Daniel Borkmann | 28 Jul 22:25 2015
Picon

[PATCH man v3] bpf.2: various updates/follow-ups to address some fixmes

A couple of follow-ups to the bpf(2) man-page, besides others:

 * Description of map data types
 * Explanation on eBPF tail calls and program arrays
 * Paragraph on tc holding ref of the eBPF program in the kernel
 * Updated ASCII image with tc ingress and egress invocations
 * __sync_fetch_and_add() and example usage mentioned on arrays
 * minor reword on the licensing and other minor fixups

Signed-off-by: Daniel Borkmann <daniel@...>
---
 v2->v3:
  - Feedback from Michael
 v1->v2:
  - Reworded __sync_fetch_and_add sentence, hope that's better.

 man2/bpf.2 | 149 +++++++++++++++++++++++++++++++++++++------------------------
 1 file changed, 90 insertions(+), 59 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 2b96ebc..f6a1353 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
 <at>  <at>  -33,7 +33,7  <at>  <at>  bpf - perform a command on an extended BPF map or program
 .BI "int bpf(int cmd, union bpf_attr *attr, unsigned int size);
 .SH DESCRIPTION
 The
-.BR bpf ()
+.BR bpf (2)
 system call performs a range of operations related to extended
(Continue reading)

Daniel Borkmann | 28 Jul 20:59 2015
Picon

[PATCH man v2] bpf.2: various updates/follow-ups to address some fixmes

A couple of follow-ups to the bpf(2) man-page.

Signed-off-by: Daniel Borkmann <daniel@...>
---
 v1->v2:
  - Reworded __sync_fetch_and_add sentence, hope that's better.

 man2/bpf.2 | 143 ++++++++++++++++++++++++++++++++++++-------------------------
 1 file changed, 85 insertions(+), 58 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 2b96ebc..189582d 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
 <at>  <at>  -51,42 +51,41  <at>  <at>  opcode extension provided by eBPF)
 and access shared data structures such as eBPF maps.
 .\"
 .SS Extended BPF Design/Architecture
-.\"
-.\" FIXME In the following line, what does "different data types" mean?
-.\"       Are the values in a map not just blobs?
-.\" Daniel Borkmann commented:
-.\"     Sort of, currently, these blobs can have different sizes of keys
-.\"     and values (you can even have structs as keys). For the map itself
-.\"     they are treated as blob internally. However, recently, bpf tail call
-.\"     got added where you can lookup another program from an array map and
-.\"     call into it. Here, that particular type of map can only have entries
-.\"     of type of eBPF program fd. I think, if needed, adding a paragraph to
-.\"     the tail call could be done as follow-up after we have an initial man
-.\"     page in the tree included.
(Continue reading)

Daniel Borkmann | 28 Jul 17:29 2015
Picon

[PATCH man] ebpf.2: various updates to address some fixmes

A couple of follow-ups to the bpf(2) man-page.

Signed-off-by: Daniel Borkmann <daniel@...>
---
 man2/bpf.2 | 140 ++++++++++++++++++++++++++++++++++++-------------------------
 1 file changed, 82 insertions(+), 58 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 2b96ebc..8df70c4 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
 <at>  <at>  -51,42 +51,41  <at>  <at>  opcode extension provided by eBPF)
 and access shared data structures such as eBPF maps.
 .\"
 .SS Extended BPF Design/Architecture
-.\"
-.\" FIXME In the following line, what does "different data types" mean?
-.\"       Are the values in a map not just blobs?
-.\" Daniel Borkmann commented:
-.\"     Sort of, currently, these blobs can have different sizes of keys
-.\"     and values (you can even have structs as keys). For the map itself
-.\"     they are treated as blob internally. However, recently, bpf tail call
-.\"     got added where you can lookup another program from an array map and
-.\"     call into it. Here, that particular type of map can only have entries
-.\"     of type of eBPF program fd. I think, if needed, adding a paragraph to
-.\"     the tail call could be done as follow-up after we have an initial man
-.\"     page in the tree included.
-.\"
 eBPF maps are a generic data structure for storage of different data types.
+Data types are generally treated as binary blobs, so a user just specifies
(Continue reading)

Davidlohr Bueso | 28 Jul 08:50 2015
Picon

Re: Aw: Re: Revised futex(2) man page for review

On Tue, 2015-07-28 at 07:44 +0200, Heinrich Schuchardt wrote:
> Hello David,
> 
> >> A futex is in essence a 32-bit user-space address.
> I know what a 32 bit integer is.
> I am not aware of 32 bit addresses on my 64 bit operating system.

Well I am referring to in the context of a user-space address, such as a
32-bit lock ('int'), but yes, my text is misleading. In fact we
obviously need to cast to the word size for doing gup_fast, among other
tasks.

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michael Kerrisk (man-pages | 27 Jul 14:07 2015
Picon

Next round: revised futex(2) man page for review

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... Anyway, this time, I will take
a different tack, interspersing the FIXMEs in a rendered 
version of the page. I'd greatly appreciate help with those FIXMEs.

The current page source can be found at in a branch at
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?h=draft_futex

===

As becomes quickly obvious upon reading it, the current futex(2) 
man page is in a sorry state, lacking many important details, and
also the various additions that have been made to the interface
over the last years. I've been working on revising it, first
of all based on input I got in response to a request for help
last year (http://thread.gmane.org/gmane.linux.kernel/1703405), 
especially taking Thomas Gleixner's input 
(http://thread.gmane.org/gmane.linux.kernel/1703405/focus=2952) 
into account. I also got some further offlist input from Darren
 Hart, Torvald Riegel, and Davidlohr Bueso that has been
incorporated into the revised draft. Other than that, I got
some useful info out of Ulrich Drepper's paper (cited at the
end of the page) and one or two web pages (cited in the page
source).

(Continue reading)

Michael Kerrisk (man-pages | 26 Jul 22:24 2015
Picon

Re: For review: nptl(7) man page

On 07/24/2015 05:51 PM, Nicholas Miell wrote:
> PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
> the mutex can operate on the mutex and POSIX basically ignores the idea
> that different processes could be running completely incompatible
> executables or whatever.
> 
> pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
> structure size and layout between i386 and x86_64.
> 
> Most importantly, the positions of the __nusers and __kind fields are
> swapped (this looks to be an oversight dating back to 2003 when __nusers
> was first introduced and carefully preserved when the separate i386 and
> x86_64 versions of pthreadtypes.h were merged into the single x86 version),
> which means that when the lock and unlock functions attempt to figure out
> what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
> wrong field if the mutex is from the wrong architecture and then things
> will break.
> 
> And then there's the fact that the rest of the struct is a union in the
> 32-bit version and flat in the 64-bit version, but that could have been
> worked around if you put a flag in the __kind field that tells the 64-bit
> pthread library that it is looking at a 32-bit mutex.

Thanks for the additional detail, Nicholas. So, how about a paragraph such 
as the following for the manual page:

       POSIX says that any thread in any process with access to the mem‐
       ory containing a  process-shared  (PTHREAD_PROCESS_SHARED)  mutex
       can  operate  on that mutex.  However, on 64-bit x86 systems, the
       mutex definition for x86-64 is incompatible with the mutex  defi‐
(Continue reading)

Carl Winbäck | 26 Jul 22:20 2015
Picon

Status for bug 71211? [random(4): clarify utility and volume]

Hello Michael & Co,

I would like to bring your attention to bug report 71211, ”random(4):
clarify utility and volume”.

https://bugzilla.kernel.org/show_bug.cgi?id=71211

This report was filed over a year ago but still hasn’t received any response.

Michael, do you have the time to take a look?

Perhaps you, or someone else on the linux-man list, are familiar with
CSPRNGs and have some ideas on how to reword this man page?

Unfortunately I’m not at all an expert in this area, so I’m afraid I
don’t have any specific suggestions regarding how to change this man
page. But I still think it would be helpful to the Linux community if
it could be improved, and as a result, hopefully cause less confusion
regarding getting random numbers on Linux.

Looking forward to hear your thoughts on this.

Best regards,
Carl Winbäck
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Michael Kerrisk (man-pages | 24 Jul 11:30 2015
Picon

For review: dladdr(3) man page

Hello all,

I've recently been working on improving documentation of the
dlopen API, and as part of that work, I split dladdr(3) out of 
the dlopen(3) man page, and added documentation for the formerly 
undocumented dladdr1() API. 

I would be happy to receive review comments, suggestions for
fixes or improvements, or offers of more beer in Prague next month.

Page source provided inline below. (Extract and use "man -l file"
to render.)

Cheers,

Michael

'\" t
.\" Copyright (C) 2015 Michael Kerrisk <mtk.manpages@...>
.\" and Copyright (C) 2008 Petr Baudis <pasky@...> (dladdr caveat)
.\"
.\" %%%LICENSE_START(VERBATIM)
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
(Continue reading)

Michael Kerrisk (man-pages | 24 Jul 11:11 2015
Picon

Further work on bpf(2)

Hello Alexei, Daniel

Now that we have a version of the bpf(2) man page out the door, I'd
like to see it refined, since there are a number of missing pieces.
In particular:

* The page lacks documentation of the BPF_MAP_TYPE_PROG_ARRAY 
  map type.

* The page needs more info on the BPF_PROG_TYPE_SOCKET_FILTER
  program type.

* The page lacks documentation of the BPF_PROG_TYPE_SOCKET_FILTER
  program type.

    commit 2541517c32be2531e0da59dfd7efc1ce844644f5
    Author: Alexei Starovoitov <ast@...>
    Date:   Wed Mar 25 12:49:20 2015 -0700

        tracing, perf: Implement BPF programs attached to kprobes

* The page lacks documentation of the BPF_PROG_TYPE_SCHED_CLS
  program type.

    commit 96be4325f443dbbfeb37d2a157675ac0736531a1
    Author: Daniel Borkmann <daniel@...>
    Date:   Sun Mar 1 12:31:46 2015 +0100

        ebpf: add sched_cls_type and map it to sk_filter's verifier ops

(Continue reading)


Gmane