headers
Christopher Yeoh | 2 Apr 2012 04:03
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)

Permalink | Reply | 1 comment |
headers
Jak | 3 Apr 2012 20:37
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
Permalink | Reply | 1 comment |
headers
Andrew Morton | 5 Apr 2012 02:10

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
Permalink | Reply | 2 comments |
headers
Dmitry Antipov | 6 Apr 2012 11:02
Favicon

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)

Permalink | Reply | 1 comment |
headers
Dmitry Antipov | 6 Apr 2012 11:14
Favicon

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)

Permalink | Reply | 1 comment |
headers
Andrew Morton | 6 Apr 2012 21:55

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)

Permalink | Reply | 9 comments |
headers
bugzilla | 7 Apr 2012 00:39

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

Permalink | Reply | 1 comment |
headers
Armin Rigo | 7 Apr 2012 18:40
Favicon

Typo in pthread_testcancel(3)

Hi,

The man page of pthread_testcancel(3) contains a typo: when it
mentions pthread_cancel(3) in the DESCRIPTION, it should really
mention pthread_testcancel() instead.

Thanks!

Armin Rigo
--
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
Permalink | Reply | 1 comment |
headers
bugzilla | 8 Apr 2012 13:49

[Bug 43072] New: epoll & threads

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

           Summary: epoll & threads
           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: arigo@...
        Regression: No

The manpages of epoll do not mention the behavior in the presence of multiple
threads.  By trying it out, I found out that the following works: if one thread
does epoll_wait() on an epoll in which some fd was not registered at all, and
blocks; and later another thread does epoll_ctl() to add the fd; then the fd
will be reported by the original thread's epoll_wait() as soon as it meets the
condition.  This behavior is something that may be very useful in some
situations.  As far as I see, it cannot be achieved easily with select().  I
think that it should be officially mentioned in the manpages (provided it is
not an accident but works this way by design).

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Kruppa | 11 Apr 2012 18:21
Picon

Minor error in aio_read(3)

In aio_read(3), the sentence

"The return status of a completed I/O operation can be obtained aio_return(3)."

is missing a preposition, e.g.,

"can be obtained by aio_return(3)."

Best regards,

A. Kruppa
--
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
Permalink | Reply | 1 comment |

Gmane