headers
Guillem Jover | 1 Jan 2012 03:49

Re: [PATCH] fsync.2 updates

Hi!

On 2011-11-04 6:12:04, Christoph Hellwig wrote:
> - fsync works on any fd and does not require a writeable one,
>   correct the EBADF error code explanation.

The problem is, while this is true for Linux, that's not a safe portable
assumption to make on POSIX in general as that behaviour is not
specified and as such is implementation specific, some Unix systems
do actually fail on read-only file descriptors, for example:

  <http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50_HTML/MAN/MAN2/0033____.HTM>
  <http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/fsync.htm>

So if this part of the patch gets applied it would be nice to add a
note stating this is Linux specific behaviour, and that other systems
might still fail on such condition.

regards,
guillem
--
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
Guillem Jover | 1 Jan 2012 07:40

[PATCH] proc.5: Document /proc/PID/exe behaviour on unlinked pathnames

Signed-off-by: Guillem Jover <guillem@...>
---
 man5/proc.5 |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/man5/proc.5 b/man5/proc.5
index 5aca38a..8aa8798 100644
--- a/man5/proc.5
+++ b/man5/proc.5
 <at>  <at>  -58,7 +58,7  <at>  <at> 
 .\" to see what information could be imported from that file
 .\" into this file.
 .\"
-.TH PROC 5 2011-10-04 "Linux" "Linux Programmer's Manual"
+.TH PROC 5 2011-12-29 "Linux" "Linux Programmer's Manual"
 .SH NAME
 proc \- process information pseudo-file system
 .SH DESCRIPTION
 <at>  <at>  -174,6 +174,8  <at>  <at>  You can even type
 .I /proc/[pid]/exe
 to run another copy of the same executable as is being run by
 process [pid].
+If the pathname has been unlinked, the symbolic link will contain the
+string \(aq (deleted)\(aq appended to the original pathname.
 .\" The following was still true as at kernel 2.6.13
 In a multithreaded process, the contents of this symbolic link
 are not available if the main thread has already terminated
--

-- 
1.7.7.3
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark R Bannister | 3 Jan 2012 13:11
Picon

Re: [patch] qsort.3: document qsort_r

Ben <software@...> wrote on 2011-12-29 20:50:25 GMT:
> Following a discussion on comp.lang.c, I noticed that glibc's qsort_r is
> not documented in the man pages.

Hi Ben,

I addressed this omission in a patch dated 24th October:
http://article.gmane.org/gmane.linux.man/2397

Best regards,
Mark.

--
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 | 3 comments |
headers
Mike Frysinger | 15 Jan 2012 01:43
Picon
Favicon
Gravatar

[PATCH] sigprocmask(2): add EFAULT as a possible errno value

This func takes pointers, and invalid ones will result in EFAULT.

Signed-off-by: Mike Frysinger <vapier@...>
---
 man2/sigprocmask.2 |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/man2/sigprocmask.2 b/man2/sigprocmask.2
index bd4065d..14222b6 100644
--- a/man2/sigprocmask.2
+++ b/man2/sigprocmask.2
 <at>  <at>  -92,6 +92,14  <at>  <at>  is unspecified in a multithreaded process; see
 .BR sigprocmask ()
 returns 0 on success and \-1 on error.
 .SH ERRORS
+.TP
+.B EFAULT
+The specified
+.I set
+or
+.I oldset
+pointed outside the process's allocated address space.
+.TP
 .B EINVAL
 The value specified in
 .I how
--

-- 
1.7.8.3

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Siddhesh Poyarekar | 17 Jan 2012 05:54
Picon
Gravatar

[PATCH] Mark thread stack correctly in proc/<pid>/maps

[Take 2]

Memory mmaped by glibc for a thread stack currently shows up as a simple
anonymous map, which makes it difficult to differentiate between memory
usage of the thread on stack and other dynamic allocation. Since glibc
already uses MAP_STACK to request this mapping, the attached patch
uses this flag to add additional VM_STACK_FLAGS to the resulting vma
so that the mapping is treated as a stack and not any regular
anonymous mapping. Also, one may use vm_flags to decide if a vma is a
stack.

This patch also changes the maps output to annotate stack guards for
both the process stack as well as the thread stacks. Thus is born the
[stack guard] annotation, which should be exactly a page long for the
process stack and can be longer than a page (configurable in
userspace) for POSIX compliant thread stacks. A thread stack guard is
simply page(s) with PROT_NONE.

If accepted, this should also reflect in the man page for mmap since
MAP_STACK will no longer be a noop.

Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@...>
---
 fs/proc/task_mmu.c |   41 ++++++++++++++++++++++++++++++++++++-----
 include/linux/mm.h |   19 +++++++++++++++++--
 mm/mmap.c          |    3 +++
 3 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index e418c5a..650330c 100644
(Continue reading)

Permalink | Reply | 33 comments |
headers
starlight | 19 Jan 2012 04:16
Favicon

suggestion for improvement to vfork() man page

Also I don't think it is unfortunate (or a bug)
that vfork() continues to exist in Linux aside
from the fact that the semantics differ from
other *nixes in subtle and potentially
confusing ways.

As implemented in Linux vfork() is quite useful
and with the aforementioned clarifications to
the documentation, worth retaining.

--
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 | 5 comments |
headers
starlight | 19 Jan 2012 04:04
Favicon

suggestion for improvement to vfork() man page

Hello,

Please consider the following two suggestions for
adjusting the vfork() man page.

In the "Linux Description" section it should be
mentioned that vfork() does not suspend all the
threads in the parent process and only suspends
the thread issuing the call to vfork().  The
wording is misleading and I misunderstood the
semantics for a long time, thinking that all
threads would be suspended.  Had to test it to
determine the actual effect for certain.  In our
case suspending all threads for even a few
microseconds is unacceptable.

Also, it is important to note that the
clone(CLONE_VFORK|CLONE_VM) call invoked by
vfork() makes a separate copy of all process
resources except the address space.  While this is
implied by the statement "the vfork() function has
the same effect as fork(2)," this is easily
overlooked by someone who works with various UNIXs
where this is most definitely not the case.

This matters for situations like ours where a
process with a huge address space, real-time
priority and root privileges must occasionally
spawn scripts that should run at user priority
with user privileges.  Using fork() is expensive
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Frysinger | 19 Jan 2012 19:36
Picon
Favicon
Gravatar

Re: suggestion for improvement to vfork() man page

On Wednesday 18 January 2012 22:16:28 starlight@... wrote:
> Also I don't think it is unfortunate (or a bug)
> that vfork() continues to exist in Linux aside
> from the fact that the semantics differ from
> other *nixes in subtle and potentially
> confusing ways.
> 
> As implemented in Linux vfork() is quite useful
> and with the aforementioned clarifications to
> the documentation, worth retaining.

it also most likely won't ever be going away.  a few reasons:
	- vfork() is really just a clone() with certain flags
	- clone() is never going away as it is used to create threads
	- vfork() is required for no-mmu systems (can't implement fork())
-mike
Permalink | Reply | 1 comment |
headers
Andreas Heiduk | 21 Jan 2012 11:28

Missing ioctl descriptions: TIOCMIWAIT, TIOCGICOUNT

Hello,

my Ubuntu 10.04 (lucid) distribution uses manpages-3.23-1. But neither
there nor in the browsable manpages here

http://www.kernel.org/doc/man-pages/online/pages/man4/tty_ioctl.4.html
http://www.kernel.org/doc/man-pages/online/pages/man2/ioctl_list.2.html

there is a description for the ioctls TIOCMIWAIT and TIOCGICOUNT

Could you please add them to the pages ioctl_list and tty_ioctl ?

Best regards,
Andreas Heiduk
--
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
Jon Grant | 21 Jan 2012 22:40

errno(3) link on pages which set errno

Hello

Could pages like aio_read and others which may set errno, have a link in 
the SEE ALSO section to errno(3) please.  There are quite a lot of pages 
that could have this SEE ALSO link.

Regards, Jon
--
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