summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-04-01udp: use sk_protocol instead of pcflag to detect udplite socketsPaolo Abeni
In the udp_sock struct, the 'forward_deficit' and 'pcflag' fields share the same cacheline. While the first is dirtied by udp_recvmsg, the latter is read, possibly several times, by the bottom half processing to discriminate between udp and udplite sockets. With this patch, sk->sk_protocol is used to check is the socket is really an udplite one, avoiding some cache misses per packet and improving the performance under udp_flood with small packet up to 10%. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge branch 'parisc-4.11-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "Al Viro reported that - in case of read faults - our copy_from_user() implementation may claim to have copied more bytes than it actually did. In order to fix this bug and because of the way how gcc optimizes register usage for inline assembly in C code, we had to replace our pa_memcpy() function with a pure assembler implementation. While fixing the memcpy bug we noticed some other issues with our get_user() and put_user() functions, e.g. nested faults may return wrong data. This is now fixed by a common fixup handler for get_user/put_user in the exception handler which additionally makes generated code smaller and faster. The third patch is a trivial one-line fix for a patch which went in during 4.11-rc and which avoids stalled CPU warnings after power shutdown (for parisc machines which can't plug power off themselves). Due to the rewrite of pa_memcpy() into assembly this patch got bigger than what I wanted to have sent at this stage. Those patches have been running in production during the last few days on our debian build servers without any further issues" * 'parisc-4.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Avoid stalled CPU warnings after system shutdown parisc: Clean up fixup routines for get_user()/put_user() parisc: Fix access fault handling in pa_memcpy()
2017-04-01net: dsa: fix build error with devlink build as moduleTobias Regnery
After commit 96567d5dacf4 ("net: dsa: dsa2: Add basic support of devlink") I see the following link error with CONFIG_NET_DSA=y and CONFIG_NET_DEVLINK=m: net/built-in.o: In function 'dsa_register_switch': (.text+0xe226b): undefined reference to `devlink_alloc' net/built-in.o: In function 'dsa_register_switch': (.text+0xe2284): undefined reference to `devlink_register' net/built-in.o: In function 'dsa_register_switch': (.text+0xe243e): undefined reference to `devlink_port_register' net/built-in.o: In function 'dsa_register_switch': (.text+0xe24e1): undefined reference to `devlink_port_register' net/built-in.o: In function 'dsa_register_switch': (.text+0xe24fa): undefined reference to `devlink_port_type_eth_set' net/built-in.o: In function 'dsa_dst_unapply.part.8': dsa2.c:(.text.unlikely+0x345): undefined reference to 'devlink_port_unregister' dsa2.c:(.text.unlikely+0x36c): undefined reference to 'devlink_port_unregister' dsa2.c:(.text.unlikely+0x38e): undefined reference to 'devlink_port_unregister' dsa2.c:(.text.unlikely+0x3f2): undefined reference to 'devlink_unregister' dsa2.c:(.text.unlikely+0x3fb): undefined reference to 'devlink_free' Fix this by adding a dependency on MAY_USE_DEVLINK so that CONFIG_NET_DSA get switched to be build as module when CONFIG_NET_DEVLINK=m. Fixes: 96567d5dacf4 ("net: dsa: dsa2: Add basic support of devlink") Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Thirteen small fixes: The hopefully final effort to get the lpfc nvme kconfig problems sorted, there's one important sg fix (user can induce read after end of buffer) and one minor enhancement (adding an extra PCI ID to qedi). The rest are a set of minor fixes, which mostly occur as user visible in error legs or on specific devices" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: remove the duplicated checking for supporting clkscaling scsi: lpfc: fix building without debugfs support scsi: lpfc: Fix PT2PT PRLI reject scsi: hpsa: fix volume offline state scsi: libsas: fix ata xfer length scsi: scsi_dh_alua: Warn if the first argument of alua_rtpg_queue() is NULL scsi: scsi_dh_alua: Ensure that alua_activate() calls the completion function scsi: scsi_dh_alua: Check scsi_device_get() return value scsi: sg: check length passed to SG_NEXT_CMD_LEN scsi: ufshcd-platform: remove the useless cast in ERR_PTR/IS_ERR scsi: qedi: Add PCI device-ID for QL41xxx adapters. scsi: aacraid: Fix potential null access scsi: qla2xxx: Fix crash in qla2xxx_eh_abort on bad ptr
2017-04-01Merge branch 'phylib-EEE-updates'David S. Miller
Russell King says: ==================== phylib EEE updates This series of patches depends on the previous set of changes, and is therefore net-next material. While testing the EEE code, I discovered a number of issues: 1. It is possible to enable advertisment of EEE modes which are not supported by the hardware. We omit to check the supported modes and mask off those modes that are not supported before writing the EEE advertisment register. 2. We need to restart autonegotiation after a change of the EEE advertisment, otherwise the link partner does not see the updated EEE modes. 3. SGMII connected PHYs are also capable of supporting EEE. Through discussion with Florian, it has been decided to remove the check for the PHY interface mode in patch (3). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: phy: allow EEE with any interface modeRussell King
EEE is able to work in any PHY interface mode, there is nothing which fundamentally restricts it to only a few modes. For example, EEE works in SGMII mode with the Marvell 88E1512. Rather than just adding SGMII mode to the list, Florian suggests removing the list of interface modes entirely: It actually sounds like we should just kill the check entirely, it does not appear that any of the interface mode would not fundamentally be able to support EEE, because the "lowest" mode we support is MII, and even there it's quite possible to support EEE. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: phy: restart phy autonegotiation after EEE advertisment changeRussell King
When the EEE advertisment is changed, we should restart autonegotiation to update the link partner with the new EEE settings. Add this trigger but only if the advertisment has changed. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: phy: avoid setting unsupported EEE advertismentsRussell King
We currently allow userspace to set any EEE advertisments it desires, whether or not the PHY supports them. For example: # ethtool --set-eee eth1 advertise 0xffffffff # ethtool --show-eee eth1 EEE Settings for eth1: EEE status: disabled Tx LPI: disabled Supported EEE link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full 1000baseKX/Full 10000baseT/Full 10000baseKX4/Full 10000baseKR/Full Clearly, this is not sane, we should only allow link modes that are supported to be advertised (as we do elsewhere.) Ensure that we mask the MDIO_AN_EEE_ADV value with the capabilities retrieved from the MDIO_PCS_EEE_ABLE register. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge branch 'akpm' (patches from Andrew)Linus Torvalds
Merge misc fixes from Andrew Morton: "11 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: kasan: do not sanitize kexec purgatory drivers/rapidio/devices/tsi721.c: make module parameter variable name unique mm/hugetlb.c: don't call region_abort if region_chg fails kasan: report only the first error by default hugetlbfs: initialize shared policy as part of inode allocation mm: fix section name for .data..ro_after_init mm, hugetlb: use pte_present() instead of pmd_present() in follow_huge_pmd() mm: workingset: fix premature shadow node shrinking with cgroups mm: rmap: fix huge file mmap accounting in the memcg stats mm: move mm_percpu_wq initialization earlier mm: migrate: fix remove_migration_pte() for ksm pages
2017-04-01Merge tag 'mac80211-for-davem-2017-03-31' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Two fixes: * don't block netdev queues (indefinitely!) if mac80211 manages traffic queueing itself * check wiphy registration before checking for ops on resume, to avoid crash ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge branch 'bpf-prog-testing-framework'David S. Miller
Alexei Starovoitov says: ==================== bpf: program testing framework Development and testing of networking bpf programs is quite cumbersome. Especially tricky are XDP programs that attach to real netdevices and program development feels like working on the car engine while the car is in motion. Another problem is ongoing changes to upstream llvm core that can introduce an optimization that verifier will not recognize. llvm bpf backend tests have no ability to run the programs. To improve this situation introduce BPF_PROG_TEST_RUN command to test and performance benchmark bpf programs. It achieves several goals: - development of xdp and skb based bpf programs can be done in a canned environment with unit tests - program performance optimizations can be benchmarked outside of networking core (without driver and skb costs) - continuous testing of upstream changes is finally practical Patches 4,5,6 add C based test cases of various complexity to cover some sched_cls and xdp features. More tests will be added in the future. The tests were run on centos7 only. For now the framework supports only skb and xdp programs. In the future it can be extended to socket_filter and tracing program types. More details are in individual patches. v1->v2: - rename bpf_program_test_run->bpf_prog_test_run - add missing #include <linux/bpf.h> since libbpf.h shouldn't depend on prior includes - reordered patches 3 and 4 to keep bisect clean ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01selftests/bpf: add l4 load balancer test based on sched_clsAlexei Starovoitov
this l4lb demo is a comprehensive test case for LLVM codegen and kernel verifier. It's using fully inlined jhash(), complex packet parsing and multiple map lookups of different types to stress llvm and verifier. The map sizes, map population and test vectors are artificial to exercise different paths through the bpf program. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01selftests/bpf: add a test for basic XDP functionalityAlexei Starovoitov
add C test for xdp_adjust_head(), packet rewrite and map lookups Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01selftests/bpf: add a test for overlapping packet range checksAlexei Starovoitov
add simple C test case for llvm and verifier range check fix from commit b1977682a385 ("bpf: improve verifier packet range checks") Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01tools/lib/bpf: expose bpf_program__set_type()Alexei Starovoitov
expose bpf_program__set_type() to set program type Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01tools/lib/bpf: add support for BPF_PROG_TEST_RUN commandAlexei Starovoitov
add support for BPF_PROG_TEST_RUN command to libbpf.a Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Wang Nan <wangnan0@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01bpf: introduce BPF_PROG_TEST_RUN commandAlexei Starovoitov
development and testing of networking bpf programs is quite cumbersome. Despite availability of user space bpf interpreters the kernel is the ultimate authority and execution environment. Current test frameworks for TC include creation of netns, veth, qdiscs and use of various packet generators just to test functionality of a bpf program. XDP testing is even more complicated, since qemu needs to be started with gro/gso disabled and precise queue configuration, transferring of xdp program from host into guest, attaching to virtio/eth0 and generating traffic from the host while capturing the results from the guest. Moreover analyzing performance bottlenecks in XDP program is impossible in virtio environment, since cost of running the program is tiny comparing to the overhead of virtio packet processing, so performance testing can only be done on physical nic with another server generating traffic. Furthermore ongoing changes to user space control plane of production applications cannot be run on the test servers leaving bpf programs stubbed out for testing. Last but not least, the upstream llvm changes are validated by the bpf backend testsuite which has no ability to test the code generated. To improve this situation introduce BPF_PROG_TEST_RUN command to test and performance benchmark bpf programs. Joint work with Daniel Borkmann. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: Mock-up driverFlorian Fainelli
This patch adds support for a DSA mock-up driver which essentially does the following: - registers/unregisters 4 fixed PHYs to the slave network devices - uses eth0 (configurable) as the master netdev - registers the switch as a fixed MDIO device against the fixed MDIO bus at address 31 - includes dynamic debug prints for dsa_switch_ops functions that can be enabled to get call traces This is a good way to test modular builds as well as exercise the DSA APIs without requiring access to real hardware. This does not test the data-path, although this could be added later on. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge branch 'bpf-map_value_adj-reg-types-fixes'David S. Miller
Daniel Borkmann says: ==================== BPF fixes on map_value_adj reg types This set adds two fixes for map_value_adj register type in the verifier and user space tests along with them for the BPF self test suite. For details, please see individual patches. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01bpf: add various verifier test cases for self-testsDaniel Borkmann
Add a couple of test cases, for example, probing for xadd on a spilled pointer to packet and map_value_adj register, various other map_value_adj tests including the unaligned load/store, and trying out pointer arithmetic on map_value_adj register itself. For the unaligned load/store, we need to figure out whether the architecture has efficient unaligned access and need to mark affected tests accordingly. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01bpf, verifier: fix rejection of unaligned access checks for map_value_adjDaniel Borkmann
Currently, the verifier doesn't reject unaligned access for map_value_adj register types. Commit 484611357c19 ("bpf: allow access into map value arrays") added logic to check_ptr_alignment() extending it from PTR_TO_PACKET to also PTR_TO_MAP_VALUE_ADJ, but for PTR_TO_MAP_VALUE_ADJ no enforcement is in place, because reg->id for PTR_TO_MAP_VALUE_ADJ reg types is never non-zero, meaning, we can cause BPF_H/_W/_DW-based unaligned access for architectures not supporting efficient unaligned access, and thus worst case could raise exceptions on some archs that are unable to correct the unaligned access or perform a different memory access to the actual requested one and such. i) Unaligned load with !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS on r0 (map_value_adj): 0: (bf) r2 = r10 1: (07) r2 += -8 2: (7a) *(u64 *)(r2 +0) = 0 3: (18) r1 = 0x42533a00 5: (85) call bpf_map_lookup_elem#1 6: (15) if r0 == 0x0 goto pc+11 R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp 7: (61) r1 = *(u32 *)(r0 +0) 8: (35) if r1 >= 0xb goto pc+9 R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R1=inv,min_value=0,max_value=10 R10=fp 9: (07) r0 += 3 10: (79) r7 = *(u64 *)(r0 +0) R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R1=inv,min_value=0,max_value=10 R10=fp 11: (79) r7 = *(u64 *)(r0 +2) R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R1=inv,min_value=0,max_value=10 R7=inv R10=fp [...] ii) Unaligned store with !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS on r0 (map_value_adj): 0: (bf) r2 = r10 1: (07) r2 += -8 2: (7a) *(u64 *)(r2 +0) = 0 3: (18) r1 = 0x4df16a00 5: (85) call bpf_map_lookup_elem#1 6: (15) if r0 == 0x0 goto pc+19 R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp 7: (07) r0 += 3 8: (7a) *(u64 *)(r0 +0) = 42 R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp 9: (7a) *(u64 *)(r0 +2) = 43 R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp 10: (7a) *(u64 *)(r0 -2) = 44 R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp [...] For the PTR_TO_PACKET type, reg->id is initially zero when skb->data was fetched, it later receives a reg->id from env->id_gen generator once another register with UNKNOWN_VALUE type was added to it via check_packet_ptr_add(). The purpose of this reg->id is twofold: i) it is used in find_good_pkt_pointers() for setting the allowed access range for regs with PTR_TO_PACKET of same id once verifier matched on data/data_end tests, and ii) for check_ptr_alignment() to determine that when not having efficient unaligned access and register with UNKNOWN_VALUE was added to PTR_TO_PACKET, that we're only allowed to access the content bytewise due to unknown unalignment. reg->id was never intended for PTR_TO_MAP_VALUE{,_ADJ} types and thus is always zero, the only marking is in PTR_TO_MAP_VALUE_OR_NULL that was added after 484611357c19 via 57a09bf0a416 ("bpf: Detect identical PTR_TO_MAP_VALUE_OR_NULL registers"). Above tests will fail for non-root environment due to prohibited pointer arithmetic. The fix splits register-type specific checks into their own helper instead of keeping them combined, so we don't run into a similar issue in future once we extend check_ptr_alignment() further and forget to add reg->type checks for some of the checks. Fixes: 484611357c19 ("bpf: allow access into map value arrays") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Josef Bacik <jbacik@fb.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01bpf, verifier: fix alu ops against map_value{, _adj} register typesDaniel Borkmann
While looking into map_value_adj, I noticed that alu operations directly on the map_value() resp. map_value_adj() register (any alu operation on a map_value() register will turn it into a map_value_adj() typed register) are not sufficiently protected against some of the operations. Two non-exhaustive examples are provided that the verifier needs to reject: i) BPF_AND on r0 (map_value_adj): 0: (bf) r2 = r10 1: (07) r2 += -8 2: (7a) *(u64 *)(r2 +0) = 0 3: (18) r1 = 0xbf842a00 5: (85) call bpf_map_lookup_elem#1 6: (15) if r0 == 0x0 goto pc+2 R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp 7: (57) r0 &= 8 8: (7a) *(u64 *)(r0 +0) = 22 R0=map_value_adj(ks=8,vs=48,id=0),min_value=0,max_value=8 R10=fp 9: (95) exit from 6 to 9: R0=inv,min_value=0,max_value=0 R10=fp 9: (95) exit processed 10 insns ii) BPF_ADD in 32 bit mode on r0 (map_value_adj): 0: (bf) r2 = r10 1: (07) r2 += -8 2: (7a) *(u64 *)(r2 +0) = 0 3: (18) r1 = 0xc24eee00 5: (85) call bpf_map_lookup_elem#1 6: (15) if r0 == 0x0 goto pc+2 R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp 7: (04) (u32) r0 += (u32) 0 8: (7a) *(u64 *)(r0 +0) = 22 R0=map_value_adj(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp 9: (95) exit from 6 to 9: R0=inv,min_value=0,max_value=0 R10=fp 9: (95) exit processed 10 insns Issue is, while min_value / max_value boundaries for the access are adjusted appropriately, we change the pointer value in a way that cannot be sufficiently tracked anymore from its origin. Operations like BPF_{AND,OR,DIV,MUL,etc} on a destination register that is PTR_TO_MAP_VALUE{,_ADJ} was probably unintended, in fact, all the test cases coming with 484611357c19 ("bpf: allow access into map value arrays") perform BPF_ADD only on the destination register that is PTR_TO_MAP_VALUE_ADJ. Only for UNKNOWN_VALUE register types such operations make sense, f.e. with unknown memory content fetched initially from a constant offset from the map value memory into a register. That register is then later tested against lower / upper bounds, so that the verifier can then do the tracking of min_value / max_value, and properly check once that UNKNOWN_VALUE register is added to the destination register with type PTR_TO_MAP_VALUE{,_ADJ}. This is also what the original use-case is solving. Note, tracking on what is being added is done through adjust_reg_min_max_vals() and later access to the map value enforced with these boundaries and the given offset from the insn through check_map_access_adj(). Tests will fail for non-root environment due to prohibited pointer arithmetic, in particular in check_alu_op(), we bail out on the is_pointer_value() check on the dst_reg (which is false in root case as we allow for pointer arithmetic via env->allow_ptr_leaks). Similarly to PTR_TO_PACKET, one way to fix it is to restrict the allowed operations on PTR_TO_MAP_VALUE{,_ADJ} registers to 64 bit mode BPF_ADD. The test_verifier suite runs fine after the patch and it also rejects mentioned test cases. Fixes: 484611357c19 ("bpf: allow access into map value arrays") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Josef Bacik <jbacik@fb.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge branch 'mv88e6xxx-cross-chip-bridging'David S. Miller
Vivien Didelot says: ==================== net: dsa: mv88e6xxx: program cross-chip bridging The purpose of this patch series is to bring hardware cross-chip bridging configuration to the DSA layer and the mv88e6xxx DSA driver. Most recent Marvell switch chips have a Cross-chip Port Based VLAN Table (PVT) used to restrict to which internal destination port an arbitrary external source port is allowed to egress frames to. The current behavior of the mv88e6xxx driver is to program this table table with all ones, allowing any external ports to egress frames on any internal ports. This means that carefully crafted Ethernet frames can potentially bypass the user bridging configuration. Patches 1 to 7 prepare the setup of this table and factorize the common bits of both in-chip and cross-chip Marvell bridging code. Patch 8 adds new optional cross-chip bridging operations to DSA switch. Patch 9 switches the current behavior to program the table according to the user bridging configuration when (cross-chip) ports get (un)bridged. On a ZII Rev B board, bridging together the 3 user ports of both 88E6352 will result in the following PVTs on respectively switch 0 and switch 1: External Internal Ports Dev Port 0 1 2 3 4 5 6 1 0 * * * - - * * 1 1 * * * - - * * 1 2 * * * - - * * 1 3 - - - - - * * 1 4 - - - - - * * 1 5 * * * * * * * 1 6 * * * * * * * 0 0 * * * - - * * 0 1 * * * - - * * 0 2 * * * - - * * 0 3 - - - - - * * 0 4 - - - - - * * 0 5 * * * * * * * 0 6 * * * * * * * Changes since v2: - Define MV88E6XXX_MAX_PVT_SWITCHES and MV88E6XXX_MAX_PVT_PORTS - use mv88e6xxx_g2_misc_4_bit_port instead of the 5-bit variant - add Andrew's tags and reword commit 6/9 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: add cross-chip bridgingVivien Didelot
Implement the DSA cross-chip bridging operations by remapping the local ports an external source port can egress frames to, when this cross-chip port joins or leaves a bridge. The PVT is no longer configured with all ones allowing any external frame to egress any local port. Only DSA and CPU ports, as well as bridge group members, can egress frames on local ports. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: add cross-chip bridging operationsVivien Didelot
Introduce crosschip_bridge_{join,leave} operations in the dsa_switch_ops structure, which can be used by switches supporting interconnection. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: remap existing bridge membersVivien Didelot
When a local port of a switch chip becomes a member of a bridge group, we need to reprogram the Cross-chip Port Based VLAN Table (PVT) to allow existing cross-chip bridge members to egress frames on the new ports. There is no functional changes yet, since the PVT is still programmed with all ones, allowing any external port to egress frames locally. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: factorize in-chip bridge mapVivien Didelot
Factorize the code in the DSA port_bridge_{join,leave} routines used to program the port VLAN map of all local ports of a given bridge group. At the same time shorten the _mv88e6xxx_port_based_vlan_map to get rid of the old underscore prefix naming convention. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: rework in-chip bridgingVivien Didelot
All ports -- internal and external, for chips featuring a PVT -- have a mask restricting to which internal ports a frame is allowed to egress. Now that DSA exposes the number of ports and their bridge devices, it is possible to extract the code generating the VLAN map and make it generic so that it can be shared later with the cross-chip bridging code. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: allocate the number of portsVivien Didelot
The current code allocates DSA_MAX_PORTS ports for a Marvell dsa_switch structure. Provide the exact number of ports so the corresponding ds->num_ports is accurate. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: program the PVT with all onesVivien Didelot
The Cross-chip Port Based VLAN Table (PVT) is currently initialized with all ones, allowing any external ports to egress frames on local ports. This commit implements the PVT access functions and programs the PVT with all ones for the local switch ports only, instead of using the Init operation. The current behavior is unchanged for the moment. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: use 4-bit port for PVT dataVivien Didelot
The Cross-chip Port Based VLAN Table (PVT) supports two indexing modes, one using 5-bit for device and 4-bit for port, the other using 4-bit for device and 5-bit for port, configured via the Global 2 Misc register. Only 4 bits for the source port are needed when interconnecting 88E6xxx switch devices since they all support less than 16 physical ports. The full 5 bits are needed when interconnecting a device with 98DXxxx switch devices since they support more than 16 physical ports. Add a mv88e6xxx_pvt_setup helper to set the 4-bit port PVT mode, which will be extended later to also initialize the PVT content. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: dsa: mv88e6xxx: move PVT description in infoVivien Didelot
Not all Marvell switch chips feature a Cross-chip Port VLAN Table (PVT). Chips with a PVT use the same implementation, so a new mv88e6xxx_ops member won't be necessary yet. Add a "pvt" boolean member to the mv88e6xxx_info structure and kill the obsolete MV88E6XXX_FLAGS_PVT flag. Add a mv88e6xxx_has_pvt helper to wrap future checks of that condition. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01r8152: The Microsoft Surface docks also use R8152 v2René Rebe
Without this the generic cdc_ether grabs the device, and does not really work. Signed-off-by: René Rebe <rene@exactcode.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01openvswitch: Fix ovs_flow_key_update()Yi-Hung Wei
ovs_flow_key_update() is called when the flow key is invalid, and it is used to update and revalidate the flow key. Commit 329f45bc4f19 ("openvswitch: add mac_proto field to the flow key") introduces mac_proto field to flow key and use it to determine whether the flow key is valid. However, the commit does not update the code path in ovs_flow_key_update() to revalidate the flow key which may cause BUG_ON() on execute_recirc(). This patch addresses the aforementioned issue. Fixes: 329f45bc4f19 ("openvswitch: add mac_proto field to the flow key") Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com> Acked-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net/faraday: Explicitly include linux/of.h and linux/property.hMark Brown
This driver uses interfaces from linux/of.h and linux/property.h but relies on implict inclusion of those headers which means that changes in other headers could break the build, as happened in -next for arm today. Add a explicit includes. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01net: hns: Add ACPI support to check SFP presentDaode Huang
The current code only supports DT to check SFP present. This patch adds ACPI support as well. Signed-off-by: Daode Huang <huangdaode@hisilicon.com> Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01dpaa_eth: use AVOIDBLOCK for Tx confirmation queuesMadalin Bucur
The AVOIDBLOCK flag determines the Tx confirmation queues processing to be redirected to any available CPU when the current one is slow in processing them. This may result in a higher Tx confirmation interrupt count but may reduce pressure on a certain CPU that with the previous setting would process all Tx confirmation frames. Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge tag 'usb-4.11-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB fixes for 4.11-rc5. The usual xhci fixes are here, as well as a fix for yet-another-bug- found-by-KASAN, those developers are doing great stuff here. And there's a phy build warning fix that showed up in 4.11-rc1. All of these have been in linux-next with no reported issues" * tag 'usb-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: phy: isp1301: Fix build warning when CONFIG_OF is disabled xhci: Manually give back cancelled URB if we can't queue it for cancel xhci: Set URB actual length for stopped control transfers xhci: plat: Register shutdown for xhci_plat USB: fix linked-list corruption in rh_call_control()
2017-04-01fsl/fman: take into account all RGMII modesMadalin Bucur
Accept the internal delay RGMII variants. Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge tag 'tty-4.11-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some small fixes for some serial drivers and Kconfig help text for 4.11-rc5. Nothing major here at all, a few things resolving reported bugs in some random serial drivers. I don't think these made the last linux-next due to me getting to them yesterday, but I am not sure, they might have snuck in. The patches only affect drivers that the maintainers of sent me these patches for, so we should be safe here :)" * tag 'tty-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty: pl011: fix earlycon work-around for QDF2400 erratum 44 serial: 8250_EXAR: fix duplicate Kconfig text and add missing help text tty/serial: atmel: fix TX path in atmel_console_write() tty/serial: atmel: fix race condition (TX+DMA) serial: mxs-auart: Fix baudrate calculation
2017-04-01vxlan: vxlan dev should inherit lowerdev's gso_max_sizeFelix Manlunas
vxlan dev currently ignores lowerdev's gso_max_size, which adversely affects TSO performance of liquidio if it's the lowerdev. Egress TCP packets' skb->len often exceed liquidio's advertised gso_max_size. This may happen on other NIC drivers. Fix it by assigning lowerdev's gso_max_size to that of vxlan dev. Might as well do likewise for gso_max_segs. Single flow TSO throughput of liquidio as lowerdev (using iperf3): Before the patch: 139 Mbps After the patch : 8.68 Gbps Percent increase: 6,144 % Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by: Satanand Burla <satananda.burla@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-01Merge tag 'acpi-4.11-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix two issues related to IOAPIC hotplug, an overzealous build optimization that prevents the function graph tracer from working with the ACPI subsystem correctly and an RCU synchronization issue in the ACPI APEI code. Specifics: - drop the unconditional setting of the '-Os' gcc flag from the ACPI Makefile to make the function graph tracer work correctly with the ACPI subsystem (Josh Poimboeuf). - add missing synchronize_rcu() to ghes_remove() which removes an element from an RCU-protected list, but fails to synchronize it properly afterward (James Morse). - fix two problems related to IOAPIC hotplug, a local variable initialization in setup_res() and the creation of platform device objects for IO(x)APICs which are (a) unused and (b) leaked on hot-removal (Joerg Roedel)" * tag 'acpi-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: Fix incompatibility with mcount-based function graph tracing ACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal ACPI: Do not create a platform_device for IOAPIC/IOxAPIC ACPI: ioapic: Clear on-stack resource before using it
2017-04-01Merge tag 'pm-4.11-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix a cpufreq core issue with the initialization of the cpufreq sysfs interface and a cpuidle powernv driver initialization issue. Specifics: - symbolic links from CPU directories to the corresponding cpufreq policy directories in sysfs are not created during initialization in some cases which confuses user space, so prevent that from happening (Rafael Wysocki). - the powernv cpuidle driver fails to pass a correct cpumaks to the cpuidle core in some cases which causes subsequent failures to occur, so fix it (Vaidyanathan Srinivasan)" * tag 'pm-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpuidle: powernv: Pass correct drv->cpumask for registration cpufreq: Fix creation of symbolic links to policy directories
2017-04-01Merge branch 'i2c/for-current' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Two bugfixes from I2C, specifically the I2C mux section. Thanks to peda for collecting them" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: mux: pca954x: Add missing pca9546 definition to chip_desc Revert "i2c: mux: pca954x: Add ACPI support for pca954x"
2017-04-01Merge tag 'arc-4.11-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: "Accumulated fixes for ARC which I've been been sitting on for a while: - reading clk from driver vs device tree [Vlad] - fix support for UIO in VDK platform [Alexey] - SLC busy bit reading workaround - build warning with kprobes header reorg" * tag 'arc-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: fix build warnings with !CONFIG_KPROBES ARCv2: SLC: Make sure busy bit is set properly on SLC flushing ARC: vdk: Fix support of UIO ARCv2: make unimplemented vectors as no-ops rather than halt core ARC: get rate from clk driver instead of reading device tree ARC: [dts] add cpu nodes to ARCHS SMP device tree ARC: [dts] add input clocks for cpu nodes
2017-04-01Merge tag 'nfsd-4.11-1' of git://linux-nfs.org/~bfields/linuxLinus Torvalds
Pull nfsd fixes from Bruce Fields: "The restriction of NFSv4 to TCP went overboard and also broke the backchannel; fix. Also some minor refinements to the nfsd version-setting interface that we'd like to get fixed before release" * tag 'nfsd-4.11-1' of git://linux-nfs.org/~bfields/linux: svcrdma: set XPT_CONG_CTRL flag for bc xprt NFSD: fix nfsd_reset_versions for NFSv4. NFSD: fix nfsd_minorversion(.., NFSD_AVAIL) NFSD: further refinement of content of /proc/fs/nfsd/versions nfsd: map the ENOKEY to nfserr_perm for avoiding warning SUNRPC/backchanel: set XPT_CONG_CTRL flag for bc xprt
2017-04-01tty: pl011: fix earlycon work-around for QDF2400 erratum 44Timur Tabi
The work-around for the Qualcomm Datacenter Technologies QDF2400 erratum 44 sets the "qdf2400_e44_present" global variable if the work-around is needed. However, this check does not happen until after earlycon is initialized, which means the work-around is not used, and the console hangs as soon as it displays one character. Fixes: d8a4995bcea1 ("tty: pl011: Work around QDF2400 E44 stuck BUSY bit") Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-31Merge branch 'for-linus-4.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fixes from Chris Mason: "We have three small fixes queued up in my for-linus-4.11 branch" * 'for-linus-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: fix an integer overflow check btrfs: Change qgroup_meta_rsv to 64bit Btrfs: bring back repair during read
2017-03-31kasan: do not sanitize kexec purgatoryMike Galbraith
Fixes this: kexec: Undefined symbol: __asan_load8_noabort kexec-bzImage64: Loading purgatory failed Link: http://lkml.kernel.org/r/1489672155.4458.7.camel@gmx.de Signed-off-by: Mike Galbraith <efault@gmx.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-03-31drivers/rapidio/devices/tsi721.c: make module parameter variable name uniqueRandy Dunlap
kbuild test robot reported a non-static variable name collision between a staging driver and a RapidIO driver, with a generic variable name of 'dbg_level'. Both drivers should be changed so that they don't use this generic public variable name. This patch fixes the RapidIO driver but does not change the user interface (name) for the module parameter. drivers/staging/built-in.o:(.bss+0x109d0): multiple definition of `dbg_level' drivers/rapidio/built-in.o:(.bss+0x16c): first defined here Link: http://lkml.kernel.org/r/ab527fc5-aa3c-4b07-5d48-eef5de703192@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kbuild test robot <fengguang.wu@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Alexandre Bounine <alexandre.bounine@idt.com> Cc: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>