Christopher Yeoh | 2 Apr 04:03 2012
Picon

Re: [PATCH] process_vm_{read,write}v(3): initial man pages

On Fri, 30 Mar 2012 07:42:49 +1300
"Michael Kerrisk (man-pages)" <mtk.manpages@...> wrote:

> On Thu, Mar 22, 2012 at 7:29 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@...> wrote:
> > On Thu, Mar 22, 2012 at 4:43 AM, Mike Frysinger <vapier@...>
> > wrote:
> >> Michael: should i fold in the updates that came from this thread
> >> and send a v2, or are you going to tackle it ?
> >
> > I'll work on a draft, and have it out for review in a few days.
> 
> Mike, Chris,
> 
> Here's a heavily edited version of the page that Mike sent in. Since I
> might have messed something up, could I ask you two to take a good
> look at this page?
> 

....

> 
> The
> .BR process_vm_readv ()
> system call transfers data from the process
> .I pid
> to the calling process.
> The data to be transferred is identified by
> .IR remote_vec

(Continue reading)

Jak | 3 Apr 20:37 2012
Picon

Changed type of ai_addrlen in struct addrinfo

Hi,

<http://man7.org/linux/man-pages/man3/getaddrinfo.3.html> says that 
struct addrinfo contains:

         size_t    ai_addrlen;

However, in the GNU C Library, the type was changed on 2000-04-01 from 
size_t to socklen_t, as ChangeLog.11 in the glibc source shows:

         * resolv/netdb.h
         [...]
         (struct addrinfo): Use socklen_t for ai_addrlen element.

Please could the manpage be updated?

Thanks,
Jak.
--
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

Andrew Morton | 5 Apr 02:10 2012

Re: [RFC PATCH] hrtimers: system-wide and per-task hrtimer slacks

On Mon, 20 Feb 2012 11:49:32 +0400
Dmitry Antipov <dmitry.antipov@...> wrote:

> This patch proposes a system-wide sysctl-aware default for the
> high-resolution timer slack value, which may be changed from 0
> to HRTIMER_MAX_SLACK nanoseconds. Default system-wide and per-task
> values are HRTIMER_DEFAULT_SLACK. Per-task value isn't inherited
> across fork(); instead, newborn task uses system-wide value by
> default, and newborn thread uses it's group leader value.

Well..  there are some back-incompatibilities here. 
prctl(PR_SET_TIMERSLACK, -1) used to restore current's slack setting to
whatever-we-inherited-at-fork, but that has been removed.  What are the
implications of this, and did we need to do it?

If we do make changes in this area then the prctl manpage should be
updated, please.  And if
http://www.spinics.net/lists/linux-man/msg01149.html represents the
current state of that manpage then it should be updated anyway - that
entry doesn't say anything about the (arg2 <= 0) case.

--
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

Dmitry Antipov | 6 Apr 11:02 2012

http://lwn.net/Articles/484162

Document PR_GET_TIMERSLACK and PR_SET_TIMERSLACK for prctl (2).
Document /proc/sys/kernel/timer_slack for proc (5).

Signed-off-by: Dmitry Antipov <dmitry.antipov@...>
---
 man2/prctl.2 |   15 +++++++++++++++
 man5/proc.5  |    4 ++++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/man2/prctl.2 b/man2/prctl.2
index effad2a..dcf803f 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
 <at>  <at>  -378,6 +378,21  <at>  <at>  Return the current per-process machine check kill policy.
 All unused
 .BR prctl ()
 arguments must be zero.
+.TP
+.BR PR_GET_TIMERSLACK " (since Linux 2.6.28)"
+Return the current per-thread high-resolution timers slack, in nanoseconds.
+.TP
+.BR PR_SET_TIMERSLACK " (since Linux 2.6.28)"
+Set the current per-thread high-resolution timers slack. If arg2 is less than or
+equal to zero, system-wide default value is restored. The system-wide default can
+be read and set by /proc/sys/kernel/timer_slack (see
+.BR proc (5)).
+Otherwise, if arg2 is less than or equal to HRTIMER_MAX_SLACK (which is a kernel
+constant defined in include/linux/hrtimer.h), this value is set up as a new slack.
+Slack is not inherited across
+.BR fork (2);
(Continue reading)

Dmitry Antipov | 6 Apr 11:14 2012

Re: [RFC PATCH] hrtimers: system-wide and per-task hrtimer slacks

On 04/05/2012 04:10 AM, Andrew Morton wrote:

> Well..  there are some back-incompatibilities here.
> prctl(PR_SET_TIMERSLACK, -1) used to restore current's slack setting to
> whatever-we-inherited-at-fork, but that has been removed.  What are the
> implications of this, and did we need to do it?

It seems you're looking at the previous version of this patch
(http://lkml.org/lkml/2012/2/20/55). Latest proposal is
http://lwn.net/Articles/484162/, which defines PR_SET_TIMERSLACK
action as:
...
case PR_SET_TIMERSLACK:
         if (arg2 <= 0)
                 current->timer_slack_ns =
                         default_timer_slack_ns;
         else if (arg2 <= HRTIMER_MAX_SLACK)
                 current->timer_slack_ns = arg2;
         else
                 error = -EINVAL;
         break;
...

> If we do make changes in this area then the prctl manpage should be
> updated, please.  And if
> http://www.spinics.net/lists/linux-man/msg01149.html represents the
> current state of that manpage then it should be updated anyway - that
> entry doesn't say anything about the (arg2<= 0) case.

I sent a patch for man pages too, it should be one of the recent posts
(Continue reading)

Andrew Morton | 6 Apr 21:55 2012

Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

On Thu, 29 Mar 2012 15:01:46 -0500
Will Drewry <wad@...> wrote:

> From: Andy Lutomirski <luto@...>
> 
> With this set, a lot of dangerous operations (chroot, unshare, etc)
> become a lot less dangerous because there is no possibility of
> subverting privileged binaries.

The changelog doesn't explain the semantics of the new syscall. 
There's a comment way-down-there which I guess suffices, if you hunt
for it.

And the changelog doesn't explain why this is being added.  Presumably
seccomp_filter wants/needs this feature but whowhatwherewhenwhy?  Spell
it all out, please.

The new syscall mode will be documented in the prctl manpage.  Please
cc linux-man@... and work with Michael on getting this
done?

>
> ...
>
--
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)

Andrew Lutomirski | 6 Apr 22:01 2012
Picon

Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

On Fri, Apr 6, 2012 at 12:55 PM, Andrew Morton
<akpm <at> linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:46 -0500
> Will Drewry <wad <at> chromium.org> wrote:
>
>> From: Andy Lutomirski <luto <at> amacapital.net>
>>
>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>> become a lot less dangerous because there is no possibility of
>> subverting privileged binaries.
>
> The changelog doesn't explain the semantics of the new syscall.
> There's a comment way-down-there which I guess suffices, if you hunt
> for it.
>
> And the changelog doesn't explain why this is being added.  Presumably
> seccomp_filter wants/needs this feature but whowhatwherewhenwhy?  Spell
> it all out, please.
>
> The new syscall mode will be documented in the prctl manpage.  Please
> cc linux-man <at> vger.kernel.org and work with Michael on getting this
> done?

This has been bugging me for awhile.  Is there any interest in moving
the manpages into the kernel source tree?  Then there could be a
general requirement that new APIs get documented when they're written.

(There are plenty of barely- or incompletely-documented syscalls.
futex and relatives come to mind.)

(Continue reading)

Jonathan Corbet | 6 Apr 22:28 2012
Picon

Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

On Fri, 6 Apr 2012 13:01:17 -0700
Andrew Lutomirski <luto <at> mit.edu> wrote:

> This has been bugging me for awhile.  Is there any interest in moving
> the manpages into the kernel source tree?  Then there could be a
> general requirement that new APIs get documented when they're written.

Man page (or other documentation) requirements for patch acceptance are a
regular kernel summit feature.  People seem to think it's a good idea, but
actual enforcement of such requirements always seems to be lacking.  Lots
of people have kind of given up trying.  I don't really see that adding
the man pages to the tree would help, but I could be wrong...

jon
Andrew Lutomirski | 6 Apr 22:37 2012
Picon

Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

On Fri, Apr 6, 2012 at 1:28 PM, Jonathan Corbet <corbet <at> lwn.net> wrote:
> On Fri, 6 Apr 2012 13:01:17 -0700
> Andrew Lutomirski <luto <at> mit.edu> wrote:
>
>> This has been bugging me for awhile.  Is there any interest in moving
>> the manpages into the kernel source tree?  Then there could be a
>> general requirement that new APIs get documented when they're written.
>
> Man page (or other documentation) requirements for patch acceptance are a
> regular kernel summit feature.  People seem to think it's a good idea, but
> actual enforcement of such requirements always seems to be lacking.  Lots
> of people have kind of given up trying.  I don't really see that adding
> the man pages to the tree would help, but I could be wrong...
>

If it's in the source, then I can send it with git format-patch.  If
it's out of tree, I have to find the tree, clone the tree, figure out
how to submit, and send separate emails.  And then whoever checks that
I documented it has to figure out where I sent it and how to read it
and then try to decide which documentation submission matches which
patch submission.

(Also, if it's in-tree, then I can build the docs from a kernel tree
and have the latest ones.  That could be nice.)

--Andy
bugzilla | 7 Apr 00:39 2012

[Bug 43061] New: resolver.3 man page: RES_DEBUG option has effect only if libresolv compiled with DEBUG defined

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

               URL: http://man7.org/linux/man-pages/man3/resolver.3.html
           Summary: resolver.3 man page: RES_DEBUG option has effect only
                    if libresolv compiled with DEBUG defined
           Product: Documentation
           Version: unspecified
    Kernel Version: n/a
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
        AssignedTo: documentation_man-pages@...
        ReportedBy: kernelbugs@...
        Regression: No

The resolver.3 man page's description of the available _res.options flag says:

RES_DEBUG
              Print debugging messages.

However, from looking at the libresolv source, I get the impression that if the
library was not compiled with "DEBUG" defined then the RES_DEBUG option is
silently ignored.  

Since it appears to be fairly common for the library to be compiled without
DEBUG, it seems worth adding a note to the man page mentioning that RES_DEBUG
(Continue reading)


Gmane