| Age | Commit message (Collapse) | Author |
|---|
|
It's bad to use these macros when not dealing with error code. this
patch changes calls to these macros with correct casts.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
SE discovery errors are currently overwriting the dev_up() return error.
This is wrong for many reasons:
- We don't want to report an error if we actually brought the device up
but it failed to discover SEs. By doing so we pretend we don't have an
NFC functional device even we do. The only thing we could not do was
checking for SEs availability. This is the false negative case.
- In some cases the actual device power up failed but the SE discovery
succeeded. Userspace then believes the device is up while it's not.
This is the false positive case.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
If MIUX is not present in CONNECT or CC use default MIU value (128)
instead of one announced durring link setup.
This was affecting Bluetooth handover with Android 4.3+ NCI stack.
Signed-off-by: Szymon Janc <szymon.janc@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
If sending was not completed due to low memory condition msg_data
was not free before returning from function.
Signed-off-by: Szymon Janc <szymon.janc@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
If the device is polling, this will trigger a netlink event to notify
userspace about the polling error.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
With commit e29a9e2ae165620d, we set the active_target pointer from
nfc_dep_link_is_up() in order to support the case where the target
detection and the DEP link setting are done atomically by the driver.
That can only happen in initiator mode, so we need to check for that
otherwise we fail to bring a p2p link in target mode.
Signed-off-by: Arron Wang <arron.wang@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
The llc_sap_list_lock does not need to be global, only acquired
in core.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Namespace related cleaning
* make cred_to_ucred static
* remove unused sock_rmalloc function
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
percpu route cache eliminates share of dst refcnt between CPUs.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Avoid doing a route lookup on every packet being tunneled.
In ip_tunnel.c cache the route returned from ip_route_output if
the tunnel is "connected" so that all the rouitng parameters are
taken from tunnel parms for a packet. Specifically, not NBMA tunnel
and tos is from tunnel parms (not inner packet).
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Recently I updated the sctp socket option deprecation warnings to be both a bit
more clear and ratelimited to prevent user processes from spamming the log file.
Ben Hutchings suggested that I add the process name and pid to these warnings so
that users can tell who is responsible for using the deprecated apis. This
patch accomplishes that.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch allows you to dump all sets available in all of
the registered families. This allows you to use NFPROTO_UNSPEC
to dump all existing sets, similarly to other existing table,
chain and rule operations.
This patch is based on original patch from Arturo Borrero
González.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
NFSv4 clients can contact port 2049 directly instead of needing the
portmapper.
Therefore a failure to register to the portmapper when starting an
NFSv4-only server isn't really a problem.
But Gareth Williams reports that an attempt to start an NFSv4-only
server without starting portmap fails:
#rpc.nfsd -N 2 -N 3
rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused)
rpc.nfsd: unable to set any sockets for nfsd
Add a flag to svc_version to tell the rpc layer it can safely ignore an
rpcbind failure in the NFSv4-only case.
Reported-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
|
|
It would be useful e.g. in a server or desktop environment to have
a facility in the notion of fine-grained "per application" or "per
application group" firewall policies. Probably, users in the mobile,
embedded area (e.g. Android based) with different security policy
requirements for application groups could have great benefit from
that as well. For example, with a little bit of configuration effort,
an admin could whitelist well-known applications, and thus block
otherwise unwanted "hard-to-track" applications like [1] from a
user's machine. Blocking is just one example, but it is not limited
to that, meaning we can have much different scenarios/policies that
netfilter allows us than just blocking, e.g. fine grained settings
where applications are allowed to connect/send traffic to, application
traffic marking/conntracking, application-specific packet mangling,
and so on.
Implementation of PID-based matching would not be appropriate
as they frequently change, and child tracking would make that
even more complex and ugly. Cgroups would be a perfect candidate
for accomplishing that as they associate a set of tasks with a
set of parameters for one or more subsystems, in our case the
netfilter subsystem, which, of course, can be combined with other
cgroup subsystems into something more complex if needed.
As mentioned, to overcome this constraint, such processes could
be placed into one or multiple cgroups where different fine-grained
rules can be defined depending on the application scenario, while
e.g. everything else that is not part of that could be dropped (or
vice versa), thus making life harder for unwanted processes to
communicate to the outside world. So, we make use of cgroups here
to track jobs and limit their resources in terms of iptables
policies; in other words, limiting, tracking, etc what they are
allowed to communicate.
In our case we're working on outgoing traffic based on which local
socket that originated from. Also, one doesn't even need to have
an a-prio knowledge of the application internals regarding their
particular use of ports or protocols. Matching is *extremly*
lightweight as we just test for the sk_classid marker of sockets,
originating from net_cls. net_cls and netfilter do not contradict
each other; in fact, each construct can live as standalone or they
can be used in combination with each other, which is perfectly fine,
plus it serves Tejun's requirement to not introduce a new cgroups
subsystem. Through this, we result in a very minimal and efficient
module, and don't add anything except netfilter code.
One possible, minimal usage example (many other iptables options
can be applied obviously):
1) Configuring cgroups if not already done, e.g.:
mkdir /sys/fs/cgroup/net_cls
mount -t cgroup -o net_cls net_cls /sys/fs/cgroup/net_cls
mkdir /sys/fs/cgroup/net_cls/0
echo 1 > /sys/fs/cgroup/net_cls/0/net_cls.classid
(resp. a real flow handle id for tc)
2) Configuring netfilter (iptables-nftables), e.g.:
iptables -A OUTPUT -m cgroup ! --cgroup 1 -j DROP
3) Running applications, e.g.:
ping 208.67.222.222 <pid:1799>
echo 1799 > /sys/fs/cgroup/net_cls/0/tasks
64 bytes from 208.67.222.222: icmp_seq=44 ttl=49 time=11.9 ms
[...]
ping 208.67.220.220 <pid:1804>
ping: sendmsg: Operation not permitted
[...]
echo 1804 > /sys/fs/cgroup/net_cls/0/tasks
64 bytes from 208.67.220.220: icmp_seq=89 ttl=56 time=19.0 ms
[...]
Of course, real-world deployments would make use of cgroups user
space toolsuite, or own custom policy daemons dynamically moving
applications from/to various cgroups.
[1] http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: cgroups@vger.kernel.org
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
While we're at it and introduced CGROUP_NET_CLASSID, lets also make
NETPRIO_CGROUP more consistent with the rest of cgroups and rename it
into CONFIG_CGROUP_NET_PRIO so that for networking, we now have
CONFIG_CGROUP_NET_{PRIO,CLASSID}. This not only makes the CONFIG
option consistent among networking cgroups, but also among cgroups
CONFIG conventions in general as the vast majority has a prefix of
CONFIG_CGROUP_<SUBSYS>.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Zefan Li <lizefan@huawei.com>
Cc: cgroups@vger.kernel.org
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Zefan Li requested [1] to perform the following cleanup/refactoring:
- Split cgroupfs classid handling into net core to better express a
possible more generic use.
- Disable module support for cgroupfs bits as the majority of other
cgroupfs subsystems do not have that, and seems to be not wished
from cgroup side. Zefan probably might want to follow-up for netprio
later on.
- By this, code can be further reduced which previously took care of
functionality built when compiled as module.
cgroupfs bits are being placed under net/core/netclassid_cgroup.c, so
that we are consistent with {netclassid,netprio}_cgroup naming that is
under net/core/ as suggested by Zefan.
No change in functionality, but only code refactoring that is being
done here.
[1] http://patchwork.ozlabs.org/patch/304825/
Suggested-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Zefan Li <lizefan@huawei.com>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: cgroups@vger.kernel.org
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
If setting event mask fails then we were returning 0 for success.
This patch updates return code to -EINVAL in case of problem.
Signed-off-by: Eric Leblond <eric@regit.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The following code is not used in current upstream code.
Some of this seems to be old hooks, other might be used by some
out of tree module (which I don't care about breaking), and
the need_ipv4_conntrack was used by old NAT code but no longer
called.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Function never used in current upstream code.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
We currently use prandom_u32() for allocation of ports in tcp bind(0)
and udp code. In case of plain SNAT we try to keep the ports as is
or increment on collision.
SNAT --random mode does use per-destination incrementing port
allocation. As a recent paper pointed out in [1] that this mode of
port allocation makes it possible to an attacker to find the randomly
allocated ports through a timing side-channel in a socket overloading
attack conducted through an off-path attacker.
So, NF_NAT_RANGE_PROTO_RANDOM actually weakens the port randomization
in regard to the attack described in this paper. As we need to keep
compatibility, add another flag called NF_NAT_RANGE_PROTO_RANDOM_FULLY
that would replace the NF_NAT_RANGE_PROTO_RANDOM hash-based port
selection algorithm with a simple prandom_u32() in order to mitigate
this attack vector. Note that the lfsr113's internal state is
periodically reseeded by the kernel through a local secure entropy
source.
More details can be found in [1], the basic idea is to send bursts
of packets to a socket to overflow its receive queue and measure
the latency to detect a possible retransmit when the port is found.
Because of increasing ports to given destination and port, further
allocations can be predicted. This information could then be used by
an attacker for e.g. for cache-poisoning, NS pinning, and degradation
of service attacks against DNS servers [1]:
The best defense against the poisoning attacks is to properly
deploy and validate DNSSEC; DNSSEC provides security not only
against off-path attacker but even against MitM attacker. We hope
that our results will help motivate administrators to adopt DNSSEC.
However, full DNSSEC deployment make take significant time, and
until that happens, we recommend short-term, non-cryptographic
defenses. We recommend to support full port randomisation,
according to practices recommended in [2], and to avoid
per-destination sequential port allocation, which we show may be
vulnerable to derandomisation attacks.
Joint work between Hannes Frederic Sowa and Daniel Borkmann.
[1] https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf
[2] http://arxiv.org/pdf/1205.5190v1.pdf
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The nfmsg variable is not used (except in sizeof operator which does
not care about its value) between the first and second time it is
assigned the value. Furthermore, nlmsg_data has no side effects, so
the assignment can be safely removed.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
In nf_tables_set_alloc_name(), we are trying to find a new, unused
name for our new set and interate through the list of present sets.
As far as I can see, we're using format string %d to parse already
present names in order to mark their presence in a bitmap, so that
we can later on find the first 0 in that map to assign the new set
name to. We should rather use a temporary variable of type int to
store the result of sscanf() to, and for making sanity checks on.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
If user run pktgen plus ipsec by using spi, show spi value
properly when cat /proc/net/pktgen/ethX
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
Introduce xfrm_state_lookup_byspi to find user specified by custom
from "pgset spi xxx". Using this scheme, any flow regardless its
saddr/daddr could be transform by SA specified with configurable
spi.
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
IPsec tunnel mode encapuslation needs to set outter ip header
with right protocol/ttl/id value with regard to skb->dst->child.
Looking up a rt in a standard way is absolutely wrong for every
packet transmission. In a simple way, construct a dst by setting
neccessary information to make tunnel mode encapuslation working.
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
User could set specific SPI value to arm pktgen flow with IPsec
transformation, instead of looking up SA by sadr/daddr. The reaseon
to do so is because current state lookup scheme is both slow and, most
important of all, in fact pktgen doesn't need to match any SA state
addresses information, all it needs is the SA transfromation shell to
do the encapuslation.
And this option also provide user an alternative to using pktgen
test existing SA without creating new ones.
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
Acquiring xfrm_state_lock in process context is expected to turn BH off,
as this lock is also used in BH context, namely xfrm state timer handler.
Otherwise it surprises LOCKDEP with below messages.
[ 81.422781] pktgen: Packet Generator for packet performance testing. Version: 2.74
[ 81.725194]
[ 81.725211] =========================================================
[ 81.725212] [ INFO: possible irq lock inversion dependency detected ]
[ 81.725215] 3.13.0-rc2+ #92 Not tainted
[ 81.725216] ---------------------------------------------------------
[ 81.725218] kpktgend_0/2780 just changed the state of lock:
[ 81.725220] (xfrm_state_lock){+.+...}, at: [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
[ 81.725231] but this lock was taken by another, SOFTIRQ-safe lock in the past:
[ 81.725232] (&(&x->lock)->rlock){+.-...}
[ 81.725232]
[ 81.725232] and interrupts could create inverse lock ordering between them.
[ 81.725232]
[ 81.725235]
[ 81.725235] other info that might help us debug this:
[ 81.725237] Possible interrupt unsafe locking scenario:
[ 81.725237]
[ 81.725238] CPU0 CPU1
[ 81.725240] ---- ----
[ 81.725241] lock(xfrm_state_lock);
[ 81.725243] local_irq_disable();
[ 81.725244] lock(&(&x->lock)->rlock);
[ 81.725246] lock(xfrm_state_lock);
[ 81.725248] <Interrupt>
[ 81.725249] lock(&(&x->lock)->rlock);
[ 81.725251]
[ 81.725251] *** DEADLOCK ***
[ 81.725251]
[ 81.725254] no locks held by kpktgend_0/2780.
[ 81.725255]
[ 81.725255] the shortest dependencies between 2nd lock and 1st lock:
[ 81.725269] -> (&(&x->lock)->rlock){+.-...} ops: 8 {
[ 81.725274] HARDIRQ-ON-W at:
[ 81.725276] [<ffffffff8109a64b>] __lock_acquire+0x65b/0x1d70
[ 81.725282] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725284] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 81.725289] [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
[ 81.725292] [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
[ 81.725300] [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
[ 81.725303] [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
[ 81.725305] [<ffffffff8105a026>] irq_exit+0x96/0xc0
[ 81.725308] [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
[ 81.725313] [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
[ 81.725316] [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
[ 81.725329] [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
[ 81.725333] [<ffffffff8102e5b0>] start_secondary+0x190/0x1f0
[ 81.725338] IN-SOFTIRQ-W at:
[ 81.725340] [<ffffffff8109a61d>] __lock_acquire+0x62d/0x1d70
[ 81.725342] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725344] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 81.725347] [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
[ 81.725349] [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
[ 81.725352] [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
[ 81.725355] [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
[ 81.725358] [<ffffffff8105a026>] irq_exit+0x96/0xc0
[ 81.725360] [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
[ 81.725363] [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
[ 81.725365] [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
[ 81.725368] [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
[ 81.725370] [<ffffffff8102e5b0>] start_secondary+0x190/0x1f0
[ 81.725373] INITIAL USE at:
[ 81.725375] [<ffffffff8109a31a>] __lock_acquire+0x32a/0x1d70
[ 81.725385] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725388] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 81.725390] [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
[ 81.725394] [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
[ 81.725398] [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
[ 81.725401] [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
[ 81.725404] [<ffffffff8105a026>] irq_exit+0x96/0xc0
[ 81.725407] [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
[ 81.725409] [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
[ 81.725412] [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
[ 81.725415] [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
[ 81.725417] [<ffffffff8102e5b0>] start_secondary+0x190/0x1f0
[ 81.725420] }
[ 81.725421] ... key at: [<ffffffff8295b9c8>] __key.46349+0x0/0x8
[ 81.725445] ... acquired at:
[ 81.725446] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725449] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 81.725452] [<ffffffff816dc057>] __xfrm_state_delete+0x37/0x140
[ 81.725454] [<ffffffff816dc18c>] xfrm_state_delete+0x2c/0x50
[ 81.725456] [<ffffffff816dc277>] xfrm_state_flush+0xc7/0x1b0
[ 81.725458] [<ffffffffa005f6cc>] pfkey_flush+0x7c/0x100 [af_key]
[ 81.725465] [<ffffffffa005efb7>] pfkey_process+0x1c7/0x1f0 [af_key]
[ 81.725468] [<ffffffffa005f139>] pfkey_sendmsg+0x159/0x260 [af_key]
[ 81.725471] [<ffffffff8162c16f>] sock_sendmsg+0xaf/0xc0
[ 81.725476] [<ffffffff8162c99c>] SYSC_sendto+0xfc/0x130
[ 81.725479] [<ffffffff8162cf3e>] SyS_sendto+0xe/0x10
[ 81.725482] [<ffffffff8177dd12>] system_call_fastpath+0x16/0x1b
[ 81.725484]
[ 81.725486] -> (xfrm_state_lock){+.+...} ops: 11 {
[ 81.725490] HARDIRQ-ON-W at:
[ 81.725493] [<ffffffff8109a64b>] __lock_acquire+0x65b/0x1d70
[ 81.725504] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725507] [<ffffffff81774e4b>] _raw_spin_lock_bh+0x3b/0x70
[ 81.725510] [<ffffffff816dc1df>] xfrm_state_flush+0x2f/0x1b0
[ 81.725513] [<ffffffffa005f6cc>] pfkey_flush+0x7c/0x100 [af_key]
[ 81.725516] [<ffffffffa005efb7>] pfkey_process+0x1c7/0x1f0 [af_key]
[ 81.725519] [<ffffffffa005f139>] pfkey_sendmsg+0x159/0x260 [af_key]
[ 81.725522] [<ffffffff8162c16f>] sock_sendmsg+0xaf/0xc0
[ 81.725525] [<ffffffff8162c99c>] SYSC_sendto+0xfc/0x130
[ 81.725527] [<ffffffff8162cf3e>] SyS_sendto+0xe/0x10
[ 81.725530] [<ffffffff8177dd12>] system_call_fastpath+0x16/0x1b
[ 81.725533] SOFTIRQ-ON-W at:
[ 81.725534] [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
[ 81.725537] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725539] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 81.725541] [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
[ 81.725544] [<ffffffffa008af03>] mod_cur_headers+0x793/0x7f0 [pktgen]
[ 81.725547] [<ffffffffa008bca2>] pktgen_thread_worker+0xd42/0x1880 [pktgen]
[ 81.725550] [<ffffffff81078f84>] kthread+0xe4/0x100
[ 81.725555] [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
[ 81.725565] INITIAL USE at:
[ 81.725567] [<ffffffff8109a31a>] __lock_acquire+0x32a/0x1d70
[ 81.725569] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725572] [<ffffffff81774e4b>] _raw_spin_lock_bh+0x3b/0x70
[ 81.725574] [<ffffffff816dc1df>] xfrm_state_flush+0x2f/0x1b0
[ 81.725576] [<ffffffffa005f6cc>] pfkey_flush+0x7c/0x100 [af_key]
[ 81.725580] [<ffffffffa005efb7>] pfkey_process+0x1c7/0x1f0 [af_key]
[ 81.725583] [<ffffffffa005f139>] pfkey_sendmsg+0x159/0x260 [af_key]
[ 81.725586] [<ffffffff8162c16f>] sock_sendmsg+0xaf/0xc0
[ 81.725589] [<ffffffff8162c99c>] SYSC_sendto+0xfc/0x130
[ 81.725594] [<ffffffff8162cf3e>] SyS_sendto+0xe/0x10
[ 81.725597] [<ffffffff8177dd12>] system_call_fastpath+0x16/0x1b
[ 81.725599] }
[ 81.725600] ... key at: [<ffffffff81cadef8>] xfrm_state_lock+0x18/0x50
[ 81.725606] ... acquired at:
[ 81.725607] [<ffffffff810995c0>] check_usage_backwards+0x110/0x150
[ 81.725609] [<ffffffff81099e96>] mark_lock+0x196/0x2f0
[ 81.725611] [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
[ 81.725614] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725616] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 81.725627] [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
[ 81.725629] [<ffffffffa008af03>] mod_cur_headers+0x793/0x7f0 [pktgen]
[ 81.725632] [<ffffffffa008bca2>] pktgen_thread_worker+0xd42/0x1880 [pktgen]
[ 81.725635] [<ffffffff81078f84>] kthread+0xe4/0x100
[ 81.725637] [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
[ 81.725640]
[ 81.725641]
[ 81.725641] stack backtrace:
[ 81.725645] CPU: 0 PID: 2780 Comm: kpktgend_0 Not tainted 3.13.0-rc2+ #92
[ 81.725647] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox 12/01/2006
[ 81.725649] ffffffff82537b80 ffff880018199988 ffffffff8176af37 0000000000000007
[ 81.725652] ffff8800181999f0 ffff8800181999d8 ffffffff81099358 ffffffff82537b80
[ 81.725655] ffffffff81a32def ffff8800181999f4 0000000000000000 ffff880002cbeaa8
[ 81.725659] Call Trace:
[ 81.725664] [<ffffffff8176af37>] dump_stack+0x46/0x58
[ 81.725667] [<ffffffff81099358>] print_irq_inversion_bug.part.42+0x1e8/0x1f0
[ 81.725670] [<ffffffff810995c0>] check_usage_backwards+0x110/0x150
[ 81.725672] [<ffffffff81099e96>] mark_lock+0x196/0x2f0
[ 81.725675] [<ffffffff810994b0>] ? check_usage_forwards+0x150/0x150
[ 81.725685] [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
[ 81.725691] [<ffffffff810899a5>] ? sched_clock_local+0x25/0x90
[ 81.725694] [<ffffffff81089b38>] ? sched_clock_cpu+0xa8/0x120
[ 81.725697] [<ffffffff8109a31a>] ? __lock_acquire+0x32a/0x1d70
[ 81.725699] [<ffffffff816dd751>] ? xfrm_stateonly_find+0x41/0x1f0
[ 81.725702] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 81.725704] [<ffffffff816dd751>] ? xfrm_stateonly_find+0x41/0x1f0
[ 81.725707] [<ffffffff810899a5>] ? sched_clock_local+0x25/0x90
[ 81.725710] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 81.725712] [<ffffffff816dd751>] ? xfrm_stateonly_find+0x41/0x1f0
[ 81.725715] [<ffffffff810971ec>] ? lock_release_holdtime.part.26+0x1c/0x1a0
[ 81.725717] [<ffffffff816dd751>] xfrm_stateonly_find+0x41/0x1f0
[ 81.725721] [<ffffffffa008af03>] mod_cur_headers+0x793/0x7f0 [pktgen]
[ 81.725724] [<ffffffffa008bca2>] pktgen_thread_worker+0xd42/0x1880 [pktgen]
[ 81.725727] [<ffffffffa008ba71>] ? pktgen_thread_worker+0xb11/0x1880 [pktgen]
[ 81.725729] [<ffffffff8109cf9d>] ? trace_hardirqs_on+0xd/0x10
[ 81.725733] [<ffffffff81775410>] ? _raw_spin_unlock_irq+0x30/0x40
[ 81.725745] [<ffffffff8151faa0>] ? e1000_clean+0x9d0/0x9d0
[ 81.725751] [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
[ 81.725753] [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
[ 81.725757] [<ffffffffa008af60>] ? mod_cur_headers+0x7f0/0x7f0 [pktgen]
[ 81.725759] [<ffffffff81078f84>] kthread+0xe4/0x100
[ 81.725762] [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
[ 81.725765] [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
[ 81.725768] [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
so /proc/net/xfrm_stat could give user clue about what's
wrong in this process.
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
xfrm_state lock protects its state, i.e., VALID/DEAD and statistics,
not the transforming procedure, as both mode/type output functions
are reentrant.
Another issue is state lock can be used in BH context when state timer
alarmed, after transformation in pktgen, update state statistics acquiring
state lock should disabled BH context for a moment. Otherwise LOCKDEP
critisize this:
[ 62.354339] pktgen: Packet Generator for packet performance testing. Version: 2.74
[ 62.655444]
[ 62.655448] =================================
[ 62.655451] [ INFO: inconsistent lock state ]
[ 62.655455] 3.13.0-rc2+ #70 Not tainted
[ 62.655457] ---------------------------------
[ 62.655459] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[ 62.655463] kpktgend_0/2764 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 62.655466] (&(&x->lock)->rlock){+.?...}, at: [<ffffffffa00886f6>] pktgen_thread_worker+0x1796/0x1860 [pktgen]
[ 62.655479] {IN-SOFTIRQ-W} state was registered at:
[ 62.655484] [<ffffffff8109a61d>] __lock_acquire+0x62d/0x1d70
[ 62.655492] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 62.655498] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 62.655505] [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
[ 62.655511] [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
[ 62.655519] [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
[ 62.655523] [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
[ 62.655526] [<ffffffff8105a026>] irq_exit+0x96/0xc0
[ 62.655530] [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
[ 62.655537] [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
[ 62.655541] [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
[ 62.655547] [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
[ 62.655552] [<ffffffff81761c3c>] rest_init+0xbc/0xd0
[ 62.655557] [<ffffffff81ea5e5e>] start_kernel+0x3c4/0x3d1
[ 62.655583] [<ffffffff81ea55a8>] x86_64_start_reservations+0x2a/0x2c
[ 62.655588] [<ffffffff81ea569f>] x86_64_start_kernel+0xf5/0xfc
[ 62.655592] irq event stamp: 77
[ 62.655594] hardirqs last enabled at (77): [<ffffffff810ab7f2>] vprintk_emit+0x1b2/0x520
[ 62.655597] hardirqs last disabled at (76): [<ffffffff810ab684>] vprintk_emit+0x44/0x520
[ 62.655601] softirqs last enabled at (22): [<ffffffff81059b57>] __do_softirq+0x177/0x2d0
[ 62.655605] softirqs last disabled at (15): [<ffffffff8105a026>] irq_exit+0x96/0xc0
[ 62.655609]
[ 62.655609] other info that might help us debug this:
[ 62.655613] Possible unsafe locking scenario:
[ 62.655613]
[ 62.655616] CPU0
[ 62.655617] ----
[ 62.655618] lock(&(&x->lock)->rlock);
[ 62.655622] <Interrupt>
[ 62.655623] lock(&(&x->lock)->rlock);
[ 62.655626]
[ 62.655626] *** DEADLOCK ***
[ 62.655626]
[ 62.655629] no locks held by kpktgend_0/2764.
[ 62.655631]
[ 62.655631] stack backtrace:
[ 62.655636] CPU: 0 PID: 2764 Comm: kpktgend_0 Not tainted 3.13.0-rc2+ #70
[ 62.655638] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox 12/01/2006
[ 62.655642] ffffffff8216b7b0 ffff88001be43ab8 ffffffff8176af37 0000000000000007
[ 62.655652] ffff88001c8d4fc0 ffff88001be43b18 ffffffff81766d78 0000000000000000
[ 62.655663] ffff880000000001 ffff880000000001 ffffffff8101025f ffff88001be43b18
[ 62.655671] Call Trace:
[ 62.655680] [<ffffffff8176af37>] dump_stack+0x46/0x58
[ 62.655685] [<ffffffff81766d78>] print_usage_bug+0x1f1/0x202
[ 62.655691] [<ffffffff8101025f>] ? save_stack_trace+0x2f/0x50
[ 62.655696] [<ffffffff81099f8c>] mark_lock+0x28c/0x2f0
[ 62.655700] [<ffffffff810994b0>] ? check_usage_forwards+0x150/0x150
[ 62.655704] [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
[ 62.655712] [<ffffffff81115b09>] ? irq_work_queue+0x69/0xb0
[ 62.655717] [<ffffffff810ab7f2>] ? vprintk_emit+0x1b2/0x520
[ 62.655722] [<ffffffff8109cec5>] ? trace_hardirqs_on_caller+0x105/0x1d0
[ 62.655730] [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
[ 62.655734] [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
[ 62.655741] [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
[ 62.655745] [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
[ 62.655752] [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
[ 62.655758] [<ffffffffa00886f6>] pktgen_thread_worker+0x1796/0x1860 [pktgen]
[ 62.655766] [<ffffffffa0087a79>] ? pktgen_thread_worker+0xb19/0x1860 [pktgen]
[ 62.655771] [<ffffffff8109cf9d>] ? trace_hardirqs_on+0xd/0x10
[ 62.655777] [<ffffffff81775410>] ? _raw_spin_unlock_irq+0x30/0x40
[ 62.655785] [<ffffffff8151faa0>] ? e1000_clean+0x9d0/0x9d0
[ 62.655791] [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
[ 62.655795] [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
[ 62.655800] [<ffffffffa0086f60>] ? mod_cur_headers+0x7f0/0x7f0 [pktgen]
[ 62.655806] [<ffffffff81078f84>] kthread+0xe4/0x100
[ 62.655813] [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
[ 62.655819] [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
[ 62.655824] [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
The VLAN tag handling code in netpoll_send_skb_on_dev() has two problems.
1) It exits without unlocking the TXQ.
2) It then tries to queue a NULL skb to npinfo->txq.
Reported-by: Ahmed Tamrawi <atamrawi@iastate.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
when read/write the 64bit data, the correct lock should be hold.
and we can use the generic vti6_get_stats to return stats, and
not define a new one in ip6_vti.c
Fixes: 87b6d218f3adb ("tunnel: implement 64 bits statistics")
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
when read/write the 64bit data, the correct lock should be hold.
Fixes: 87b6d218f3adb ("tunnel: implement 64 bits statistics")
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
valid_lft is infinity
Fixed a problem with setting the lifetime of an IPv6
address. When setting preferred_lft to a value not zero or
infinity, while valid_lft is infinity(0xffffffff) preferred
lifetime is set to forever and does not update. Therefore
preferred lifetime never becomes deprecated. valid lifetime
and preferred lifetime should be set independently, even if
valid lifetime is infinity, preferred lifetime must expire
correctly (meaning it must eventually become deprecated)
Signed-off-by: Yasushi Asano <yasushi.asano@jp.fujitsu.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
While commit 30a584d944fb fixes datagram interface in LLC, a use
after free bug has been introduced for SOCK_STREAM sockets that do
not make use of MSG_PEEK.
The flow is as follow ...
if (!(flags & MSG_PEEK)) {
...
sk_eat_skb(sk, skb, false);
...
}
...
if (used + offset < skb->len)
continue;
... where sk_eat_skb() calls __kfree_skb(). Therefore, cache
original length and work on skb_len to check partial reads.
Fixes: 30a584d944fb ("[LLX]: SOCK_DGRAM interface fixes")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
VM to VM GSO traffic is broken if it goes through VXLAN or GRE
tunnel and the physical NIC on the host supports hardware VXLAN/GRE
GSO offload (e.g. bnx2x and next-gen mlx4).
Two issues -
(VXLAN) VM traffic has SKB_GSO_DODGY and SKB_GSO_UDP_TUNNEL with
SKB_GSO_TCP/UDP set depending on the inner protocol. GSO header
integrity check fails in udp4_ufo_fragment if inner protocol is
TCP. Also gso_segs is calculated incorrectly using skb->len that
includes tunnel header. Fix: robust check should only be applied
to the inner packet.
(VXLAN & GRE) Once GSO header integrity check passes, NULL segs
is returned and the original skb is sent to hardware. However the
tunnel header is already pulled. Fix: tunnel header needs to be
restored so that hardware can perform GSO properly on the original
packet.
Signed-off-by: Wei-Chun Chao <weichunc@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit de6fb288b1246a5c4e00c0cdbfe3a838a360b3f4.
Otherwise we got:
net/sched/cls_cgroup.c:106:29: error: static declaration of ‘net_cls_subsys’ follows non-static declaration
static struct cgroup_subsys net_cls_subsys = {
^
In file included from include/linux/cgroup.h:654:0,
from net/sched/cls_cgroup.c:18:
include/linux/cgroup_subsys.h:35:29: note: previous declaration of ‘net_cls_subsys’ was here
SUBSYS(net_cls)
^
make[2]: *** [net/sched/cls_cgroup.o] Error 1
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The SCTP outqueue structure maintains a data chunks
that are pending transmission, the list of chunks that
are pending a retransmission and a length of data in
flight. It also tries to keep the emtpy state so that
it can performe shutdown sequence or notify user.
The problem is that the empy state is inconsistently
tracked. It is possible to completely drain the queue
without sending anything when using PR-SCTP. In this
case, the empty state will not be correctly state as
report by Jamal Hadi Salim <jhs@mojatatu.com>. This
can cause an association to be perminantly stuck in the
SHUTDOWN_PENDING state.
Additionally, SCTP is incredibly inefficient when setting
the empty state. Even though all the data is availaible
in the outqueue structure, we ignore it and walk a list
of trasnports.
In the end, we can completely remove the extra empty
state and figure out if the queue is empty by looking
at 3 things: length of pending data, length of in-flight
data, and exisiting of retransmit data. All of these
are already in the strucutre.
Reported-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Doesn't need to be global.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
No need to export functions only used in one file.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
since the prune parameter for fib6_clean_all always is 0, remove it.
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In commit 3b8401fe9d ("tipc: kill unnecessary goto's") didn't make
the code look most readable, so fix it. This patch is cosmetic
and does not change the operation of TIPC in any way.
Suggested-by: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
Fix that "else should follow close brace '}'".
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
Fix checkpatch error "space prohibited xxx".
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
This patch clean up some checkpatch errors like this:
ERROR: "foo * bar" should be "foo *bar"
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
This patch cleanup some space errors.
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
|
|
arp_accept is set
Gratuitous arp packets are useful in switchover scenarios to update
client arp tables as quickly as possible. Currently, the mac address
of a neighbour is only updated after a locktime period has elapsed
since the last update. In most use cases such delays are unacceptable
for network admins. Moreover, the "updated" field of the neighbour
stucture doesn't record the last time the address of a neighbour
changed but records any change that happens to the neighbour. This is
clearly a bug since locktime uses that field as meaning "addr_updated".
With this observation, I was able to perpetuate a stale address by
sending a stream of gratuitous arp packets spaced less than locktime
apart. With this change the address is updated when a gratuitous arp
is received and the arp_accept sysctl is set.
Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Running 'make namespacecheck' shows:
net/ipv6/route.o
ipv6_route_table_template
rt6_bind_peer
net/ipv6/icmp.o
icmpv6_route_lookup
ipv6_icmp_table_template
This addresses some of those warnings by:
* make icmpv6_route_lookup static
* move inline's out of ip6_route.h since only used into route.c
* move rt6_bind_peer into route.c
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
