SPECTRE_V2_GCC_MITIGATION, but SPECTRE_V2_GCC_MITIGATION being empty is
not a good enough check as it can't be overwritte on the make
command line. Now I can do: "make SPECTRE_V2_GCC_MITIGATION=0" (e.g. when
my gcc is too old for having the indirect-branch options).
The recently exposed device.h internals to _KMEMUSER also require
exposing details about pmf.
The current build works without this as the only user is crash(8)
which partially uses kernel sources and is compiled with the
additional kernel include path.
net.inet6.esp6
net.inet6.ipcomp6
net.inet6.ah6
subtrees. They are aliases to net.inet6.ipsec6, but they are not
consistent with the original intended naming. (eg there was
net.inet6.esp6.esp_trans_deflev instead of net.inet6.esp6.trans_deflev).
net.inet.esp.trans_deflev = net.inet.ipsec.esp_trans_deflev
net.inet.esp.net_deflev = net.inet.ipsec.esp_net_deflev
net.inet.ah.cleartos = net.inet.ipsec.ah_cleartos
net.inet.ah.offsetmask = net.inet.ipsec.ah_offsetmask
net.inet.ah.trans_deflev = net.inet.ipsec.ah_trans_deflev
net.inet.ah.net_deflev = net.inet.ipsec.ah_net_deflev
Use the convention on the right. Discussed a month ago on tech-net@.
The change fixes race conditions on list operations. One example is that a
reader may see invalid pointers on a looking item in a list due to lack of
membar_producer.
From: ppalka <ppalka@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Wed, 27 Apr 2016 21:18:05 +0000
Subject: [PATCH] Reduce nesting of parentheses in conditionals generated by
genattrtab
gcc/ChangeLog:
* genattrtab.c (write_test_expr): New parameter EMIT_PARENS
which defaults to true. Emit an outer pair of parentheses only if
EMIT_PARENS. When continuing a chain of && or || (or & or |),
don't emit parentheses for the right-hand operand.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@235536
gcc/arm generates so many parens it hits a bracket depth limited which is
enforced by clang. This reduces the number of parens generated and avoids the
need to increase bracket depth.
Fixes PR toolchain/53178 properly.
m_adj(m1, -(m1->m_len - roff));
if (m1 != m)
m->m_pkthdr.len -= (m1->m_len - roff);
This is wrong: m_adj will modify m1->m_len, so we're using a wrong value
when manually adjusting m->m_pkthdr.len.
Because of that, it is possible to exploit the attack I described in
uipc_mbuf.c::rev1.182. The exploit is more complicated, but works 100%
reliably.
should, but it looks like there are several places that can put M_PKTHDR
on secondary mbufs (PR/53189), so drop this assumption right now to
prevent further bugs.
The check is replaced by (m1 != m), which is equivalent to the previous
code: we want to modify m->m_pkthdr.len only when 'm' was not passed in
m_adj().
