I obtained the information in this man page as a consequence
of having worked on the cciss driver for the past several years,
and having written considerable portions of it.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document the MADV_HUGEPAGE and MADV_NOHUGEPAGE flags added to
madvise() in Linux 2.6.38.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux 2.6.39, unprivileged processes under the
SCHED_IDLE policy can switch to another nonrealtime
policy if their nice value falls within the range
permitted by their RLIMIT_NICE limit.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These flags, designed for discovering holes in a file,
were added in Linux 3.1. Included comments from Eric
Blake and Sunil Mushran.
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Sunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Alan Curry:
According to man2/lseek.2,
This document's use of whence is incorrect English, but
maintained for historical reasons.
What is the grammatical objection?
From WordNet (r) 3.0 (2006) [wn]:
whence
adv 1: from what place, source, or cause
Wiktionary:
[edit] Adverb
whence (not comparable)
1. From where; from which place or source.
lseek's second parameter is a distance to be traveled, and
the third parameter chooses the starting point from which
that distance is measured. How is that not a "whence"?
Looking at some man page archives, I found that the accusation
of incorrect English goes back to before 4.4BSD. It survives
not just in the linux-man-pages but also in recent versions
of {Net,Open,Free}BSD. The name "whence" for this parameter
goes back at least to V7.
Of all the people who have read this page over the years,
am I the only one wondering... what's this about? Who decided
that "whence" was incorrect and put that note in the man page?
Was there ever anything wrong, or do we have someone's
20-year-old unresearched pet peeve lingering in the man pages?
Reported-by: Alan Curry <pacman@kosh.dhis.org>
Reported-by: Reuben Thomas <rrt@sc3d.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Now that the underlying system call rt_sigqueueinfo(2) is
properly documented, move sigqueue() to Section 3, since
it is really a library function.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This replaces the previous '.so' man page link file for
rt_sigqueueinfo.2, which linked to ths sigqueue() man page.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
We've recently discovered that GDB will fail to attach to any
process that sets itself non-dumpable. Tested on kernel 2.6.32,
with:
int main(int argc, char *argv[])
{
if (prctl(PR_SET_DUMPABLE, 0, 0, 0) != 0) {
perror("prctl");
}
printf("Run gdb %s %d\n", argv[0], getpid());
sleep(20);
abort();
}
./a.out
Run gdb ./a.out 30476
gdb -q ./a.out 30476
Reading symbols from /tmp/a.out...done.
Attaching to program: /tmp/a.out, process 30476
ptrace: Operation not permitted.
/tmp/30476: No such file or directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>