Currently we generate a new fragmentation id on UFO segmentation. It
is pretty hairy to identify the correct net namespace and dst there.
Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst
available at all.
This causes unreliable or very predictable ipv6 fragmentation id
generation while segmentation.
Luckily we already have pregenerated the ip6_frag_id in
ip6_ufo_append_data and can use it here.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes bug introduced by:
commit 1d4c8c2984
"neigh: restore old behaviour of default parms values"
The thing is that in neigh_sysctl_register, extra1 and extra2 which were
previously set for NEIGH_VAR_GC_* are overwritten. That leads to
nonsense int limits for gc_* variables. So fix this by not touching
extra* fields for gc_* variables.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes two bugs in fastopen :
1) The tcp_sendmsg(..., @size) argument was ignored.
Code was relying on user not fooling the kernel with iovec mismatches
2) When MTU is about 64KB, tcp_send_syn_data() attempts order-5
allocations, which are likely to fail when memory gets fragmented.
Fixes: 783237e8da ("net-tcp: Fast Open client - sending SYN-data")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Tested-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ying Xue says:
====================
tipc: clean up components initialization code
In this series, we will fix a regression issue involved by commit
6e967adf7(tipc: relocate common functions from media to bearer)
But before the issue is fixed, we firstly adjust the process of
components initialization so as to remove all enabled flags from
necessary tipc components. Otherwise, without the change, we also
have to add an extra enabled flag into bearer layer indicating
whether bearer setup is finshed or not.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Accidentally a side effect is involved by commit 6e967adf7(tipc:
relocate common functions from media to bearer). Now tipc stack
handler of receiving packets from netdevices as well as netdevice
notification handler are registered when bearer is enabled rather
than tipc module initialization stage, but the two handlers are
both unregistered in tipc module exit phase. If tipc module is
inserted and then immediately removed, the following warning
message will appear:
"dev_remove_pack: ffffffffa0380940 not found"
This is because in module insertion stage tipc stack packet handler
is not registered at all, but in module exit phase dev_remove_pack()
needs to remove it. Of course, dev_remove_pack() cannot find tipc
protocol handler from the kernel protocol handler list so that the
warning message is printed out.
But if registering the two handlers is adjusted from enabling bearer
phase into inserting module stage, the warning message will be
eliminated. Due to this change, tipc_core_start_net() and
tipc_core_stop_net() can be deleted as well.
Reported-by: Wang Weidong <wangweidong1@huawei.com>
Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When tipc module is inserted, many tipc components are initialized
one by one. During the initialization period, if one of them is
failed, tipc_core_stop() will be called to stop all components
whatever corresponding components are created or not. To avoid to
release uncreated ones, relevant components have to add necessary
enabled flags indicating whether they are created or not.
But in the initialization stage, if one component is unsuccessfully
created, we will just destroy successfully created components before
the failed component instead of all components. All enabled flags
defined in components, in turn, become redundant. Additionally it's
also unnecessary to identify whether table.types is NULL in
tipc_nametbl_stop() because name stable has been definitely created
successfully when tipc_nametbl_stop() is called.
Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In current implementation it is possible to reach PF state from unconfirmed.
We can interpret sctp-failover-02 in a way that PF state is meant to be reached
only from active state, in the end, this is when entering PF state makes sense.
Here are few quotes from sctp-failover-02, but regardless of these, same
understanding can be reached from whole section 5:
Section 5.1, quickfailover guide:
"The PF state is an intermediate state between Active and Failed states."
"Each time the T3-rtx timer expires on an active or idle
destination, the error counter of that destination address will
be incremented. When the value in the error counter exceeds
PFMR, the endpoint should mark the destination transport address as PF."
There are several concrete reasons for such interpretation. For start, rfc4960
does not take into concern quickfailover algorithm. Therefore, quickfailover
must comply to 4960. Point where this compliance can be argued is following
behavior:
When PF is entered, association overall error counter is incremented for each
missed HB. This is contradictory to rfc4960, as address, while in unconfirmed
state, is subjected to probing, and while it is probed, it should not increment
association overall error counter. This has as a consequence that we might end
up in situation in which we drop association due path failure on unconfirmed
address, in case we have wrong configuration in a way:
Association.Max.Retrans == Path.Max.Retrans.
Another reason is that entering PF from unconfirmed will cause a loss of address
confirmed event when address is once (if) confirmed. This is fine from failover
guide point of view, but it is not consistent with behavior preceding failover
implementation and recommendation from 4960:
5.4. Path Verification
Whenever a path is confirmed, an indication MAY be given to the upper
layer.
Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current flow: Set TX BD ready, and then set "INT" and "PINS" bit to
enable tx interrupt generation and crc checksum.
There has potential issue like as:
CPU fec uDMA
Set tx ready bit
uDMA start the BD transmission
Set "INT" bit
Set "PINS" bit
...
Above situation cause fec tx interrupt lost and fec MAC don't do
CRC checksum. The patch fix the potential issue.
Signed-off-by: Fugang Duan <B38611@freescale.com>
Acked-by: Frank Li <Frank.li@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bug introduced by commit 7d442fab0a ("ipv4: Cache dst in tunnels").
Because sit code does not call ip_tunnel_init(), the dst_cache was not
initialized.
CC: Tom Herbert <therbert@google.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Even though only the outer vlan tag can be HW accelerated in the transmission
path, in the TUN/TAP driver vlan_features mirrors hw_features, which happens
to have the NETIF_F_HW_VLAN_?TAG_TX flags set. Because of this, during packet
tranmisssion through a stacked vlan device dev_hard_start_xmit, (incorrectly)
assuming that the vlan device supports hardware vlan acceleration, does not
add the vlan header to the skb payload and the inner vlan tags are lost
(vlan_tci contains the outer vlan tag when userspace reads the packet from
the tap device).
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Even if we create a stacked vlan interface such as veth0.10.20, it sends
single tagged frames (tagged with only vid 10).
Because vlan_features of a veth interface has the
NETIF_F_HW_VLAN_[CTAG/STAG]_TX bits, veth0.10 also has that feature, so
dev_hard_start_xmit(veth0.10) doesn't call __vlan_put_tag() and
vlan_dev_hard_start_xmit(veth0.10) overwrites vlan_tci.
This prevents us from using a combination of 802.1ad and 802.1Q
in containers, etc.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Acked-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/built-in.o:(.rodata+0x1707c): undefined reference to `ip_tunnel_get_stats64'
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
In ed1f50c3a ("net: add skb_checksum_setup") we introduced some checksum
functions in core driver. Subsequent change b5cf66cd1 ("xen-netfront:
use new skb_checksum_setup function") made use of those functions to
replace its own implementation.
However with that change netfront is broken. It sees a lot of checksum
error. That's because its own implementation of checksum function was a
bit hacky (dereferencing skb->data directly) while the new function was
implemented using ip_hdr(). The network header is not reset before skb
is passed to the new function. When the new function tries to do its
job, it's confused and reports error.
The fix is simple, we need to reset network header before passing skb to
checksum function. Netback is not affected as it already does the right
thing.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Paul Durrant <paul.durrant@citrix.com>
Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for your net tree,
they are:
* Fix nf_trace in nftables if XT_TRACE=n, from Florian Westphal.
* Don't use the fast payload operation in nf_tables if the length is
not power of 2 or it is not aligned, from Nikolay Aleksandrov.
* Fix missing break statement the inet flavour of nft_reject, which
results in evaluating IPv4 packets with the IPv6 evaluation routine,
from Patrick McHardy.
* Fix wrong kconfig symbol in nft_meta to match the routing realm,
from Paul Bolle.
* Allocate the NAT null binding when creating new conntracks via
ctnetlink to avoid that several packets race at initializing the
the conntrack NAT extension, original patch from Florian Westphal,
revisited version from me.
* Fix DNAT handling in the snmp NAT helper, the same handling was being
done for SNAT and DNAT and 2.4 already contains that fix, from
Francois-Xavier Le Bail.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull drm fixes from Dave Airlie:
"Lots of little small things, nothing too major: nouveau regression
fixes, vmware fixes for the new hw support, memory leaks in error path
fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (31 commits)
drm/radeon/ni: fix typo in dpm sq ramping setup
drm/radeon/si: fix typo in dpm sq ramping setup
drm/radeon: fix CP semaphores on CIK
drm/radeon: delete a stray tab
drm/radeon: fix display tiling setup on SI
drm/radeon/dpm: reduce r7xx vblank mclk threshold to 200
drm/radeon: fill in DRM_CAPs for cursor size
drm: add DRM_CAPs for cursor size
drm/radeon: unify bpc handling
drm/ttm: Fix memory leak in ttm_agp_backend.c
drm/ttm: declare 'struct device' in ttm_page_alloc.h
drm/nouveau: fix TTM_PL_TT memtype on pre-nv50
drm/nv50/disp: use correct register to determine DP display bpp
drm/nouveau/fb: use correct ram oclass for nv1a hardware
drm/nv50/gr: add missing nv_error parameter priv
drm/nouveau: fix ENG_RUNLIST register address
drm/nv4c/bios: disallow retrieving from prom on nv4x igp's
drm/nv4c/vga: decode register is in a different place on nv4x igp's
drm/nv4c/mc: nv4x igp's have a different msi rearm register
drm/nouveau: set irq_enabled manually
...
Pull HID update from Jiri Kosina:
- fixes for several bugs in incorrect allocations of buffers by David
Herrmann and Benjamin Tissoires.
- support for a few new device IDs by Archana Patni, Benjamin
Tissoires, Huei-Horng Yo, Reyad Attiyat and Yufeng Shen
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: hyperv: make sure input buffer is big enough
HID: Bluetooth: hidp: make sure input buffers are big enough
HID: hid-sensor-hub: quirk for STM Sensor hub
HID: apple: add Apple wireless keyboard 2011 JIS model support
HID: fix buffer allocations
HID: multitouch: add FocalTech FTxxxx support
HID: microsoft: Add ID's for Surface Type/Touch Cover 2
HID: usbhid: quirk for CY-TM75 75 inch Touch Overlay
Pull networking fixes from David Miller:
1) kvaser CAN driver has fixed limits of some of it's table, validate
that we won't exceed those limits at probe time. Fix from Olivier
Sobrie.
2) Fix rtl8192ce disabling interrupts for too long, from Olivier
Langlois.
3) Fix botched shift in ath5k driver, from Dan Carpenter.
4) Fix corruption of deferred packets in TIPC, from Erik Hugne.
5) Fix newlink error path in macvlan driver, from Cong Wang.
6) Fix netpoll deadlock in bonding, from Ding Tianhong.
7) Handle GSO packets properly in forwarding path when fragmentation is
necessary on egress, from Florian Westphal.
8) Fix axienet build errors, from Michal Simek.
9) Fix refcounting of ubufs on tx in vhost net driver, from Michael S
Tsirkin.
10) Carrier status isn't set properly in hyperv driver, from Haiyang
Zhang.
11) Missing pci_disable_device() in tulip_remove_one), from Ingo Molnar.
12) AF_PACKET qdisc bypass mode doesn't adhere to driver provided TX
queue selection method. Add a fallback method mechanism to fix this
bug, from Daniel Borkmann.
13) Fix regression in link local route handling on GRE tunnels, from
Nicolas Dichtel.
14) Bonding can assign dup aggregator IDs in some sequences of
configuration, fix by making the allocation counter per-bond instead
of global. From Jiri Bohac.
15) sctp_connectx() needs compat translations, from Daniel Borkmann.
16) Fix of_mdio PHY interrupt parsing, from Ben Dooks
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (62 commits)
MAINTAINERS: add entry for the PHY library
of_mdio: fix phy interrupt passing
net: ethernet: update dependency and help text of mvneta
NET: fec: only enable napi if we are successful
af_packet: remove a stray tab in packet_set_ring()
net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode
ipv4: fix counter in_slow_tot
irtty-sir.c: Do not set_termios() on irtty_close()
bonding: 802.3ad: make aggregator_identifier bond-private
usbnet: remove generic hard_header_len check
gre: add link local route when local addr is any
batman-adv: fix potential kernel paging error for unicast transmissions
batman-adv: avoid double free when orig_node initialization fails
batman-adv: free skb on TVLV parsing success
batman-adv: fix TT CRC computation by ensuring byte order
batman-adv: fix potential orig_node reference leak
batman-adv: avoid potential race condition when adding a new neighbour
batman-adv: properly check pskb_may_pull return value
batman-adv: release vlan object after checking the CRC
batman-adv: fix TT-TVLV parsing on OGM reception
...
Pull ARM fixes from Russell King:
"A range of ARM fixes. Biggest change is the stage-2 attributes used
for for hyp mode which were wrong. I've killed some bits in a couple
of DT files which turned out not to be required, and a few other
fixes.
One fix touches code outside of arch/arm, which is related to sorting
out the DMA masks correctly. There is a long standing issue with the
conversion from PFNs to addresses where people assume that shifting an
unsigned long left by PAGE_SHIFT results in a correct address. This
is not the case with C: the integer promotion happens at assignment
after evaluation. This fixes the recently introduced dma_max_pfn()
function, but there's a number of other places where we try this
directly on an unsigned long in the mm code"
* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 7957/1: add DSB after icache flush in __flush_icache_all()
Fix uses of dma_max_pfn() when converting to a limiting address
ARM: 7955/1: spinlock: ensure we have a compiler barrier before sev
ARM: 7953/1: mm: ensure TLB invalidation is complete before enabling MMU
ARM: 7952/1: mm: Fix the memblock allocation for LPAE machines
ARM: 7950/1: mm: Fix stage-2 device memory attributes
ARM: dts: fix spdif pinmux configuration
Pull jfs fix from David Kleikamp:
"Another ACL regression. This one more subtle"
* tag 'jfs-3.14-rc4' of git://github.com/kleikamp/linux-shaggy:
jfs: set i_ctime when setting ACL
The PHY library has been subject to some changes, new drivers and DT
interactions over the past few months. Add myself as a maintainer for
the core PHY library parts and drivers. Make sure the PHY library entry
also covers the Device Tree files which have a close interaction with
the MDIO bus, PHY connection and Ethernet PHY mode parsing.
CC: Grant Likely <grant.likely@linaro.org>
CC: Shaohui Xie <shaohui.xie@freescale.com>
CC: Andy Fleming <afleming@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The of_mdiobus_register_phy() is not setting phy->irq thus causing
some drivers to incorrectly assume that the PHY does not have an
IRQ associated with it. Not only do some drivers report no IRQ
they do not install an interrupt handler for the PHY.
Simplify the code setting irq and set the phy->irq at the same
time so that we cover the following issues, which should cover
all the cases the code will find:
- Set phy->irq if node has irq property and mdio->irq is NULL
- Set phy->irq if node has no irq and mdio->irq is not NULL
- Leave phy->irq as PHY_POLL default if none of the above
This fixes the issue:
net eth0: attached PHY 1 (IRQ -1) to driver Micrel KSZ8041RNLI
to the correct:
net eth0: attached PHY 1 (IRQ 416) to driver Micrel KSZ8041RNLI
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
With the introduction of the support for Armada 375 and Armada 38x,
the hidden Kconfig option MACH_ARMADA_370_XP is being renamed to
MACH_MVEBU_V7. Therefore, the dependency that was used for the mvneta
driver can no longer work. This commit replaces this dependency by a
dependency on PLAT_ORION, which is used similarly for the mv643xx_eth
driver.
In addition to this, it takes this opportunity to adjust the
description and help text to indicate that the driver can is also used
for Armada 38x. Note that Armada 375 cannot use this driver as it has
a completely different networking unit, which will require a separate
driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jason Wang
Hannes Frederic Sowa
Daniel Borkmann
Jiri Pirko
Eric Dumazet
David S. Miller
Ying Xue
Matija Glavinic Pecotic
Duan Fugang-B38611
Nicolas Dichtel
Fernando Luis Vazquez Cao
Toshiaki Makita
Wei Liu
Max Filippov
Linus Torvalds
Florian Fainelli
Ben Dooks
Thomas Petazzoni