This was fixed in glibc 2.1.1, which is a long while ago.
And in any case, there is nothing special about this case;
it's just one of those times when glibc lags.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text makes no sense. The check is based
purely on a capability check. (Kernel function
net/packet/af_packet.c::packet_create()
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Actually a dummy commit to mark the fact that I mashed commit
e8db1b97eb to have the wrong
author. Come release time, I'll at least fix the Changelog
to note that the author was Scot Doyle.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's important that the reader receive contemporary information.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
While a lot of the changes are issues of presentation,
there are also issues of grammar and punctuation.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Per IEEE-754 rounding rules.
The round(3) page describes the behavior of rint and nearbyint
in the halfway cases by saying:
These functions round x to the nearest integer, but round
halfway cases away from zero [...], instead of to the
nearest even integer like rint(3)
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote:
> Jann Horn writes:
> > Or should I throw this patch away and write a patch
> > for the prctl() manpage instead that documents that
> > being able to call sigreturn() implies being able to
> > effectively call sigprocmask(), at least on some
> > architectures like X86?
>
> Well, that is the semantics of sigreturn(). It is essentially
> setcontext() [which includes the actions of sigprocmask()], but
> with restrictions on parameter placement (at least on x86).
>
> You could introduce some setting to restrict that aspect for
> seccomp processes, but you can't change this for normal processes
> without breaking things.
Then I think it's probably better and easier to just document the
existing behavior? If a new setting would have to be introduced
and developers would need to be aware of that, it's probably
easier to just tell everyone to use SIGKILL.
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Mikael Pettersson <mikpelinux@gmail.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix a warning of groff: line 527: warning [p 6, 2.3i]: cannot adjust line
Signed-off-by: Stéphane Aulery <saulery@free.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix a warning of groff: line 192: warning [p 2, 4.7i]: cannot adjust line
Signed-off-by: Stéphane Aulery <saulery@free.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking over the man page for 'tcp' I came across a reference to
tuning the 'TCP_SYNQ_HSIZE' parameter when increasing
'tcp_max_syn_backlog' above 1024. However, this static sizing was
removed back in Linux 2.6.20 in favor of dynamic scaling - as
part of commit 72a3effaf633bcae9034b7e176bdbd78d64a71db.
I have included a patch below with reference to this commit, and
that the process detailed is not required on >= Linux 2.6.20.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The description mentions close(2). Hence it should also be referenced
in the SEE ALSO section.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk