Julia Lawall pointed out that IPSET_ATTR_ETHER netlink attribute length
was not checked explicitly, just for the maximum possible size. Malicious
netlink clients could send shorter attribute and thus resulting a kernel
read after the buffer.
The patch adds the explicit length checkings.
Reported-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
The NETFILTER_XT_TARGET_TEE option selects NF_DUP_IPV6 whenever
IP6_NF_IPTABLES is enabled, and it ensures that it cannot be
builtin itself if NF_CONNTRACK is a loadable module, as that
is a dependency for NF_DUP_IPV6.
However, NF_DUP_IPV6 can be enabled even if IP6_NF_IPTABLES is
turned off, and it only really depends on IPV6. With the current
check in tee_tg6, we call nf_dup_ipv6() whenever NF_DUP_IPV6
is enabled. This can however be a loadable module which is
unreachable from a built-in xt_TEE:
net/built-in.o: In function `tee_tg6':
:(.text+0x67728): undefined reference to `nf_dup_ipv6'
The bug was originally introduced in the split of the xt_TEE module
into separate modules for ipv4 and ipv6, and two patches tried
to fix it unsuccessfully afterwards.
This is a revert of the the first incorrect attempt to fix it,
going back to depending on IPV6 as the dependency, and we
adapt the 'select' condition accordingly.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: bbde9fc1824a ("netfilter: factor out packet duplication for IPv4/IPv6") Fixes: 116984a316c3 ("netfilter: xt_TEE: use IS_ENABLED(CONFIG_NF_DUP_IPV6)") Fixes: 74ec4d55c4d2 ("netfilter: fix xt_TEE and xt_TPROXY dependencies") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Phil Turnbull [Tue, 2 Feb 2016 18:36:45 +0000 (13:36 -0500)]
netfilter: nfnetlink: correctly validate length of batch messages
If nlh->nlmsg_len is zero then an infinite loop is triggered because
'skb_pull(skb, msglen);' pulls zero bytes.
The calculation in nlmsg_len() underflows if 'nlh->nlmsg_len <
NLMSG_HDRLEN' which bypasses the length validation and will later
trigger an out-of-bound read.
If the length validation does fail then the malformed batch message is
copied back to userspace. However, we cannot do this because the
nlh->nlmsg_len can be invalid. This leads to an out-of-bounds read in
netlink_ack:
[ 41.455421] ==================================================================
[ 41.456431] BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr ffff880119e79340
[ 41.456431] Read of size 4294967280 by task a.out/987
[ 41.456431] =============================================================================
[ 41.456431] BUG kmalloc-512 (Not tainted): kasan: bad access detected
[ 41.456431] -----------------------------------------------------------------------------
...
[ 41.456431] Bytes b4 ffff880119e79310: 00 00 00 00 d5 03 00 00 b0 fb fe ff 00 00 00 00 ................
[ 41.456431] Object ffff880119e79320: 20 00 00 00 10 00 05 00 00 00 00 00 00 00 00 00 ...............
[ 41.456431] Object ffff880119e79330: 14 00 0a 00 01 03 fc 40 45 56 11 22 33 10 00 05 .......@EV."3...
[ 41.456431] Object ffff880119e79340: f0 ff ff ff 88 99 aa bb 00 14 00 0a 00 06 fe fb ................
^^ start of batch nlmsg with
nlmsg_len=4294967280
...
[ 41.456431] Memory state around the buggy address:
[ 41.456431] ffff880119e79400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 41.456431] ffff880119e79480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 41.456431] >ffff880119e79500: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
[ 41.456431] ^
[ 41.456431] ffff880119e79580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 41.456431] ffff880119e79600: fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb fb
[ 41.456431] ==================================================================
Fix this with better validation of nlh->nlmsg_len and by setting
NFNL_BATCH_FAILURE if any batch message fails length validation.
CAP_NET_ADMIN is required to trigger the bugs.
Fixes: 9ea2aa8b7dba ("netfilter: nfnetlink: validate nfnetlink header from batch") Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Florian Westphal [Thu, 28 Jan 2016 12:16:59 +0000 (13:16 +0100)]
netfilter: cttimeout: fix deadlock due to erroneous unlock/lock conversion
The spin_unlock call should have been left as-is, revert.
Fixes: b16c29191dc89bd ("netfilter: nf_conntrack: use safer way to lock all buckets") Reported-by: kernel test robot <fengguang.wu@intel.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
netfilter: nfnetlink: use original skbuff when acking batches
Since bd678e09dc17 ("netfilter: nfnetlink: fix splat due to incorrect
socket memory accounting in skbuff clones"), we don't manually attach
the sk to the skbuff clone anymore, so we have to use the original
skbuff from netlink_ack() which needs to access the sk pointer.
Fixes: bd678e09dc17 ("netfilter: nfnetlink: fix splat due to incorrect socket memory accounting in skbuff clones") Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Problem is that nf_ct_iterate_cleanup can run for a very long time
since it can be interrupted by softirq processing.
Moreover, atomic_notifier_call_chain runs with rcu readlock held.
So lets call cond_resched() in nf_ct_iterate_cleanup and defer
the call to a work queue for the atomic_notifier_call_chain case.
We also need another cond_resched in get_next_corpse, since we
have to deal with iter() always returning false, in that case
get_next_corpse will walk entire conntrack table.
David S. Miller [Sat, 30 Jan 2016 23:32:42 +0000 (15:32 -0800)]
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Johan Hedberg says:
====================
pull request: bluetooth 2016-01-30
Here's a set of important Bluetooth fixes for the 4.5 kernel:
- Two fixes to 6LoWPAN code (one fixing a potential crash)
- Fix LE pairing with devices using both public and random addresses
- Fix allocation of dynamic LE PSM values
- Fix missing COMPATIBLE_IOCTL for UART line discipline
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Yuchung Cheng [Fri, 29 Jan 2016 23:11:50 +0000 (15:11 -0800)]
tcp: avoid cwnd undo after receiving ECN
RFC 4015 section 3.4 says the TCP sender MUST refrain from
reversing the congestion control state when the ACK signals
congestion through the ECN-Echo flag. Currently we may not
always do that when prior_ssthresh is reset upon receiving
ACKs with ECE marks. This patch fixes that.
Signed-off-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
WANG Cong [Fri, 29 Jan 2016 19:58:03 +0000 (11:58 -0800)]
irda: fix a potential use-after-free in ircomm_param_request
self->ctrl_skb is protected by self->spinlock, we should not
access it out of the lock. Move the debugging printk inside.
Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Samuel Ortiz <samuel@sortiz.org> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Fri, 29 Jan 2016 11:39:15 +0000 (12:39 +0100)]
net: tg3: avoid uninitialized variable warning
The tg3_set_eeprom() function correctly initializes the 'start' variable,
but gcc generates a false warning:
drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom':
drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
I have not come up with a way to restructure the code in a way that
avoids the warning without making it less readable, so this adds an
initialization for the declaration to shut up that warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Fri, 29 Jan 2016 11:39:14 +0000 (12:39 +0100)]
net: nb8800: avoid uninitialized variable warning
The nb8800_poll() function initializes the 'next' variable in the
loop looking for new input data. We know this will be called at
least once because 'budget' is a guaranteed to be a positive number
when we enter the function, but the compiler doesn't know that
and warns when the variable is used later:
drivers/net/ethernet/aurora/nb8800.c: In function 'nb8800_poll':
drivers/net/ethernet/aurora/nb8800.c:350:21: warning: 'next' may be used uninitialized in this function [-Wmaybe-uninitialized]
Changing the 'while() {}' loop to 'do {} while()' makes it obvious
to the compiler what is going on so it no longer warns.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mans Rullgard <mans@mansr.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Fri, 29 Jan 2016 11:39:13 +0000 (12:39 +0100)]
net: vxge: avoid unused function warnings
When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
in the vxge driver:
drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning: 'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning: 'adaptive_coalesce_rx_interrupts' defined but not used [-Wunused-function]
We could add another #ifdef here, but it's nicer to avoid those warnings
for good by converting the existing #ifdef to if(IS_ENABLED()), which has
the same effect but provides better compile-time coverage in general,
and lets the compiler understand better when the function is intentionally
unused.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Fri, 29 Jan 2016 11:39:12 +0000 (12:39 +0100)]
net: bgmac: clarify CONFIG_BCMA dependency
The bgmac driver depends on BCMA_HOST_SOC, which is only used
when CONFIG_BCMA is enabled. However, it is a bool option and can
be set when CONFIG_BCMA=m, and then bgmac can be built-in, leading
to an obvious link error:
drivers/built-in.o: In function `bgmac_init':
:(.init.text+0x7f2c): undefined reference to `__bcma_driver_register'
drivers/built-in.o: In function `bgmac_exit':
:(.exit.text+0x110a): undefined reference to `bcma_driver_unregister'
To avoid this case, we need to depend on both BCMA and BCMA_SOC,
as this patch does. I'm also trying to make the dependency more
readable by splitting it into three lines, and adding a COMPILE_TEST
alternative so we can test-build it in all configurations that
support BCMA.
The added dependency on FIXED_PHY addresses a related issue where
we cannot call fixed_phy_register() when CONFIG_FIXED_PHY=m and
CONFIG_BGMAC=y.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Fri, 29 Jan 2016 11:39:11 +0000 (12:39 +0100)]
net: hp100: remove unnecessary #ifdefs
Building the hp100 ethernet driver causes warnings when both the PCI
and EISA drivers are disabled:
ethernet/hp/hp100.c: In function 'hp100_module_init':
ethernet/hp/hp100.c:3047:2: warning: label 'out3' defined but not used [-Wunused-label]
ethernet/hp/hp100.c: At top level:
ethernet/hp/hp100.c:2828:13: warning: 'cleanup_dev' defined but not used [-Wunused-function]
We can easily avoid the warnings and make the driver look slightly
nicer by removing the #ifdefs that check for the CONFIG_PCI and
CONFIG_EISA, as all the registration functions are designed to
have no effect when the buses are disabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Fri, 29 Jan 2016 11:39:10 +0000 (12:39 +0100)]
net: davinci_cpdma: use dma_addr_t for DMA address
The davinci_cpdma mixes up physical addresses as seen from the CPU
and DMA addresses as seen from a DMA master, since it can operate
on both normal memory or an on-chip buffer. If dma_addr_t is
different from phys_addr_t, this means we get a compile-time warning
about the type mismatch:
ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
In file included from ethernet/ti/davinci_cpdma.c:21:0:
dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
static inline void *dma_alloc_coherent(struct device *dev, size_t size,
This slightly restructures the code so the address we use for
mapping RAM into a DMA address is always a dma_addr_t, avoiding
the warning. The code is correct even if both types are 32-bit
because the DMA master in this device only supports 32-bit addressing
anyway, independent of the types that are used.
We still assign this value to pool->phys, and that is wrong if
the driver is ever used with an IOMMU, but that value appears to
be never used, so there is no problem really. I've added a couple
of comments about where we do things that are slightly violating
the API.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
ip addr add dev eth0 2001:0010::1/64
ip addr add dev eth1 2001:0020::1/64
ping6 -I eth0 2001:0020::2
do not lead to the expected results, i.e. eth1 is used as the
egress interface.
This is due to two related issues in handling sticky pktinfo,
used by ping6 to enforce the device binding:
- ip6_dst_lookup_flow()/ip6_dst_lookup_tail() do not really enforce
flowi6_oif match
- ipv6 udp connect() just ignore flowi6_oif
These patches address each issue individually.
The kernel has never enforced the egress interface specified
via the sticky pktinfo, except briefly between the commits 741a11d9e410 ("net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is set")
and d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE flag if saddr set"),
but the ping6 tools was unaffected up to iputils-20100214,
since before it used SO_BINDTODEVICE to enforce the egress
interface.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Paolo Abeni [Fri, 29 Jan 2016 11:30:20 +0000 (12:30 +0100)]
ipv6/udp: use sticky pktinfo egress ifindex on connect()
Currently, the egress interface index specified via IPV6_PKTINFO
is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7
can be subverted when the user space application calls connect()
before sendmsg().
Fix it by initializing properly flowi6_oif in connect() before
performing the route lookup.
Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Paolo Abeni [Fri, 29 Jan 2016 11:30:19 +0000 (12:30 +0100)]
ipv6: enforce flowi6_oif usage in ip6_dst_lookup_tail()
The current implementation of ip6_dst_lookup_tail basically
ignore the egress ifindex match: if the saddr is set,
ip6_route_output() purposefully ignores flowi6_oif, due
to the commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE
flag if saddr set"), if the saddr is 'any' the first route lookup
in ip6_dst_lookup_tail fails, but upon failure a second lookup will
be performed with saddr set, thus ignoring the ifindex constraint.
This commit adds an output route lookup function variant, which
allows the caller to specify lookup flags, and modify
ip6_dst_lookup_tail() to enforce the ifindex match on the second
lookup via said helper.
ip6_route_output() becames now a static inline function build on
top of ip6_route_output_flags(); as a side effect, out-of-tree
modules need now a GPL license to access the output route lookup
functionality.
Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 30 Jan 2016 04:26:08 +0000 (20:26 -0800)]
Merge tag 'wireless-drivers-for-davem-2016-01-29' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
iwlwifi
* Fix support for 3168 device:
* NVM version
* firmware file name
* device IDs
* Fix a compilation warning in dvm calibration code
* Fix the TPC (reduced Tx Power) code. This fixes performance issues
* Add device IDs for 8265
rtx2x00
* fix monitor mode regression dating back to 4.1
brcmfmac
* fix sdio initialisation related crash
rtlwifi
* rtl8821ae: Fix 5G failure when EEPROM is incorrectly encoded
ath9k
* ignore eeprom magic mismatch on flash based devices
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We should not trim skb for mmaped socket since its buf size is fixed
and userspace will read as frame which data equals head. mmaped
socket will not call recvmsg, means max_recvmsg_len is 0,
skb_reserve was not called before commit: db65a3aaf29e.
Fixes: db65a3aaf29e (netlink: Trim skb to alloc size to avoid MSG_TRUNC) Signed-off-by: Ken-ichirou MATSUZAWA <chamas@h4.dion.ne.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
it can be fixed by enlarging the all_zeros_mac to 8 byte, although it is
harmless; eth_hash() will be called in other place with the memory which
is larger and equal to 8 byte.
Signed-off-by: Li RongQing <roy.qing.li@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This means that port 3 is allowed to talk to port 2-6, but cannot talk
to ports 0 and 1. With this fix, port 3 can correctly talk to all ports
except 3 itself:
Fixes: ede8098d0fef ("net: dsa: mv88e6xxx: bridges do not need an FID") Reported-by: Kevin Smith <kevin.smith@elecsyscorp.com> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Thu, 28 Jan 2016 21:42:24 +0000 (13:42 -0800)]
fib_trie: Fix shift by 32 in fib_table_lookup
The fib_table_lookup function had a shift by 32 that triggered a UBSAN
warning. This was due to the fact that I had placed the shift first and
then followed it with the check for the suffix length to ignore the
undefined behavior. If we reorder this so that we verify the suffix is
less than 32 before shifting the value we can avoid the issue.
Reported-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Thu, 28 Jan 2016 16:54:33 +0000 (17:54 +0100)]
net: moxart: use correct accessors for DMA memory
The moxart ethernet driver confuses coherent DMA buffers with
MMIO registers.
moxart_ether.c: In function 'moxart_mac_setup_desc_ring':
moxart_ether.c:146:428: error: passing argument 1 of '__fswab32' makes integer from pointer without a cast [-Werror=int-conversion]
moxart_ether.c:74:39: warning: incorrect type in argument 3 (different address spaces)
moxart_ether.c:74:39: expected void *cpu_addr
moxart_ether.c:74:39: got void [noderef] <asn:2>*tx_desc_base
This leaves the basic logic alone and uses normal pointers for
the virtual address of the descriptor. As we cannot use readl/writel
to access them, we also introduce our own moxart_desc_read
moxart_desc_write helpers that perform the same endianess swap
as the original code, but without the address space conversion.
The barriers are made explicit here where needed: Even in the worst-case
scenario, we just have to use a rmb() after checking ownership so
we don't read any input data before we are sure it is value, and we
use wmb() before transferring ownership back to the device.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Thu, 28 Jan 2016 16:39:24 +0000 (17:39 +0100)]
ipv4: ipconfig: avoid unused ic_proto_used symbol
When CONFIG_PROC_FS, CONFIG_IP_PNP_BOOTP, CONFIG_IP_PNP_DHCP and
CONFIG_IP_PNP_RARP are all disabled, we get a warning about the
ic_proto_used variable being unused:
net/ipv4/ipconfig.c:146:12: error: 'ic_proto_used' defined but not used [-Werror=unused-variable]
This avoids the warning, by making the definition conditional on
whether a dynamic IP configuration protocol is configured. If not,
we know that the value is always zero, so we can optimize away the
variable and all code that depends on it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Chan [Thu, 28 Jan 2016 08:11:22 +0000 (03:11 -0500)]
bnxt_en: Fix crash in bnxt_free_tx_skbs() during tx timeout.
The ring index j is not wrapped properly at the end of the ring, causing
it to reference pointers past the end of the ring. For proper loop
termination and to access the ring properly, we need to increment j and
mask it before referencing the ring entry.
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Chan [Thu, 28 Jan 2016 08:11:21 +0000 (03:11 -0500)]
bnxt_en: Exclude rx_drop_pkts hw counter from the stack's rx_dropped counter.
This hardware counter is misleading as it counts dropped packets that
don't match the hardware filters for unicast/broadcast/multicast. We
will still report this counter in ethtool -S for diagnostics purposes.
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
bnxt_en: Ring free response from close path should use completion ring
Use completion ring for ring free response from firmware. The response
will be the last entry in the ring and we can free the ring after getting
the response. This will guarantee no spurious DMA to freed memory.
Signed-off-by: Prashant Sreedharan <prashant@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bernie Harris [Thu, 28 Jan 2016 03:30:51 +0000 (16:30 +1300)]
net_sched: drr: check for NULL pointer in drr_dequeue
There are cases where qdisc_dequeue_peeked can return NULL, and the result
is dereferenced later on in the function.
Similarly to the other qdisc dequeue functions, check whether the skb
pointer is NULL and if it is, goto out.
Signed-off-by: Bernie Harris <bernie.harris@alliedtelesis.co.nz> Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Kefeng Wang [Thu, 28 Jan 2016 02:27:19 +0000 (10:27 +0800)]
ptp: ixp46x: use helpers for converting ns to timespec
Convert the driver to use ns_to_timespec64() and timespec64_to_ns()
instead of open coding the same logic.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Currently when a macvlan is being initialized and the lower device is
netif_carrier_ok(), the macvlan device doesn't run through
rfc2863_policy() and is left with UNKNOWN operstate. Fix it by adding an
unconditional linkwatch event for the new macvlan device. Similar fix is
already used by the 8021q device (see register_vlan_dev()). Also fix the
inconsistent state when the lower device has been down and its carrier
was changed (when a device is down NETDEV_CHANGE doesn't get generated).
The second issue can be seen f.e. when we have a macvlan on top of a 8021q
device which has been down and its real device has been changing carrier
states, after setting the 8021q device up, the macvlan device will have
the same carrier state as it was before even though the 8021q can now
have a different state.
Example for case 1:
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
$ ip l add l eth2 macvl0 type macvlan
$ ip l set macvl0 up
$ ip l sh macvl0
72: macvl0@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN mode DEFAULT group default
link/ether f6:0b:54:0a:9d:a3 brd ff:ff:ff:ff:ff:ff
Example for case 2 (order is important):
Prestate: eth2 UP/CARRIER, vlan1 down, vlan1-macvlan down
$ ip l set vlan1-macvlan up
$ ip l sh vlan1-macvlan
71: vlan1-macvlan@vlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 4a:b8:44:56:b9:b9 brd ff:ff:ff:ff:ff:ff
[ eth2 loses CARRIER before vlan1 has been UP-ed ]
$ ip l sh eth2
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:57:16 brd ff:ff:ff:ff:ff:ff
$ ip l sh vlan1-macvlan
71: vlan1-macvlan@vlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 4a:b8:44:56:b9:b9 brd ff:ff:ff:ff:ff:ff
$ ip l set vlan1 up
$ ip l sh vlan1
70: vlan1@eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:57:16 brd ff:ff:ff:ff:ff:ff
$ ip l sh vlan1-macvlan
71: vlan1-macvlan@vlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 4a:b8:44:56:b9:b9 brd ff:ff:ff:ff:ff:ff
vlan1-macvlan is still UP, still has carrier and is still in the same
operstate as before. After the patch in case 1 macvl0 has state UP as it
should and in case 2 vlan1-macvlan has state LOWERLAYERDOWN again as it
should. Note that while the lower macvlan device is down their carrier
and thus operstate can go out of sync but that will be fixed once the
lower device goes up again.
This behaviour seems to have been present since beginning of git history.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
tipc: fix connection abort during subscription cancel
In 'commit 7fe8097cef5f ("tipc: fix nullpointer bug when subscribing
to events")', we terminate the connection if the subscription
creation fails.
In the same commit, the subscription creation result was based on
the value of the subscription pointer (set in the function) instead
of the return code.
Unfortunately, the same function tipc_subscrp_create() handles
subscription cancel request. For a subscription cancellation request,
the subscription pointer cannot be set. Thus if a subscriber has
several subscriptions and cancels any of them, the connection is
terminated.
In this commit, we terminate the connection based on the return value
of tipc_subscrp_create(). Fixes: commit 7fe8097cef5f ("tipc: fix nullpointer bug when subscribing to events") Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hedberg [Tue, 26 Jan 2016 19:31:31 +0000 (14:31 -0500)]
Bluetooth: Fix incorrect removing of IRKs
The commit cad20c278085d893ebd616cd20c0747a8e9d53c7 was supposed to
fix handling of devices first using public addresses and then
switching to RPAs after pairing. Unfortunately it missed a couple of
key places in the code.
1. When evaluating which devices should be removed from the existing
white list we also need to consider whether we have an IRK for them or
not, i.e. a call to hci_find_irk_by_addr() is needed.
2. In smp_notify_keys() we should not be requiring the knowledge of
the RPA, but should simply keep the IRK around if the other conditions
require it.
Johan Hedberg [Tue, 26 Jan 2016 22:19:11 +0000 (17:19 -0500)]
Bluetooth: L2CAP: Fix setting chan src info before adding PSM/CID
At least the l2cap_add_psm() routine depends on the source address
type being properly set to know what auto-allocation ranges to use, so
the assignment to l2cap_chan needs to happen before this.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 26 Jan 2016 22:19:09 +0000 (17:19 -0500)]
Bluetooth: L2CAP: Introduce proper defines for PSM ranges
Having proper defines makes the code a bit readable, it also avoids
duplicating hard-coded values since these are also needed when
auto-allocating PSM values (in a subsequent patch).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Andrew Lunn [Thu, 28 Jan 2016 01:30:30 +0000 (02:30 +0100)]
DT: phy.txt: Clarify expected compatible values
PHY devices may only list compatibility with clause 22, 45, and if
they need to be more specific, their PHY identifier values. No other
compatible strings are allowed. Make this clear in the documentation,
and remove examples where make/model compatible strings are listed.
Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew Lunn [Thu, 28 Jan 2016 01:30:29 +0000 (02:30 +0100)]
of: of_mdio: Add a whitelist of PHY compatibilities.
Some phy nodes list a compatible value indicating the PHY make/model.
This is never used to match the device to the driver. However it does
confuse the code to separate a PHY from a generic MDIO device like a
switch. Generic MDIO devices must have a compatible value, PHYs can
list clause 22 or 45, but nothing else.
Issue a warning if we find a compatible value known on the whitelist,
and say it is a PHY.
Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.") Reported-by: Aaro Koskinen <aaro.koskinen@nokia.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 29 Jan 2016 06:51:44 +0000 (22:51 -0800)]
Merge branch 'lan78xx-fixes'
Woojung Huh says:
====================
lan78xx: update and fixes
lan78xx: change to use updated phy-ignore-interrupts
lan78xx: Add to handle mux control per chip id
lan78xx: throttle TX path at slower than SuperSpeed USB
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Wed, 27 Jan 2016 18:52:43 +0000 (10:52 -0800)]
tcp: beware of alignments in tcp_get_info()
With some combinations of user provided flags in netlink command,
it is possible to call tcp_get_info() with a buffer that is not 8-bytes
aligned.
It does matter on some arches, so we need to use put_unaligned() to
store the u64 fields.
Current iproute2 package does not trigger this particular issue.
Fixes: 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info") Fixes: 977cb0ecf82e ("tcp: add pacing_rate information into tcp_info") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:16:43 +0000 (15:16 +0100)]
switchdev: Require RTNL mutex to be held when sending FDB notifications
When switchdev drivers process FDB notifications from the underlying
device they resolve the netdev to which the entry points to and notify
the bridge using the switchdev notifier.
However, since the RTNL mutex is not held there is nothing preventing
the netdev from disappearing in the middle, which will cause
br_switchdev_event() to dereference a non-existing netdev.
Make switchdev drivers hold the lock at the beginning of the
notification processing session and release it once it ends, after
notifying the bridge.
Also, remove switchdev_mutex and fdb_lock, as they are no longer needed
when RTNL mutex is held.
Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Malcolm Crossley [Tue, 26 Jan 2016 17:12:44 +0000 (17:12 +0000)]
xen-netfront: request Tx response events more often
Trying to batch Tx response events results in poor performance because
this delays freeing the transmitted skbs.
Instead use the standard RING_FINAL_CHECK_FOR_RESPONSES() macro to be
notified once the next Tx response is placed on the ring.
Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Nicolas Schichan [Tue, 26 Jan 2016 15:12:35 +0000 (16:12 +0100)]
net: mv643xx_eth: fix packet corruption with TSO and tiny unaligned packets.
The code in txq_put_data() would use txq->tx_curr_desc to index the
tso_hdrs/tso_hdrs_dma buffers, for less than 8 bytes unaligned
fragments, which is already moved to the next descriptor at the
beginning of the function.
If that fragment was the last of the the skb, the next skb would use
that same space to place the ip headers, overwritting that small
fragment data.
Fixes: 91986fd3d335 (net: mv643xx_eth: Ensure proper data alignment in TSO TX path) Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Reviewed-by: Philipp Kirchhofer <philipp@familie-kirchhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew Lunn [Tue, 26 Jan 2016 14:12:30 +0000 (15:12 +0100)]
of: of_mdio: Ensure mdio device is a PHY
of_phy_find_device() is used to find the phy device associated with a
device node. It is expected the node is for a PHY device, but in fact
it could of been probed as a generic MDIO device. Ensure the device is
a PHY before returning it.
Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.") Reported-by: Aaro Koskinen <aaro.koskinen@nokia.com> Reported-by: Olof Johansson <olof@lixom.net> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 29 Jan 2016 00:05:45 +0000 (16:05 -0800)]
Merge tag 'mac80211-for-davem-2016-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Here's a first set of fixes for the 4.5-rc cycle:
* make regulatory messages much less verbose by default
* various remain-on-channel fixes
* scheduled scanning fixes with hardware restart
* a PS-Poll handling fix; was broken just recently
* bugfix to avoid buffering non-bufferable MMPDUs
* world regulatory domain data fix
* a fix for scanning causing other work to get stuck
* hwsim: revert an older problematic patch that caused some
userspace tools to have issues - not that big a deal as
it's a debug only driver though
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Neal Cardwell [Mon, 25 Jan 2016 22:01:53 +0000 (14:01 -0800)]
tcp: fix tcp_mark_head_lost to check skb len before fragmenting
This commit fixes a corner case in tcp_mark_head_lost() which was
causing the WARN_ON(len > skb->len) in tcp_fragment() to fire.
tcp_mark_head_lost() was assuming that if a packet has
tcp_skb_pcount(skb) of N, then it's safe to fragment off a prefix of
M*mss bytes, for any M < N. But with the tricky way TCP pcounts are
maintained, this is not always true.
For example, suppose the sender sends 4 1-byte packets and have the
last 3 packet sacked. It will merge the last 3 packets in the write
queue into an skb with pcount = 3 and len = 3 bytes. If another
recovery happens after a sack reneging event, tcp_mark_head_lost()
may attempt to split the skb assuming it has more than 2*MSS bytes.
This sounds very counterintuitive, but as the commit description for
the related commit c0638c247f55 ("tcp: don't fragment SACKed skbs in
tcp_mark_head_lost()") notes, this is because tcp_shifted_skb()
coalesces adjacent regions of SACKed skbs, and when doing this it
preserves the sum of their packet counts in order to reflect the
real-world dynamics on the wire. The c0638c247f55 commit tried to
avoid problems by not fragmenting SACKed skbs, since SACKed skbs are
where the non-proportionality between pcount and skb->len/mss is known
to be possible. However, that commit did not handle the case where
during a reneging event one of these weird SACKed skbs becomes an
un-SACKed skb, which tcp_mark_head_lost() can then try to fragment.
The fix is to simply mark the entire skb lost when this happens.
This makes the recovery slightly more aggressive in such corner
cases before we detect reordering. But once we detect reordering
this code path is by-passed because FACK is disabled.
Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Joe Stringer [Fri, 22 Jan 2016 23:49:12 +0000 (15:49 -0800)]
inet: frag: Always orphan skbs inside ip_defrag()
Later parts of the stack (including fragmentation) expect that there is
never a socket attached to frag in a frag_list, however this invariant
was not enforced on all defrag paths. This could lead to the
BUG_ON(skb->sk) during ip_do_fragment(), as per the call stack at the
end of this commit message.
While the call could be added to openvswitch to fix this particular
error, the head and tail of the frags list are already orphaned
indirectly inside ip_defrag(), so it seems like the remaining fragments
should all be orphaned in all circumstances.
Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action") Signed-off-by: Joe Stringer <joe@ovn.org> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Thu, 28 Jan 2016 23:59:33 +0000 (15:59 -0800)]
Merge branch 'sctp-transport-races'
Xin Long says:
====================
fix the transport dead race check by using atomic_add_unless on refcnt
sctp: fix the transport dead race check by using atomic_add_unless on
refcnt
sctp: hold transport before we access t->asoc in sctp proc
sctp: remove the dead field of sctp_transport
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Thu, 21 Jan 2016 17:49:09 +0000 (01:49 +0800)]
sctp: remove the dead field of sctp_transport
After we use refcnt to check if transport is alive, the dead can be
removed from sctp_transport.
The traversal of transport_addr_list in procfs dump is using
list_for_each_entry_rcu, no need to check if it has been freed.
sctp_generate_t3_rtx_event and sctp_generate_heartbeat_event is
protected by sock lock, it's not necessary to check dead, either.
also, the timers are cancelled when sctp_transport_free() is
called, that it doesn't wait for refcnt to reach 0 to cancel them.
Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Thu, 21 Jan 2016 17:49:08 +0000 (01:49 +0800)]
sctp: hold transport before we access t->asoc in sctp proc
Previously, before rhashtable, /proc assoc listing was done by
read-locking the entire hash entry and dumping all assocs at once, so we
were sure that the assoc wasn't freed because it wouldn't be possible to
remove it from the hash meanwhile.
Now we use rhashtable to list transports, and dump entries one by one.
That is, now we have to check if the assoc is still a good one, as the
transport we got may be being freed.
Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Thu, 21 Jan 2016 17:49:07 +0000 (01:49 +0800)]
sctp: fix the transport dead race check by using atomic_add_unless on refcnt
Now when __sctp_lookup_association is running in BH, it will try to
check if t->dead is set, but meanwhile other CPUs may be freeing this
transport and this assoc and if it happens that
__sctp_lookup_association checked t->dead a bit too early, it may think
that the association is still good while it was already freed.
So we fix this race by using atomic_add_unless in sctp_transport_hold.
After we get one transport from hashtable, we will hold it only when
this transport's refcnt is not 0, so that we can make sure t->asoc
cannot be freed before we hold the asoc again.
Note that sctp association is not freed using RCU so we can't use
atomic_add_unless() with it as it may just be too late for that either.
Fixes: 4f0087812648 ("sctp: apply rhashtable api to send/recv path") Reported-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:26 +0000 (15:20 +0100)]
mlxsw: reg: Use correct offset in field definiton
The rx_lane, tx_lane and module fields in the PMLP register don't have
an additional offset besides the base one (0x04), so set it to 0x00.
Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:25 +0000 (15:20 +0100)]
mlxsw: spectrum: Compare local ports instead of pointers
When dumping the FDB we can't compare the actual pointers of the ports
structs, as it's possible the struct represents a vPort instead of the
underlying physical port.
Solve this by comparing the local port number instead, as it's shared
between the physical ports and all the vPorts on top of him.
Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:24 +0000 (15:20 +0100)]
mlxsw: spectrum: Dump LAG FDB records only once
LAG FDB records can only point to LAG devices or VLAN devices configured
on top of them. Therefore, when dumping the FDB we shouldn't associate
these records with the underlying physical ports.
Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:22 +0000 (15:20 +0100)]
mlxsw: spectrum: Don't report VLAN for 802.1D FDB entries
When dumping the hardware FDB we should report entries pointing to VLAN
devices with VLAN 0, as packets coming into the bridge are untagged.
Likewise, pass FDB_{ADD,DEL} notifications with VLAN 0 for these
devices.
Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:21 +0000 (15:20 +0100)]
mlxsw: spectrum: Notify bridge's FDB only based on learning_sync
When we disable learning on bridge port we should still update the
software bridge's FDB when entry pointing to this bridge port is
aged-out. We can otherwise have an inconsistency between software and
hardware tables.
Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:20 +0000 (15:20 +0100)]
mlxsw: spectrum: Disable learning according to STP state
When port is put into LISTENING state it shouldn't populate the FDB, so
set the port's STP state in hardware to DISCARDING instead of LEARNING.
It will therefore keep listening to BPDU packets, but discard other
non-control packets and won't perform any learning.
Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:19 +0000 (15:20 +0100)]
mlxsw: spectrum: Don't forward packets when STP state is DISABLED
When STP state is set to DISABLED the port is assumed to be inactive, but
currently we forward packets ingressing through it.
Instead, set the port's STP state in hardware to DISCARDING, which means
it doesn't forward packets or perform any learning, but it does trap
control packets. However, these packets will be dropped by bridge code,
which results in the expected behavior.
Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:18 +0000 (15:20 +0100)]
mlxsw: spectrum: Flush FDB when leaving bridge
As explained in previous commit, we should always take care of flushing
the FDB in the driver and not rely on bridge code.
We need to distinguish between two cases with regards to LAG:
1) Port is leaving LAG while LAG is bridged (or VLAN devices on top of
it). In this case don't flush the FDB entries pointing to the LAG ID, as
this will affect other ports still member in the LAG. Only flush the FDB
when the last port in the LAG is leaving the bridge.
2) LAG device is leaving the bridge. In this case the CHANGEUPPER event
is simply propagated to each member port, so make each port flush the
FDB in its turn.
Note that emptying a bridged LAG from ports creates an inconsistency
between hardware and software. A user who later (< ageing_time)
re-populates the LAG won't have any FDB entries pointing to the LAG ID
in hardware, but they will be present in the software bridge's FDB.
Currently there is no good solution to this problem, but this will be
addressed by us in the future.
In order to optimize the flushing process, flush by port or LAG ID if
there are no VLAN interfaces on top of the port. Otherwise, flush using
(Port / LAG ID, FID=VID} for each of the lower 4K FIDs. In the case of
VLAN device simply flush using {Port / LAG ID, vFID} with the vFID to
which the VLAN device is mapped to.
Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:17 +0000 (15:20 +0100)]
mlxsw: reg: Add the Switch Filtering DB Flush register
When removing a net device from a bridge we should flush the FDB entries
associated with this net device. Up until now, we relied upon bridge
code to do that for us, but it is possible for user to prevent hardware
from syncing with the software bridge (learning_sync=0), so we need to
flush overselves.
Add the Switch Filtering DB Flush (SFDF) register that is used to flush
FDB entries according to different parameters (per-port, per-FID etc).
Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 27 Jan 2016 14:20:16 +0000 (15:20 +0100)]
mlxsw: spectrum: Handle port leaving LAG while bridged
It is possible for a user to remove a port from a LAG device, while the
LAG device or VLAN devices on top of it are bridged. In these cases,
bridge's teardown sequence is never issued, so we need to take care of
it ourselves.
When LAG's unlinking event is received by port netdev:
1) Traverse its vPorts list and make those member in a bridge leave it.
They will be deleted later by LAG code.
2) Make the port netdev itself leave its bridge if member in one.
Fixes: 0d65fc13042f ("mlxsw: spectrum: Implement LAG port join/leave") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Kalle Valo [Wed, 27 Jan 2016 12:19:18 +0000 (14:19 +0200)]
Merge tag 'iwlwifi-for-kalle-2016-01-26_2' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
* Fix support for 3168 device
+ NVM version
+ firmware file name
+ device IDs
* Fix a compilation warning in dvm calibration code
* Fix the TPC (reduced Tx Power) code. This fixes performance issues
* Device IDs for 8265
Gregory Greenman [Tue, 29 Dec 2015 09:26:35 +0000 (11:26 +0200)]
iwlwifi: mvm: rs: fix TPC statistics handling
FW behaviour changed and now updates driver about the used TPC
reduction in the following cases:
1. In tx response, which is used mostly for a single frame case
2. In BA notification
When tx aggregation fails with the initial rate, FW will send
to the driver BA notification and will try to transmit with the
next rate, but this time without tx power reduction. Thus, in case
of a failure with the initial rate, driver will get two BA notifications,
the first one with reduced tx power as in the LQ command and the second
one with 0 power reduction.
This patch adapts the TPC statistics according to the description above:
1. Use BA notifications instead of Tx response
2. For TPC only, drop the optimization which considers empty BA as one
MPDU. The reason is that with TPC we want to recover very quickly from
a bad power reduction and, therefore we'd like the success ratio to get
an immediate hit when failing to get a BA, so we'd switch back to a
lower or zero power reduction
Oren Givon [Thu, 14 Jan 2016 08:24:10 +0000 (10:24 +0200)]
iwlwifi: update support for 3168 series firmware and NVM
Update the struct which defines the support for 3168 cards.
Now it will search for a firmware of this format:
iwlwifi-3168-XX.ucode
Also, set the minimum version of the ucode to 20.
Update the minimum NVM version and minimum NVM calibrations
version of the 3168 series.
Johannes Berg [Tue, 26 Jan 2016 10:29:03 +0000 (11:29 +0100)]
rfkill: fix rfkill_fop_read wait_event usage
The code within wait_event_interruptible() is called with
!TASK_RUNNING, so mustn't call any functions that can sleep,
like mutex_lock().
Since we re-check the list_empty() in a loop after the wait,
it's safe to simply use list_empty() without locking.
This bug has existed forever, but was only discovered now
because all userspace implementations, including the default
'rfkill' tool, use poll() or select() to get a readable fd
before attempting to read.
Sachin Kulkarni [Tue, 12 Jan 2016 09:00:19 +0000 (14:30 +0530)]
mac80211: Requeue work after scan complete for all VIF types.
During a sw scan ieee80211_iface_work ignores work items for all vifs.
However after the scan complete work is requeued only for STA, ADHOC
and MESH iftypes.
This occasionally results in event processing getting delayed/not
processed for iftype AP when it coexists with a STA. This can result
in data halt and eventually disconnection on the AP interface.
Cc: stable@vger.kernel.org Signed-off-by: Sachin Kulkarni <Sachin.Kulkarni@imgtec.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Arnd Bergmann [Thu, 21 Jan 2016 03:53:17 +0000 (19:53 -0800)]
net: i40e: shut up uninitialized variable warnings
intel/i40e/i40e_txrx.c: In function 'i40e_xmit_frame_ring':
intel/i40e/i40e_txrx.c:2367:20: error: 'oiph' may be used uninitialized in this function [-Werror=maybe-uninitialized]
intel/i40e/i40e_txrx.c:2317:16: note: 'oiph' was declared here
intel/i40e/i40e_txrx.c:2367:17: error: 'oudph' may be used uninitialized in this function [-Werror=maybe-uninitialized]
intel/i40e/i40e_txrx.c:2316:17: note: 'oudph' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Eric Dumazet [Thu, 21 Jan 2016 03:53:02 +0000 (19:53 -0800)]
i40e: fix build warnings
Fixes following build warnings :
drivers/net/ethernet/intel/i40e/i40e_main.c:7057:13: warning:
'i40e_sync_udp_filters_subtask' defined but not used [-Wunused-function]
drivers/net/ethernet/intel/i40e/i40e_main.c:8524:13: warning:
'i40e_add_vxlan_port' defined but not used [-Wunused-function]
drivers/net/ethernet/intel/i40e/i40e_main.c:8569:13: warning:
'i40e_del_vxlan_port' defined but not used [-Wunused-function]
drivers/net/ethernet/intel/i40e/i40e_main.c:8604:13: warning:
'i40e_add_geneve_port' defined but not used [-Wunused-function]
drivers/net/ethernet/intel/i40e/i40e_main.c:8651:13: warning:
'i40e_del_geneve_port' defined but not used [-Wunused-function]
Fixes: 6a899024058d ("i40e: geneve tunnel offload support") Signed-off-by: Eric Dumazet <edumazet@google.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Haiyang Zhang [Mon, 25 Jan 2016 17:49:31 +0000 (09:49 -0800)]
hv_netvsc: Fix book keeping of skb during batching process
Since eliminating send_completion_tid from struct hv_netvsc_packet, we
haven't add proper book keeping for the skb of the batched packet. This
patch fixes this issue and allows the previous skb is properly freed.
Otherwise, a panic may happen.
Thanks to Simon Xiao <sixiao@microsoft.com> for bisecting and analysis.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Vitaly Kuznetsov [Mon, 25 Jan 2016 15:00:41 +0000 (16:00 +0100)]
hv_netvsc: use skb_get_hash() instead of a homegrown implementation
Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
VLAN ID to flow_keys")) introduced a performance regression in netvsc
driver. Is problem is, however, not the above mentioned commit but the
fact that netvsc_set_hash() function did some assumptions on the struct
flow_keys data layout and this is wrong.
Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change
will also imply switching to Jenkins hash from the currently used Toeplitz
but it seems there is no good excuse for Toeplitz to stay.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
sit: set rtnl_link_ops before calling register_netdevice
When creating a SIT tunnel with ip tunnel, rtnl_link_ops is not set before
ipip6_tunnel_create is called. When register_netdevice is called, there is
no linkinfo attribute in the NEWLINK message because of that.
Setting rtnl_link_ops before calling register_netdevice fixes that.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johannes Berg [Mon, 25 Jan 2016 10:40:50 +0000 (11:40 +0100)]
net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28
As Arnd Bergmann points out, using CONFIG_ARCH_MXC and/or SOC_IMX28
is wrong if some other ARM platform uses this device - the operation
of the driver would depend on an unrelated ARM platform that might
or might not be set for multi-platform kernels.
Prior to my previous patch, any other platforms using it would have
been broken already due to having the cbd_datlen/cbd_sc fields in
the wrong order, but byte ordering correctly, so no such platforms
can exist and work today.
In any case, it seems likely that only Freescale SoCs use this part,
and those are little-endian on ARM, so CONFIG_ARM is safe for them.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Sudip Mukherjee [Mon, 25 Jan 2016 07:35:20 +0000 (13:05 +0530)]
defxx: fix build warning
We are getting many build warnings about:
'bar_start' may be used uninitialized
and
'bar_len' may be used uninitialized
They are not actually uninitialized as dfx_get_bars() will initialize
them properly. But still lets have them initialized just to satisfy the
compiler (gcc 4.8.2).
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Acked-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sudip Mukherjee [Mon, 25 Jan 2016 06:13:09 +0000 (11:43 +0530)]
net: macb: fix build warning
We are getting build warning about:
macb.c:2889:13: warning: 'tx_clk' may be used uninitialized in this function
macb.c:2888:11: warning: 'hclk' may be used uninitialized in this function
In reality they are not used uninitialized as clk_init() will initialize
them, this patch will just silence the warning.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johannes Berg [Sun, 24 Jan 2016 15:52:37 +0000 (16:52 +0100)]
net: fec: make driver endian-safe
The driver treats the device descriptors as CPU-endian, which appears
to be correct with the default endianness on both ARM (typically LE)
and PowerPC (typically BE) SoCs, indicating that the hardware block
is generated differently. Add endianness annotations and byteswaps as
necessary.
It's not clear that the ifdef there really is correct and shouldn't
just be #ifdef CONFIG_ARM, but I also can't test on anything but the
i.MX6 HummingBoard where this gets it working with a BE kernel.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King [Sun, 24 Jan 2016 09:22:05 +0000 (09:22 +0000)]
net: dsa: fix mv88e6xxx switches
Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del
ops"), the Marvell 88E6xxx switch has been unable to pass traffic
between ports - any received traffic is discarded by the switch.
Taking a port out of bridge mode and configuring a vlan on it also the
port to start passing traffic.
With the debugfs files re-instated to allow debug of this issue by
comparing the register settings between the working and non-working
case, the reason becomes clear:
Register 7 for the ports is the default vlan tag register, and in the
non-working setup, it has been set to 2, despite vlan 2 not being
configured. This causes the switch to drop all packets coming in to
these ports. The working setup has the default vlan tag register set
to 1, which is the default vlan when none is configured.
Inspection of the code reveals why. The code prior to this commit
was:
- for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
- if (!err && vlan->flags & BRIDGE_VLAN_INFO_PVID)
- err = ds->drv->port_pvid_set(ds, p->port, vid);
but the new code is:
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
+ }
...
+ if (pvid)
+ err = _mv88e6xxx_port_pvid_set(ds, port, vid);
This causes the new code to always set the default vlan to one higher
than the old code.
Fix this.
Fixes: 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops") Cc: <stable@vger.kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Martin Roth [Sat, 23 Jan 2016 22:56:19 +0000 (00:56 +0200)]
82xx: FCC: Fixing a bug causing to FCC port lock-up (second try)
This is an additional patch to the one already submitted recently.
The previous patch was not complete, and the FCC port lock-up scenario
has been reproduced in lab.
I had an opportunity to check the current patch in lab and the FCC
port lock no longer freezes, while the previous patch still locks-up the
FCC port.
The current patch fixes a pointer arithmetic bug (second bug in the same
line), which leads FCC port lock-up during underrun/collision handling.
Within the tx_startup() function in mac-fcc.c, the address of last BD is
not calculated correctly. As a result of wrong calculation of the last BD
address, the next transmitted BD may be set to an area out of the transmit
BD ring. This actually causes to port lock-up and it is not recoverable.
Signed-off-by: Martin Roth <martin.roth@motorolasolutions.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Thomas Egerer [Mon, 25 Jan 2016 11:58:44 +0000 (12:58 +0100)]
ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV
The ESP algorithms using CBC mode require echainiv. Hence INET*_ESP have
to select CRYPTO_ECHAINIV in order to work properly. This solves the
issues caused by a misconfiguration as described in [1].
The original approach, patching crypto/Kconfig was turned down by
Herbert Xu [2].
Signed-off-by: Thomas Egerer <hakke_007@gmx.de> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Felix Fietkau [Thu, 21 Jan 2016 15:34:08 +0000 (16:34 +0100)]
ath9k_hw: ignore eeprom magic mismatch on flash based devices
Many AR913x based devices (maybe others too) do not have a valid EEPROM
magic in their calibration data partition.
Fixes: 6fa658fd5ab2 ("ath9k: Simplify and fix eeprom endianness swapping") Signed-off-by: Felix Fietkau <nbd@openwrt.org> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Larry Finger [Thu, 21 Jan 2016 03:58:39 +0000 (21:58 -0600)]
rtlwifi: rtl8821ae: Fix 5G failure when EEPROM is incorrectly encoded
Recently, it has been reported that D-Link DWA-582 cards, which use an
RTL8812AE chip are not able to scan for 5G networks. The problems started
with kernel 4.2, which is the first version that had commit d10101a60372
("rtlwifi: rtl8821ae: Fix problem with regulatory information"). With this
patch, the driver went from setting a default channel plan to using
the value derived from EEPROM.
Bug reports at https://bugzilla.kernel.org/show_bug.cgi?id=111031 and
https://bugzilla.redhat.com/show_bug.cgi?id=1279653 are examples of this
problem.
The problem was solved once I learned that the internal country code was
resulting in a regulatory set with only 2.4 GHz channels. With the RTL8821AE
chips available to me, the country code was such that both 2.4 and 5 GHz
channels are allowed. The fix is to allow both bands even when the EEPROM
is incorrectly encoded.
Fixes: d10101a60372 ("rtlwifi: rtl8821ae: Fix problem with regulatory information") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: littlesmartguy@gmail.com Cc: gabe@codehaus.org Cc: Stable <stable@vger.kernel.org> [v4.2+] Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Eli Cooper [Mon, 18 Jan 2016 11:30:19 +0000 (19:30 +0800)]
rt2x00: fix monitor mode regression
Since commit df1404650ccb ("mac80211: remove support for IFF_PROMISC")
monitor mode for rt2x00 has been made effectively useless because the
hardware filter is configured to drop packets whose intended recipient is
not the device, regardless of the presence of monitor mode interfaces.
This patch fixes this regression by adding explicit monitor mode support,
and by configuring the hardware filter accordingly.
Signed-off-by: Eli Cooper <elicooper@gmx.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
sctp: allow setting SCTP_SACK_IMMEDIATELY by the application
This patch extends commit b93d6471748d ("sctp: implement the sender side
for SACK-IMMEDIATELY extension") as it didn't white list
SCTP_SACK_IMMEDIATELY on sctp_msghdr_parse(), causing it to be
understood as an invalid flag and returning -EINVAL to the application.
Note that the actual handling of the flag is already there in
sctp_datamsg_from_user().
https://tools.ietf.org/html/rfc7053#section-7
Fixes: b93d6471748d ("sctp: implement the sender side for SACK-IMMEDIATELY extension") Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Fri, 22 Jan 2016 10:43:44 +0000 (11:43 +0100)]
net: simplify napi_synchronize() to avoid warnings
The napi_synchronize() function is defined twice: The definition
for SMP builds waits for other CPUs to be done, while the uniprocessor
variant just contains a barrier and ignores its argument.
In the mvneta driver, this leads to a warning about an unused variable
when we lookup the NAPI struct of another CPU and then don't use it:
ethernet/marvell/mvneta.c: In function 'mvneta_percpu_notifier':
ethernet/marvell/mvneta.c:2910:30: error: unused variable 'other_port' [-Werror=unused-variable]
There are no other CPUs on a UP build, so that code never runs, but
gcc does not know this.
The nicest solution seems to be to turn the napi_synchronize() helper
into an inline function for the UP case as well, as that leads gcc to
not complain about the argument being unused. Once we do that, we can
also combine the two cases into a single function definition and use
if(IS_ENABLED()) rather than #ifdef to make it look a bit nicer.
The warning first came up in linux-4.4, but I failed to catch it
earlier.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: f86428854480 ("net: mvneta: Statically assign queues to CPUs") Signed-off-by: David S. Miller <davem@davemloft.net>
projects / linux-beck.git / log