summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* bpf_trace: Make dependent on PERF_EVENTSSteven Rostedt2015-11-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Arnd Bergmann reported: In my ARM randconfig tests, I'm getting a build error for newly added code in bpf_perf_event_read and bpf_perf_event_output whenever CONFIG_PERF_EVENTS is disabled: kernel/trace/bpf_trace.c: In function 'bpf_perf_event_read': kernel/trace/bpf_trace.c:203:11: error: 'struct perf_event' has no member named 'oncpu' if (event->oncpu != smp_processor_id() || ^ kernel/trace/bpf_trace.c:204:11: error: 'struct perf_event' has no member named 'pmu' event->pmu->count) This can happen when UPROBE_EVENT is enabled but KPROBE_EVENT is disabled. I'm not sure if that is a configuration we care about, otherwise we could prevent this case from occuring by adding Kconfig dependencies. Looking at this further, it's really that UPROBE_EVENT enables PERF_EVENTS. By just having BPF_EVENTS depend on PERF_EVENTS, then all is fine. Link: http://lkml.kernel.org/r/4525348.Aq9YoXkChv@wuerfel Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* qed: select ZLIB_INFLATEArnd Bergmann2015-11-101-0/+1
| | | | | | | | | | | | | | | | The newly added qlogic qed driver uses the zlib library, but misses the dependency: drivers/built-in.o: In function `qed_alloc_stream_mem': drivers/net/ethernet/qlogic/qed/qed_main.c:707: undefined reference to `zlib_inflate_workspacesize' drivers/built-in.o: In function `qed_unzip_data': drivers/net/ethernet/qlogic/qed/qed_main.c:675: undefined reference to `zlib_inflateInit2' This changes Kconfig to always select zlib when needed. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: fe56b9e6a8d9 ("qed: Add module with basic common support") Signed-off-by: David S. Miller <davem@davemloft.net>
* net: fix a race in dst_release()Eric Dumazet2015-11-101-1/+1
| | | | | | | | | | | | Only cpu seeing dst refcount going to 0 can safely dereference dst->flags. Otherwise an other cpu might already have freed the dst. Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst") Reported-by: Greg Thelen <gthelen@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: mvneta: Fix memory use after free.Justin Maggard2015-11-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After changing an interface's MTU, then bringing the interface down and back up again, I immediately saw tons of kernel messages like below. The reason for this bad behavior is mvneta_rxq_drop_pkts(), which calls dma_unmap_single() on already-freed memory. So we need to switch the order of those two operations. [ 152.388518] BUG: Bad page state in process ifconfig pfn:1b518 [ 152.388526] page:dff3dbc0 count:0 mapcount:0 mapping: (null) index:0x0 [ 152.395178] flags: 0x200(arch_1) [ 152.398441] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set [ 152.398446] bad because of flags: [ 152.398450] flags: 0x200(arch_1) [ 152.401716] Modules linked in: [ 152.401728] CPU: 0 PID: 1453 Comm: ifconfig Tainted: P B O 4.1.12.armada.1 #1 [ 152.401733] Hardware name: Marvell Armada 370/XP (Device Tree) [ 152.401749] [<c0015b1c>] (unwind_backtrace) from [<c0011d8c>] (show_stack+0x10/0x14) [ 152.401762] [<c0011d8c>] (show_stack) from [<c06aa68c>] (dump_stack+0x74/0x90) [ 152.401772] [<c06aa68c>] (dump_stack) from [<c0096c08>] (bad_page+0xc4/0x124) [ 152.401783] [<c0096c08>] (bad_page) from [<c0099378>] (get_page_from_freelist+0x4e4/0x644) [ 152.401794] [<c0099378>] (get_page_from_freelist) from [<c0099620>] (__alloc_pages_nodemask+0x148/0x784) [ 152.401805] [<c0099620>] (__alloc_pages_nodemask) from [<c00ac658>] (kmalloc_order+0x10/0x20) [ 152.401818] [<c00ac658>] (kmalloc_order) from [<c04c6f44>] (mvneta_rx_refill+0xc4/0xe8) [ 152.401830] [<c04c6f44>] (mvneta_rx_refill) from [<c04c96c0>] (mvneta_setup_rxqs+0x298/0x39c) [ 152.401842] [<c04c96c0>] (mvneta_setup_rxqs) from [<c04c9904>] (mvneta_open+0x3c/0x150) [ 152.401853] [<c04c9904>] (mvneta_open) from [<c0597764>] (__dev_open+0xac/0x124) [ 152.401864] [<c0597764>] (__dev_open) from [<c05979e4>] (__dev_change_flags+0x8c/0x148) [ 152.401875] [<c05979e4>] (__dev_change_flags) from [<c0597ac0>] (dev_change_flags+0x18/0x48) [ 152.401886] [<c0597ac0>] (dev_change_flags) from [<c060d308>] (devinet_ioctl+0x620/0x6d0) [ 152.401897] [<c060d308>] (devinet_ioctl) from [<c057d810>] (sock_ioctl+0x64/0x288) [ 152.401908] [<c057d810>] (sock_ioctl) from [<c00dcb7c>] (do_vfs_ioctl+0x78/0x608) [ 152.401918] [<c00dcb7c>] (do_vfs_ioctl) from [<c00dd170>] (SyS_ioctl+0x64/0x74) [ 152.401930] [<c00dd170>] (SyS_ioctl) from [<c000f3a0>] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Justin Maggard <jmaggard@netgear.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Documentation: Fix default value tcp_limit_output_bytesNiklas Cassel2015-11-091-1/+1
| | | | | | | | Commit c39c4c6abb89 ("tcp: double default TSQ output bytes limit") updated default value for tcp_limit_output_bytes Signed-off-by: Niklas Cassel <niklas.cassel@axis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* macvtap: Resolve possible __might_sleep warning in macvtap_do_read()Vlad Yasevich2015-11-091-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | macvtap_do_read code calls macvtap_put_user while it might be set up to wait for the user. This results in the following warning: Jun 23 16:25:26 galen kernel: ------------[ cut here ]------------ Jun 23 16:25:26 galen kernel: WARNING: CPU: 0 PID: 30433 at kernel/sched/core.c: 7286 __might_sleep+0x7f/0x90() Jun 23 16:25:26 galen kernel: do not call blocking ops when !TASK_RUNNING; state =1 set at [<ffffffff810f1c1f>] prepare_to_wait+0x2f/0x90 Jun 23 16:25:26 galen kernel: CPU: 0 PID: 30433 Comm: cat Not tainted 4.1.0-rc6+ #11 Jun 23 16:25:26 galen kernel: Call Trace: Jun 23 16:25:26 galen kernel: [<ffffffff817f76ba>] dump_stack+0x4c/0x65 Jun 23 16:25:26 galen kernel: [<ffffffff810a07ca>] warn_slowpath_common+0x8a/0xc 0 Jun 23 16:25:26 galen kernel: [<ffffffff810a0846>] warn_slowpath_fmt+0x46/0x50 Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ? prepare_to_wait+0x2f/0x90 Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ? prepare_to_wait+0x2f/0x90 Jun 23 16:25:26 galen kernel: [<ffffffff810cdc1f>] __might_sleep+0x7f/0x90 Jun 23 16:25:26 galen kernel: [<ffffffff811f8e15>] might_fault+0x55/0xb0 Jun 23 16:25:26 galen kernel: [<ffffffff810fab9d>] ? trace_hardirqs_on_caller+0x fd/0x1c0 Jun 23 16:25:26 galen kernel: [<ffffffff813f639c>] copy_to_iter+0x7c/0x360 Jun 23 16:25:26 galen kernel: [<ffffffffa052da86>] macvtap_do_read+0x256/0x3d0 [macvtap] Jun 23 16:25:26 galen kernel: [<ffffffff810f20e0>] ? prepare_to_wait_event+0x110/0x110 Jun 23 16:25:26 galen kernel: [<ffffffffa052dcab>] macvtap_read_iter+0x2b/0x50 [macvtap] Jun 23 16:25:26 galen kernel: [<ffffffff81247f2e>] __vfs_read+0xae/0xe0 Jun 23 16:25:26 galen kernel: [<ffffffff81248526>] vfs_read+0x86/0x140 Jun 23 16:25:26 galen kernel: [<ffffffff812493b9>] SyS_read+0x49/0xb0 Jun 23 16:25:26 galen kernel: [<ffffffff8180182e>] system_call_fastpath+0x12/0x76 Jun 23 16:25:26 galen kernel: ---[ end trace 22e33f67e70c0c2a ]--- Make sure thet we call finish_wait() if we have the skb to process before trying to actually process it. Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* mvneta: add FIXED_PHY dependencyArnd Bergmann2015-11-091-0/+1
| | | | | | | | | | | | | | | | | | | | | The fixed_phy infrastructure is done in a way that is optional, by providing 'static inline' helper functions doing nothing in include/linux/phy_fixed.h for all its APIs. However, three out of the four users (DSA, BCMGENET, and SYSTEMPORT) always 'select FIXED_PHY', presumably because they need that. MVNETA is the fourth one, and if that is built-in but FIXED_PHY is configured as a loadable module, we get a link error: drivers/built-in.o: In function `mvneta_fixed_link_update': fpga-mgr.c:(.text+0x33ed80): undefined reference to `fixed_phy_update_state' Presumably this driver has the same dependency as the others, so this patch also uses 'select' to ensure that the fixed-phy support is built-in. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 898b2970e2c9 ("mvneta: implement SGMII-based in-band link state signaling") Signed-off-by: David S. Miller <davem@davemloft.net>
* net: caif: check return value of alloc_netdevRasmus Villemoes2015-11-091-2/+5
| | | | | | | | | | I don't know if dev can actually be NULL here, but the test should be above alloc_netdev(), to avoid leaking the struct net_device in case dev is actually NULL. And of course the return value from alloc_netdev should be tested. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: hisilicon: NET_VENDOR_HISILICON should depend on HAS_DMAGeert Uytterhoeven2015-11-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If NO_DMA=y: ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined! ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined! ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined! ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined! ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined! ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined! ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined! ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined! ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined! ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined! ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined! ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined! ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined! ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined! ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined! ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined! ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined! ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined! ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined! ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined! ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined! ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined! ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined! ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined! As this affects all of HNS_ENET, HNS_DSAF, HNS, HIX5HD2_GMAC, and HIP04_ETH, add a dependency on HAS_DMA to the main NET_VENDOR_HISILICON symbol to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* drivers: net: xgene: fix RGMII 10/100Mb modeIyappan Subramanian2015-11-093-3/+48
| | | | | | | | This patch fixes the RGMII 10/100M mode by reprogramming the clock. Signed-off-by: Iyappan Subramanian <isubramanian@apm.com> Tested-by: Fushen Chen <fchen@apm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'skb_to_full_sk'David S. Miller2015-11-098-87/+149
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Eric Dumazet says: ==================== net: add skb_to_full_sk() helper Many contexts need to reach listener socket from skb attached to a request socket. This patch series add skb_to_full_sk() to clearly express this need and use it where appropriate. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * netfilter: nft_meta: use skb_to_full_sk() helperEric Dumazet2015-11-091-16/+20
| | | | | | | | | | | | | | | | SYNACK packets might be attached to request sockets. Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net_sched: em_meta: use skb_to_full_sk() helperEric Dumazet2015-11-091-46/+92
| | | | | | | | | | | | | | | | SYNACK packets might be attached to request sockets. Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * sched: cls_flow: use skb_to_full_sk() helperEric Dumazet2015-11-091-4/+11
| | | | | | | | | | | | | | | | SYNACK packets might be attached to request sockets. Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * netfilter: xt_owner: use skb_to_full_sk() helperEric Dumazet2015-11-091-2/+4
| | | | | | | | | | | | | | | | | | SYNACK packets might be attached to a request socket, xt_owner wants to gte the listener in this case. Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * smack: use skb_to_full_sk() helperEric Dumazet2015-11-091-4/+7
| | | | | | | | | | | | | | | | | | This module wants to access sk->sk_security, which is not available for request sockets. Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: add skb_to_full_sk() helper and use it in selinux_netlbl_skbuff_setsid()Eric Dumazet2015-11-093-15/+15
|/ | | | | | | | | | | | Generalize selinux_skb_sk() added in commit 212cd0895330 ("selinux: fix random read in selinux_ip_postroute_compat()") so that we can use it other contexts. Use it right away in selinux_netlbl_skbuff_setsid() Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'nfc-fixes-4.4-1' of ↵David S. Miller2015-11-094-33/+22
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes Samuel Ortiz says: ==================== NFC 4.4 fixes This is the 1st NFC fixes pull request for 4.4. It includes bug fixes and one fix for a build failure, all of them introduced with the first NFC pull request for 4.4. We have: - Fix nfcmrvl SPI driver potential build error due to a broken Kconfig dependency. - A few fixes for the firmware download implementation for the nfcmrvl UART driver. - A GPIO allocation leak for the nfcmrvl driver. - One code simplification for the nfcmrvl DT handling. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * NFC: nfcmrvl: avoid being stuck on FW dnld timeoutVincent Cuissard2015-11-051-3/+9
| | | | | | | | | | | | | | | | | | FW Download procedure can block on del_timer_sync because the timer is not running. This patch check that timer is scheduled before cancelling it. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nfcmrvl: remove unneeded CONFIG_OF switchesVincent Cuissard2015-11-052-24/+0
| | | | | | | | | | Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nfcmrvl: free reset gpioVincent Cuissard2015-11-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Reset GPIO shall be freed by the driver since the device used in devm_ calls can be still valid on unregister. If user removes the module and inserts it again, the devm_gpio_request will fail because the underlying physical device (e.g i2c) was not removed so the device management won't have freed the gpio. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nfcmrvl: add a small wait after setting UART breakVincent Cuissard2015-11-051-1/+3
| | | | | | | | | | | | | | | | A small wait is inserted to ensure that controller has enough time to handle the break character. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nfcmrvl: avoid UART break control during FW downloadVincent Cuissard2015-11-051-4/+6
| | | | | | | | | | | | | | | | BootROM does not support any form of power management during FW download. On UART, the driver shall not try to send breaks. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nfcmrvl: fix SPI driver dependenciesArnd Bergmann2015-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newly added nfcmrvl_spi driver uses the spi_nci infrastructure, but does not have a Kconfig dependency on that, so we can get a link-time error: drivers/built-in.o: In function `nfcmrvl_spi_nci_send': (.text+0x1428dc): undefined reference to `nci_spi_send' drivers/built-in.o: In function `nfcmrvl_spi_probe': (.text+0x142a24): undefined reference to `nci_spi_allocate_spi' drivers/built-in.o: In function `nfcmrvl_spi_int_irq_thread_fn': (.text+0x142abc): undefined reference to `nci_spi_read' This clarifies the dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver") Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* | bpf: doc: correct arch list for supported eBPF JITYang Shi2015-11-091-3/+3
| | | | | | | | | | | | | | | | | | | | aarch64 and s390x support eBPF JIT too, correct document to reflect this and avoid any confusion. Signed-off-by: Yang Shi <yang.shi@linaro.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | dwc_eth_qos: Delete an unnecessary check before the function call "of_node_put"Markus Elfring2015-11-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | The of_node_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | bonding: fix panic on non-ARPHRD_ETHER enslave failureJay Vosburgh2015-11-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 7d5cd2ce529b, when bond_enslave fails on devices that are not ARPHRD_ETHER, if needed, it resets the bonding device back to ARPHRD_ETHER by calling ether_setup. Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP if the bond device is up, leaving it in a quasi-down state without having actually gone through dev_close. For bonding, if any periodic work queue items are active (miimon, arp_interval, etc), those will remain running, as they are stopped by bond_close. At this point, if the bonding module is unloaded or the bond is deleted, the system will panic when the work function is called. This panic is resolved by calling dev_close on the bond itself prior to calling ether_setup. Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Fixes: 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure") Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net/qlcnic: fix mac address restore in bond mode 5/6Jarod Wilson2015-11-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bonding driver saves a copy of slaves' original mac address and then assigns whatever mac as needed to the slave, depending on mode. In at least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the mac address of another slave. On release from the bond, the original mac address is supposed to get restored via a dev_set_mac_address() call in the bonding driver's __bond_release_one() function, which calls the slave's ndo_set_mac_address function, which for qlcnic, is qlcnic_set_mac(). Now, this function tries to be somewhat intelligent and exit early if you're trying to set the mac address to the same thing that is already set. The problem here is that adapter->mac_addr isn't in sync with netdev->dev_addr. The qlcnic driver still has the original mac stored in adapter->mac_addr, while the bonding driver has updated netdev->dev_addr, so qlcnic thinks we're trying to set the same address it already has. I think the way to go here, since the function updates both netdev and adapter's stored mac addresses, is to check if either of them doesn't match the newly requested mac. Simply checking netdev's value only could result in a similar mismatch and non-update, so look at both. CC: Dept-GELinuxNICDev@qlogic.com CC: netdev@vger.kernel.org CC: Manish Chopra <manish.chopra@qlogic.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | fjes: Delete an unnecessary check before the function call "vfree"Markus Elfring2015-11-071-3/+1
| | | | | | | | | | | | | | | | | | | | The vfree() function performs also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | selinux: fix random read in selinux_ip_postroute_compat()Eric Dumazet2015-11-051-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit e446f9dfe17b ("net: synack packets can be attached to request sockets"), I missed one remaining case of invalid skb->sk->sk_security access. Dmitry Vyukov got a KASan report pointing to it. Add selinux_skb_sk() helper that is responsible to get back to the listener if skb is attached to a request socket, instead of duplicating the logic. Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Paul Moore <paul@paul-moore.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'bnxt_en-fixes'David S. Miller2015-11-053-30/+64
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Michael Chan says: ==================== bnxt_en: Bug fixes. Miscellaneous small bug fixes. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnxt_en: More robust SRIOV cleanup sequence.Jeffrey Huang2015-11-051-13/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of always calling pci_sriov_disable() in remove_one(), the driver should detect whether VFs are currently assigned to the VMs. If the VFs are active in VMs, then it should not disable SRIOV as it is catastrophic to the VMs. Instead, it just leaves the VFs alone and continues to unload the PF. The user can then cleanup the VMs even after the PF driver has been unloaded. Signed-off-by: Jeffrey Huang <huangjw@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnxt_en: Fix comparison of u16 sw_id against negative value.Michael Chan2015-11-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assign the return value from bitmap_find_free_region() to an integer variable and check for negative error codes first, before assigning the bit ID to the unsigned sw_id field. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnxt_en: map CAG_REG_LEGACY_INT_STATUS_MASK to GRC window #4Jeffrey Huang2015-11-052-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to use offset 0x4014 for reading CAG interrupt status, the actual CAG register must be mapped to GRC bar0 window #4. Otherwise, the driver is reading garbage. This patch corrects this issue. Signed-off-by: Jeffrey Huang <huangjw@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnxt_en: Determine tcp/ipv6 RSS hash type correctly.Michael Chan2015-11-051-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | The profile ID in the completion record needs to be ANDed with the profile ID mask of 0x1f. This bug was causing the SKB hash type and the gso_type to be wrong in some cases. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnxt_en: Change sp events definitions to represent bit position.Jeffrey Huang2015-11-051-5/+5
|/ / | | | | | | | | | | | | | | | | Fix the sp event bits to be bit positions instead of bit values since the bit helper functions are expecting the former. Signed-off-by: Jeffrey Huang <huangjw@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tcp: use correct req pointer in tcp_move_syn() callsEric Dumazet2015-11-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | I mistakenly took wrong request sock pointer when calling tcp_move_syn() @req_unhash is either a copy of @req, or a NULL value for FastOpen connexions (as we do not expect to unhash the temporary request sock from ehash table) Fixes: 805c4bc05705 ("tcp: fix req->saved_syn race") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Ying Cai <ycai@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | packet: race condition in packet_bindFrancesco Ruggeri2015-11-051-31/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a race conditions between packet_notifier and packet_bind{_spkt}. It happens if packet_notifier(NETDEV_UNREGISTER) executes between the time packet_bind{_spkt} takes a reference on the new netdevice and the time packet_do_bind sets po->ifindex. In this case the notification can be missed. If this happens during a dev_change_net_namespace this can result in the netdevice to be moved to the new namespace while the packet_sock in the old namespace still holds a reference on it. When the netdevice is later deleted in the new namespace the deletion hangs since the packet_sock is not found in the new namespace' &net->packet.sklist. It can be reproduced with the script below. This patch makes packet_do_bind check again for the presence of the netdevice in the packet_sock's namespace after the synchronize_net in unregister_prot_hook. More in general it also uses the rcu lock for the duration of the bind to stop dev_change_net_namespace/rollback_registered_many from going past the synchronize_net following unlist_netdevice, so that no NETDEV_UNREGISTER notifications can happen on the new netdevice while the bind is executing. In order to do this some code from packet_bind{_spkt} is consolidated into packet_do_dev. import socket, os, time, sys proto=7 realDev='em1' vlanId=400 if len(sys.argv) > 1: vlanId=int(sys.argv[1]) dev='vlan%d' % vlanId os.system('taskset -p 0x10 %d' % os.getpid()) s = socket.socket(socket.PF_PACKET, socket.SOCK_RAW, proto) os.system('ip link add link %s name %s type vlan id %d' % (realDev, dev, vlanId)) os.system('ip netns add dummy') pid=os.fork() if pid == 0: # dev should be moved while packet_do_bind is in synchronize net os.system('taskset -p 0x20000 %d' % os.getpid()) os.system('ip link set %s netns dummy' % dev) os.system('ip netns exec dummy ip link del %s' % dev) s.close() sys.exit(0) time.sleep(.004) try: s.bind(('%s' % dev, proto+1)) except: print 'Could not bind socket' s.close() os.system('ip netns del dummy') sys.exit(0) os.waitpid(pid, 0) s.close() os.system('ip netns del dummy') sys.exit(0) Signed-off-by: Francesco Ruggeri <fruggeri@arista.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ipv4: use sk_fullsock() in ipv4_conntrack_defrag()Eric Dumazet2015-11-051-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | Before converting a 'socket pointer' into inet socket, use sk_fullsock() to detect timewait or request sockets. Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tcp: fix req->saved_syn raceEric Dumazet2015-11-054-11/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For the reasons explained in commit ce1050089c96 ("tcp/dccp: fix ireq->pktopts race"), we need to make sure we do not access req->saved_syn unless we own the request sock. This fixes races for listeners using TCP_SAVE_SYN option. Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets") Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Ying Cai <ycai@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: stmmac: fix double-initialization of phy_ifaceLABBE Corentin2015-11-051-1/+1
| | | | | | | | | | | | | | | | | | The variable phy_iface is double-initialized to itself. This patch remove that. Reported-by: coverity (CID 1271141) Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | qlogic: qed: fix error codes in qed_resc_alloc()Dan Carpenter2015-11-051-3/+9
| | | | | | | | | | | | | | | | | | We accidentally return success instead of -ENOMEM here. Fixes: fe56b9e6a8d9 ('qed: Add module with basic common support') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Yuval Mintz <Yuval.Mintz@qlogic.com Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: isolate unbridged portsVivien Didelot2015-11-054-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSA documentation specifies that each port must be capable of forwarding frames to the CPU port. The last changes on bridging support for the mv88e6xxx driver broke this requirement for non-bridged ports. So as for the bridged ports, reserve a few VLANs (4000+) in the switch to isolate ports that have not been bridged yet. By default, a port will be isolated with the CPU and DSA ports. When the port joins a bridge, it will leave its reserved port. When it is removed from a bridge, it will join its reserved VLAN again. Fixes: 5fe7f68016ff ("net: dsa: mv88e6xxx: fix hardware bridging") Reported-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | USB: qmi_wwan: Add quirk for Quectel EC20 Mini PCIe modulePetr Štetiar2015-11-051-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This device has same vendor and product IDs as G2K devices, but it has different number of interfaces(4 vs 5) and also different interface layout where EC20 has QMI on interface 4 instead of 0. lsusb output: Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x05c6 Qualcomm, Inc. idProduct 0x9215 Acer Gobi 2000 Wireless Modem bcdDevice 2.32 iManufacturer 1 Quectel iProduct 2 Quectel LTE Module iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 209 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Signed-off-by: Petr Štetiar <ynezz@true.cz> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'for-upstream' of ↵David S. Miller2015-11-054-11/+34
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Johan Hedberg says: ==================== pull request: bluetooth 2015-11-05 The following set of Bluetooth patches would be good to get into 4.4-rc1 if possible: - Fix for missing LE CoC parameter validity checks - Fix for potential deadlock in btusb - Fix for issuing unsupported commands during HCI init Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | Bluetooth: L2CAP: Add missing checks for invalid LE DCIDJohan Hedberg2015-11-051-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | When receiving a connect response we should make sure that the DCID is within the valid range and that we don't already have another channel allocated for the same DCID. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: L2CAP: Fix checked range when allocating new CIDJohan Hedberg2015-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The 'dyn_end' value is also a valid CID so it should be included in the range of values checked. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: L2CAP: Fix returning correct LE CoC response codesJohan Hedberg2015-11-052-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | The core spec defines specific response codes for situations when the received CID is incorrect. Add the defines for these and return them as appropriate from the LE Connect Request handler function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | Bluetooth: Check for supported white list before issuing commandsMarcel Holtmann2015-11-051-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The white list commands might not be implemented if the controller does not actually support the white list. So check the supported commands first before issuing these commands. Not supporting the white list is the same as supporting a white list with zero size. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * | Bluetooth: Fix possible deadlock in btusbKuba Pawlak2015-11-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8f9d02f470f48416444ac3a1eacecdd0f743f1a7 introduced spinlocks in btusb_work. This is run in a context of a worqueue and can be interrupted by hardware irq. If it happens while spinlock is held, we have a deadlock. Solution is to use _irqsave/_resore version of locking [ 466.460560] ================================= [ 466.460565] [ INFO: inconsistent lock state ] [ 466.460572] 4.3.0-rc6+ #1 Tainted: G W [ 466.460576] --------------------------------- [ 466.460582] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 466.460589] kworker/0:2/94 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 466.460595] (&(&data->rxlock)->rlock){?.-...}, at: [<ffffffffa0526923>] btusb_work+0xa3/0x3fd [btusb] [ 466.460621] {IN-HARDIRQ-W} state was registered at: [ 466.460625] [<ffffffff811021b5>] __lock_acquire+0xc45/0x1e80 [ 466.460638] [<ffffffff811040d5>] lock_acquire+0xe5/0x1f0 [ 466.460646] [<ffffffff8182f108>] _raw_spin_lock+0x38/0x50 [ 466.460657] [<ffffffffa0525448>] btusb_recv_intr+0x38/0x170 [btusb] [ 466.460668] [<ffffffffa0525626>] btusb_intr_complete+0xa6/0x130 [btusb] [ 466.460679] [<ffffffff815d8f1e>] __usb_hcd_giveback_urb+0x8e/0x160 [ 466.460690] [<ffffffff815d911f>] usb_hcd_giveback_urb+0x3f/0x120 [ 466.460698] [<ffffffff81606e4d>] uhci_giveback_urb+0xad/0x280 [ 466.460706] [<ffffffff81608f64>] uhci_scan_schedule.part.33+0x6b4/0xbe0 [ 466.460714] [<ffffffff81609b50>] uhci_irq+0xd0/0x180 [ 466.460722] [<ffffffff815d8296>] usb_hcd_irq+0x26/0x40 [ 466.460729] [<ffffffff81117d40>] handle_irq_event_percpu+0x40/0x300 [ 466.460739] [<ffffffff81118040>] handle_irq_event+0x40/0x60 [ 466.460746] [<ffffffff8111af39>] handle_fasteoi_irq+0x89/0x150 [ 466.460754] [<ffffffff8101e0f3>] handle_irq+0x73/0x120 [ 466.460763] [<ffffffff81832f11>] do_IRQ+0x61/0x120 [ 466.460772] [<ffffffff8183084c>] ret_from_intr+0x0/0x31 [ 466.460780] [<ffffffff81697a77>] cpuidle_enter+0x17/0x20 [ 466.460790] [<ffffffff810f62c2>] call_cpuidle+0x32/0x60 [ 466.460800] [<ffffffff810f65a8>] cpu_startup_entry+0x2b8/0x3f0 [ 466.460807] [<ffffffff818214ca>] rest_init+0x13a/0x140 [ 466.460817] [<ffffffff81f76029>] start_kernel+0x4a3/0x4c4 [ 466.460827] [<ffffffff81f75339>] x86_64_start_reservations+0x2a/0x2c [ 466.460837] [<ffffffff81f75485>] x86_64_start_kernel+0x14a/0x16d [ 466.460846] irq event stamp: 754913 [ 466.460851] hardirqs last enabled at (754913): [<ffffffff8182f4cc>] _raw_spin_unlock_irq+0x2c/0x40 [ 466.460861] hardirqs last disabled at (754912): [<ffffffff8182f28d>] _raw_spin_lock_irq+0x1d/0x60 [ 466.460869] softirqs last enabled at (753024): [<ffffffff810aeaa0>] __do_softirq+0x380/0x490 [ 466.460880] softirqs last disabled at (753009): [<ffffffff810aedef>] irq_exit+0x10f/0x120 [ 466.460888] other info that might help us debug this: [ 466.460894] Possible unsafe locking scenario: [ 466.460899] CPU0 [ 466.460903] ---- [ 466.460907] lock(&(&data->rxlock)->rlock); [ 466.460915] <Interrupt> [ 466.460918] lock(&(&data->rxlock)->rlock); [ 466.460926] *** DEADLOCK *** [ 466.460935] 2 locks held by kworker/0:2/94: [ 466.460939] #0: ("events"){.+.+.+}, at: [<ffffffff810c69bb>] process_one_work+0x16b/0x660 [ 466.460958] #1: ((&data->work)){+.+...}, at: [<ffffffff810c69bb>] process_one_work+0x16b/0x660 [ 466.460974] Signed-off-by: Kuba Pawlak <kubax.t.pawlak@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-01 21:01:55 +0100