Describe use of tm_isdst for input to mktime();
explain how mktime() modifies this field.
(This field is left unchanged in case of error.)
Reported-by: Eugene V. Lyubimkin <jackyf.devel@gmail.com>
Debian bug 500178
Summary from mtk: recent work on mlock caused Maxin to notice that
the EAGAIN error was not documented. KOSAKI Motohiro noted
that this behavior is longstanding.
=====
Dear Michael,
As per the mlock(2) implementation bugfix which is present in
Linux 2.6.27-rc2 git commit,
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a477097d9c37c1cf289c7f0257dffcfa42d50197),
the mlock(2) man page should be modified to reflect the latest changes
in the kernel.
See the LKML thread regarding this commit :
http://www.nabble.com/mlock()-return-value-issue-in-kernel-2.6.23.17-td18751601.html
This patch modifies the mlock(2) behaviour as per the SUSv3 specification.
[ENOMEM]
Some or all of the address range specified by the addr and
len arguments does not correspond to valid mapped pages
in the address space of the process.
[EAGAIN]
Some or all of the memory identified by the operation could not
be locked when the call was made.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Maxin B. John <maxin.john@ap.sony.com>
=====
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: "Maxin John" <maxin.john@gmail.com>
Subject: Re: mlock(2) man page modifications
Cc: kosaki.motohiro@jp.fujitsu.com,
"Michael Kerrisk" <mtk.manpages@googlemail.com>, man@vger.kernel.org
Date: Thu, 25 Sep 2008 15:04:49 +0900 (JST)
Hi Maxin,
Thank you for your attention.
I think your point and your patch are right.
However, my patch is trivial regression fix, not behavior change.
An older kernel can return EAGAIN at memory stavation.
my patch has following hunk.
> +++ b/mm/mlock.c
> @@ -78,8 +78,6 @@ success:
>
> mm->locked_vm -= pages;
> out:
> - if (ret == -ENOMEM)
> - ret = -EAGAIN;
In addition, 2.6.11 (oldest code of git repository) has following code.
static int mlock_fixup(struct vm_area_struct * vma,
unsigned long start, unsigned long end, unsigned int newflags)
{
(snip)
vma->vm_mm->locked_vm -= pages;
out:
if (ret == -ENOMEM)
ret = -EAGAIN;
return ret;
}
that behavior is linux mlock's behavior for long long time.
Thanks!
When we use 'strncpy(buf, str, n)', strncpy() will fill chars from 0..(n - 1).
As we force the character at position 'n - 1' to be '\0' anyway, don't fill
it in strncpy() before.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove crufty text about use of comma instead of slash to separate
port and protocol. It's not true as at glibc 2.8, and it's not
clear if/when it was ever true.
At the end of the paragraph in opendir(3) describing fdopendir(), I
think it's worth adding "The file descriptor will be closed when
closedir() is called." It's a bit ambiguous if the file descriptor
is closed or "given back" at closedir time.
(I've tested this and verified that it's true, BTW.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As there are many users who base their own code on these examples,
we should avoid leaking memory when using functions of tsearch() family.
In the provided example, tsearch() leaks memory whenever it tries to
insert a number which was already inserted before.
Also: include use of tdestroy() in example program.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The error by getpid() in the presence of clone() occurs
only for a fork-like clone (one that omits CLONE_VM from the flags.)
This is a low-level detail, but there is no problem [known-to-me]
for thread-like clone().
The page formerly used both 'dir' and 'dirp'(!).
POSIX.1-2008 and glibc call this argument 'dirp' (consistent
with the fact that it is a *pointer* to a DIR structure).
getpid() caches the PID after the first call. This relies
on support in the glibc wrappers for fork()/vfork()/clone().
However, if syscall() is used to directly invoke fork()/vfork()/clone(),
the cache is not updated, and getpid() in the child procudes the wrong
result.
Michael Kerrisk