summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-11-17kernel/printk: Block cpuhotplug callback when tasks are frozenThomas Gleixner
The recent conversion of the console hotplug notifier to the state machine missed the fact, that the notifier only operated on the non frozen transitions. As a consequence the console_lock/unlock() pair is also invoked during suspend, which results in a lockdep warning. Restore the previous state by making the lock/unlock conditional on !tasks_frozen. Fixes: 90b14889d2f9 ("kernel/printk: Convert to hotplug state machine") Reported-and-tested-by: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1611171729320.3645@nanos Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
2016-11-17net sched filters: pass netlink message flags in event notificationRoman Mashak
Userland client should be able to read an event, and reflect it back to the kernel, therefore it needs to extract complete set of netlink flags. For example, this will allow "tc monitor" to distinguish Add and Replace operations. Signed-off-by: Roman Mashak <mrv@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17Merge branch 'rds-ha-failover-fixes'David S. Miller
Sowmini Varadhan says: ==================== RDS: TCP: HA/Failover fixes This series contains a set of fixes for bugs exposed when we ran the following in a loop between a test machine pair: while (1); do # modprobe rds-tcp on test nodes # run rds-stress in bi-dir mode between test machine pair # modprobe -r rds-tcp on test nodes done rds-stress in bi-dir mode will cause both nodes to initiate RDS-TCP connections at almost the same instant, exposing the bugs fixed in this series. Without the fixes, rds-stress reports sporadic packet drops, and packets arriving out of sequence. After the fixes,we have been able to run the test overnight, without any issues. Each patch has a detailed description of the root-cause fixed by the patch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17RDS: TCP: Force every connection to be initiated by numerically smaller IP ↵Sowmini Varadhan
address When 2 RDS peers initiate an RDS-TCP connection simultaneously, there is a potential for "duelling syns" on either/both sides. See commit 241b271952eb ("RDS-TCP: Reset tcp callbacks if re-using an outgoing socket in rds_tcp_accept_one()") for a description of this condition, and the arbitration logic which ensures that the numerically large IP address in the TCP connection is bound to the RDS_TCP_PORT ("canonical ordering"). The rds_connection should not be marked as RDS_CONN_UP until the arbitration logic has converged for the following reason. The sender may start transmitting RDS datagrams as soon as RDS_CONN_UP is set, and since the sender removes all datagrams from the rds_connection's cp_retrans queue based on TCP acks. If the TCP ack was sent from a tcp socket that got reset as part of duel aribitration (but before data was delivered to the receivers RDS socket layer), the sender may end up prematurely freeing the datagram, and the datagram is no longer reliably deliverable. This patch remedies that condition by making sure that, upon receipt of 3WH completion state change notification of TCP_ESTABLISHED in rds_tcp_state_change, we mark the rds_connection as RDS_CONN_UP if, and only if, the IP addresses and ports for the connection are canonically ordered. In all other cases, rds_tcp_state_change will force an rds_conn_path_drop(), and rds_queue_reconnect() on both peers will restart the connection to ensure canonical ordering. A side-effect of enforcing this condition in rds_tcp_state_change() is that rds_tcp_accept_one_path() can now be refactored for simplicity. It is also no longer possible to encounter an RDS_CONN_UP connection in the arbitration logic in rds_tcp_accept_one(). Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17RDS: TCP: Track peer's connection generation numberSowmini Varadhan
The RDS transport has to be able to distinguish between two types of failure events: (a) when the transport fails (e.g., TCP connection reset) but the RDS socket/connection layer on both sides stays the same (b) when the peer's RDS layer itself resets (e.g., due to module reload or machine reboot at the peer) In case (a) both sides must reconnect and continue the RDS messaging without any message loss or disruption to the message sequence numbers, and this is achieved by rds_send_path_reset(). In case (b) we should reset all rds_connection state to the new incarnation of the peer. Examples of state that needs to be reset are next expected rx sequence number from, or messages to be retransmitted to, the new incarnation of the peer. To achieve this, the RDS handshake probe added as part of commit 5916e2c1554f ("RDS: TCP: Enable multipath RDS for TCP") is enhanced so that sender and receiver of the RDS ping-probe will add a generation number as part of the RDS_EXTHDR_GEN_NUM extension header. Each peer stores local and remote generation numbers as part of each rds_connection. Changes in generation number will be detected via incoming handshake probe ping request or response and will allow the receiver to reset rds_connection state. Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17RDS: TCP: set RDS_FLAG_RETRANSMITTED in cp_retrans listSowmini Varadhan
As noted in rds_recv_incoming() sequence numbers on data packets can decreas for the failover case, and the Rx path is equipped to recover from this, if the RDS_FLAG_RETRANSMITTED is set on the rds header of an incoming message with a suspect sequence number. The RDS_FLAG_RETRANSMITTED is predicated on the RDS_FLAG_RETRANSMITTED flag in the rds_message, so make sure the flag is set on messages queued for retransmission. Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net: stmmac: replace if (netif_msg_type) by their netif_xxx counterpartLABBE Corentin
As sugested by Joe Perches, we could replace all if (netif_msg_type(priv)) dev_xxx(priv->devices, ...) by the simpler macro netif_xxx(priv, hw, priv->dev, ...) Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net: stmmac: replace hardcoded function name by __func__LABBE Corentin
Some printing have the function name hardcoded. It is better to use __func__ instead. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net: stmmac: replace all pr_xxx by their netdev_xxx counterpartLABBE Corentin
The stmmac driver use lots of pr_xxx functions to print information. This is bad since we cannot know which device logs the information. (moreover if two stmmac device are present) Furthermore, it seems that it assumes wrongly that all logs will always be subsequent by using a dev_xxx then some indented pr_xxx like this: kernel: sun7i-dwmac 1c50000.ethernet: no reset control found kernel: Ring mode enabled kernel: No HW DMA feature register supported kernel: Normal descriptors kernel: TX Checksum insertion supported So this patch replace all pr_xxx by their netdev_xxx counterpart. Excepts for some printing where netdev "cause" unpretty output like: sun7i-dwmac 1c50000.ethernet (unnamed net_device) (uninitialized): no reset control found In those case, I keep dev_xxx. In the same time I remove some "stmmac:" print since this will be a duplicate with that dev_xxx displays. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net_sched: sch_fq: use hash_ptr()Eric Dumazet
When I wrote sch_fq.c, hash_ptr() on 64bit arches was awful, and I chose hash_32(). Linus Torvalds and George Spelvin fixed this issue, so we can use hash_ptr() to get more entropy on 64bit arches with Terabytes of memory, and avoid the cast games. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Hugh Dickins <hughd@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17mremap: fix race between mremap() and page cleanningAaron Lu
Prior to 3.15, there was a race between zap_pte_range() and page_mkclean() where writes to a page could be lost. Dave Hansen discovered by inspection that there is a similar race between move_ptes() and page_mkclean(). We've been able to reproduce the issue by enlarging the race window with a msleep(), but have not been able to hit it without modifying the code. So, we think it's a real issue, but is difficult or impossible to hit in practice. The zap_pte_range() issue is fixed by commit 1cf35d47712d("mm: split 'tlb_flush_mmu()' into tlb flushing and memory freeing parts"). And this patch is to fix the race between page_mkclean() and mremap(). Here is one possible way to hit the race: suppose a process mmapped a file with READ | WRITE and SHARED, it has two threads and they are bound to 2 different CPUs, e.g. CPU1 and CPU2. mmap returned X, then thread 1 did a write to addr X so that CPU1 now has a writable TLB for addr X on it. Thread 2 starts mremaping from addr X to Y while thread 1 cleaned the page and then did another write to the old addr X again. The 2nd write from thread 1 could succeed but the value will get lost. thread 1 thread 2 (bound to CPU1) (bound to CPU2) 1: write 1 to addr X to get a writeable TLB on this CPU 2: mremap starts 3: move_ptes emptied PTE for addr X and setup new PTE for addr Y and then dropped PTL for X and Y 4: page laundering for N by doing fadvise FADV_DONTNEED. When done, pageframe N is deemed clean. 5: *write 2 to addr X 6: tlb flush for addr X 7: munmap (Y, pagesize) to make the page unmapped 8: fadvise with FADV_DONTNEED again to kick the page off the pagecache 9: pread the page from file to verify the value. If 1 is there, it means we have lost the written 2. *the write may or may not cause segmentation fault, it depends on if the TLB is still on the CPU. Please note that this is only one specific way of how the race could occur, it didn't mean that the race could only occur in exact the above config, e.g. more than 2 threads could be involved and fadvise() could be done in another thread, etc. For anonymous pages, they could race between mremap() and page reclaim: THP: a huge PMD is moved by mremap to a new huge PMD, then the new huge PMD gets unmapped/splitted/pagedout before the flush tlb happened for the old huge PMD in move_page_tables() and we could still write data to it. The normal anonymous page has similar situation. To fix this, check for any dirty PTE in move_ptes()/move_huge_pmd() and if any, did the flush before dropping the PTL. If we did the flush for every move_ptes()/move_huge_pmd() call then we do not need to do the flush in move_pages_tables() for the whole range. But if we didn't, we still need to do the whole range flush. Alternatively, we can track which part of the range is flushed in move_ptes()/move_huge_pmd() and which didn't to avoid flushing the whole range in move_page_tables(). But that would require multiple tlb flushes for the different sub-ranges and should be less efficient than the single whole range flush. KBuild test on my Sandybridge desktop doesn't show any noticeable change. v4.9-rc4: real 5m14.048s user 32m19.800s sys 4m50.320s With this commit: real 5m13.888s user 32m19.330s sys 4m51.200s Reported-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-11-17ip6_tunnel: disable caching when the traffic class is inheritedPaolo Abeni
If an ip6 tunnel is configured to inherit the traffic class from the inner header, the dst_cache must be disabled or it will foul the policy routing. The issue is apprently there since at leat Linux-2.6.12-rc2. Reported-by: Liam McBirnie <liam.mcbirnie@boeing.com> Cc: Liam McBirnie <liam.mcbirnie@boeing.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net/mlx5e: remove napi_hash_del() callsEric Dumazet
Calling napi_hash_del() after netif_napi_del() is pointless. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Saeed Mahameed <saeedm@mellanox.com> Acked-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17Merge branch 'phy-dev-leaks'David S. Miller
Johan Hovold says: ==================== net: phy: fix of_node and device leaks These patches fix a couple of of_node leaks in the fixed-link code and a device reference leak in a phy helper. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net: phy: fixed_phy: fix of_node leak in fixed_phy_unregisterJohan Hovold
Make sure to drop the of_node reference taken in fixed_phy_register() when deregistering a PHY. Fixes: a75951217472 ("net: phy: extend fixed driver with fixed_phy_register()") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17of_mdio: fix device reference leak in of_phy_find_deviceJohan Hovold
Make sure to drop the reference taken by bus_find_device() before returning NULL from of_phy_find_device() when the found device is not a PHY. Fixes: 6ed742363b9c ("of: of_mdio: Ensure mdio device is a PHY") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17of_mdio: fix node leak in of_phy_register_fixed_link error pathJohan Hovold
Make sure to drop the of_node reference also on failure to parse the speed property in of_phy_register_fixed_link(). Fixes: 3be2a49e5c08 ("of: provide a binding for fixed link PHYs") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net: check dead netns for peernet2id_alloc()WANG Cong
Andrei reports we still allocate netns ID from idr after we destroy it in cleanup_net(). cleanup_net(): ... idr_destroy(&net->netns_ids); ... list_for_each_entry_reverse(ops, &pernet_list, list) ops_exit_list(ops, &net_exit_list); -> rollback_registered_many() -> rtmsg_ifinfo_build_skb() -> rtnl_fill_ifinfo() -> peernet2id_alloc() After that point we should not even access net->netns_ids, we should check the death of the current netns as early as we can in peernet2id_alloc(). For net-next we can consider to avoid sending rtmsg totally, it is a good optimization for netns teardown path. Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids") Reported-by: Andrei Vagin <avagin@gmail.com> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Andrei Vagin <avagin@openvz.org> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17net/mlx4_en: remove napi_hash_del() callEric Dumazet
There is no need calling napi_hash_del()+synchronize_rcu() before calling netif_napi_del() netif_napi_del() does this already. Using napi_hash_del() in a driver is useful only when dealing with a batch of NAPI structures, so that a single synchronize_rcu() can be used. mlx4_en_deactivate_cq() is deactivating a single NAPI. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17phy: twl4030-usb: Fix for musb session bit based PMTony Lindgren
Now with musb driver implementing generic session bit based PM, we need to have the USB PHYs behaving in a sane way for platforms implementing PM. Currently twl4030-usb enables PM in twl4030_phy_power_on() and then disables it in twl4030_phy_power_off(). This will block PM runtime for the SoC when no cable is connected. Fix the issue by moving PM runtime autosuspend call to happen where it gets called in twl4030_phy_power_on(). Note that this patch should not be backported to anything before commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") as before that all the glue layers implemented their own PM. Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") Tested-by: Ladislav Michl <ladis@linux-mips.org> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17usb: musb: Drop pointless PM runtime code for dsps glueTony Lindgren
This already gets done automatically by PM runtime and we have a separate autosuspend timeout in musb_core.c. Reviewed-by: Johan Hovold <johan@kernel.org> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17usb: musb: Add missing pm_runtime_disable and drop 2430 PM timeoutTony Lindgren
We are missing pm_runtime_disable() in 2430 glue layer. Further, we only need to enable PM runtime and disable it on exit. With musb_core.c doing PM, the glue layer as a parent will always be active when musb_core.c is active. This fixes host enumeration issues with some devices as reported by Ladislav Michl <ladis@linux-mips.org>. And holding an RPM reference while deregistering the child would lead to a crash in omap2430_runtime_suspend() which dereferences the now freed child's driver data on put as pointed out by Johan Hovold <johan@kernel.org>: Unable to handle kernel paging request at virtual address 6b6b6f17 ... [<c05453d4>] (omap2430_runtime_suspend) from [<c0481410>] (pm_generic_runtime_suspend+0x3c/0x48) [<c0481410>] (pm_generic_runtime_suspend) from [<c0121028>] (_od_runtime_suspend+0x1c/0x30) [<c0121028>] (_od_runtime_suspend) from [<c04833b0>] (__rpm_callback+0x3c/0x70) [<c04833b0>] (__rpm_callback) from [<c0483414>] (rpm_callback+0x30/0x90) [<c0483414>] (rpm_callback) from [<c0483984>] (rpm_suspend+0x118/0x6b4) [<c0483984>] (rpm_suspend) from [<c04840f4>] (rpm_idle+0x104/0x440) [<c04840f4>] (rpm_idle) from [<c04844ac>] (__pm_runtime_idle+0x7c/0xb0) [<c04844ac>] (__pm_runtime_idle) from [<c0545458>] (omap2430_remove+0x38/0x58) [<c0545458>] (omap2430_remove) from [<c047b2bc>] (platform_drv_remove+0x34/0x4c) Note that if changes are needed to the autosuspend timeout, it should be done in musb_core.c. Reported-by: Ladislav Michl <ladis@linux-mips.org> Fixes: 87326e858448 ("usb: musb: Remove extra PM runtime calls from 2430 glue layer") Tested-by: Ladislav Michl <ladis@linux-mips.org> Reviewed-by: Johan Hovold <johan@kernel.org> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17usb: musb: Fix PM for hub disconnectTony Lindgren
With a USB hub disconnected, devctl can be 0x19 for about a second on am335x and will stay forever on at least omap3. And we get no further interrupts when devctl session bit clears. This keeps PM runtime active. Let's fix the issue by polling devctl until the session bit clears or times out. We can do this by making musb->irq_work into delayed_work. And with the polling implemented, we can now also have the quirk for invalid VBUS it to avoid disconnecting too early while VBUS is ramping up. Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") Fixes: 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS Tested-by: Ladislav Michl <ladis@linux-mips.org> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17usb: musb: Fix sleeping function called from invalid context for hdrc glueTony Lindgren
Commit 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS glue layer") wrongly added a call for pm_runtime_get_sync to otg_timer that runs in softirq context. That causes a "BUG: sleeping function called from invalid context" every time when polling the cable status: [<c015ebb4>] (__might_sleep) from [<c0413d60>] (__pm_runtime_resume+0x9c/0xa0) [<c0413d60>] (__pm_runtime_resume) from [<c04d0bc4>] (otg_timer+0x3c/0x254) [<c04d0bc4>] (otg_timer) from [<c0191180>] (call_timer_fn+0xfc/0x41c) [<c0191180>] (call_timer_fn) from [<c01915c0>] (expire_timers+0x120/0x210) [<c01915c0>] (expire_timers) from [<c0191acc>] (run_timer_softirq+0xa4/0xdc) [<c0191acc>] (run_timer_softirq) from [<c010168c>] (__do_softirq+0x12c/0x594) I did not notice that as I did not have CONFIG_DEBUG_ATOMIC_SLEEP enabled. And looks like also musb_gadget_queue() suffers from the same problem. Let's fix the issue by using a list of delayed work then call it on resume. Note that we want to do this only when musb core and it's parent devices are awake, and we need to make sure the DSPS glue timer is stopped as noted by Johan Hovold <johan@kernel.org>. Note that we already are re-enabling the timer with mod_timer() in dsps_musb_enable(). Later on we may be able to remove other delayed work in the musb driver and just do it from pending_resume_work. But this should be done only for delayed work that does not have other timing requirements beyond just being run on resume. Fixes: 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS glue layer") Reported-by: Johan Hovold <johan@kernel.org> Reviewed-by: Johan Hovold <johan@kernel.org> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17usb: musb: Fix broken use of static variable for multiple instancesTony Lindgren
We can't use static variable first for checking when musb is initialized when we have multiple musb instances like on am335x. Tested-by: Ladislav Michl <ladis@linux-mips.org> Reviewed-by: Johan Hovold <johan@hovoldconsulting.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17crypto: caam - fix type mismatch warningArnd Bergmann
Building the caam driver on arm64 produces a harmless warning: drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct pointer types lacks a cast We can use min_t to tell the compiler which type we want it to use here. Fixes: 5ecf8ef9103c ("crypto: caam - fix sg dump") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-11-17mwifiex: printk() overflow with 32-byte SSIDsBrian Norris
SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length when we print them out. This can be easily noticed by connecting to a network with a 32-octet SSID: [ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to '0123456789abcdef0123456789abcdef <uninitialized mem>' bssid xx:xx:xx:xx:xx:xx Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Brian Norris <briannorris@chromium.org> Cc: <stable@vger.kernel.org> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()Ricky Liang
kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels(): unreferenced object 0xffffffc0a2914780 (size 192): comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s) hex dump (first 32 bytes): 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@ 07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$.. backtrace: [<ffffffc0003375f4>] create_object+0x164/0x2b4 [<ffffffc0008e3530>] kmemleak_alloc+0x50/0x88 [<ffffffc000335120>] __kmalloc_track_caller+0x1bc/0x264 [<ffffffc00030899c>] kmemdup+0x38/0x64 [<ffffffbffc2311cc>] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex] [<ffffffbffc22ee9c>] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex] [<ffffffbffc22f45c>] mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex] [<ffffffbffc2375d0>] mwifiex_process_sta_event+0x378/0x898 [mwifiex] [<ffffffbffc224dc8>] mwifiex_process_event+0x1a8/0x1e8 [mwifiex] [<ffffffbffc2228f0>] mwifiex_main_process+0x258/0x534 [mwifiex] [<ffffffbffc258858>] 0xffffffbffc258858 [<ffffffc00071ee90>] process_sdio_pending_irqs+0xf8/0x160 [<ffffffc00071efdc>] sdio_irq_thread+0x9c/0x1a4 [<ffffffc000240d08>] kthread+0xf4/0x100 [<ffffffc0002043fc>] ret_from_fork+0xc/0x50 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by: Ricky Liang <jcliang@chromium.org> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17dmaengine: cppi41: More PM runtime fixesTony Lindgren
Fix use of u32 instead of int for checking for negative errors values as pointed out by Dan Carpenter <dan.carpenter@oracle.com>. And while testing the PM runtime error path by randomly returning failed values in runtime resume, I noticed two more places that need fixing: - If pm_runtime_get_sync() fails in probe, we still need to do pm_runtime_put_sync() to keep the use count happy. We could call pm_runtime_put_noidle() on the error path, but we're just going to call pm_runtime_disable() after that so pm_runtime_put_sync() will do what we want - We should print an error if pm_runtime_get_sync() fails in cppi41_dma_alloc_chan_resources() so we know where it happens Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 740b4be3f742 ("dmaengine: cpp41: Fix handling of error path") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-11-17selftests/x86: Add test_vdso to test getcpu()Andy Lutomirski
I'll eventually add tests for more vDSO functions here. Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Megha <megha.dey@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/945cd29901a62a3cc6ea7d6ee5e389ab1ec1ac0c.1479320367.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-17x86/vdso: Use RDPID in preference to LSL when availableAndy Lutomirski
RDPID is a new instruction that reads MSR_TSC_AUX quickly. This should be considerably faster than reading the GDT. Add a cpufeature for it and use it from __vdso_getcpu() when available. Tested-by: Megha Dey <megha.dey@intel.com> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/4f6c3a22012d10f1c65b9ca15800e01b42c7d39d.1479320367.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-17Merge branch 'x86/cpufeature' into x86/asm, to pick up dependencyIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-17locking/core: Provide common cpu_relax_yield() definitionChristian Borntraeger
No need to duplicate the same define everywhere. Since the only user is stop-machine and the only provider is s390, we can use a default implementation of cpu_relax_yield() in sched.h. Suggested-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Noam Camus <noamc@ezchip.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-s390 <linux-s390@vger.kernel.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: sparclinux@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/1479298985-191589-1-git-send-email-borntraeger@de.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-17ssb: Fix error routine when fallback SPROM failsLarry Finger
When there is a CRC error in the SPROM read from the device, the code attempts to handle a fallback SPROM. When this also fails, the driver returns zero rather than an error code. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17x86/dumpstack: Handle NULL stack pointer in show_trace_log_lvl()Josh Poimboeuf
When show_trace_log_lvl() is called from show_regs(), it completely fails to dump the stack. This bug was introduced when show_stack_log_lvl() was removed with the following commit: 0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump") Previous callers of that function now call show_trace_log_lvl() directly. That resulted in a subtle change, in that the 'stack' argument can now be NULL in certain cases. A NULL 'stack' pointer means that the stack dump should start from the topmost stack frame unless 'regs' is valid, in which case it should start from 'regs->sp'. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 0ee1dd9f5e7e ("x86/dumpstack: Remove raw stack dump") Link: http://lkml.kernel.org/r/c551842302a9c222d96a14e42e4003f059509f69.1479362652.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-17rtlwifi: Use dev_kfree_skb_irq instead of kfree_skbWei Yongjun
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled, spin_lock_irqsave() make sure always in irq disable context. So the kfree_skb() should be replaced with dev_kfree_skb_irq(). This is detected by Coccinelle semantic patch. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17cw1200: fix bogus maybe-uninitialized warningArnd Bergmann
On x86, the cw1200 driver produces a rather silly warning about the possible use of the 'ret' variable without an initialization presumably after being confused by the architecture specific definition of WARN_ON: drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’: drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] We have already checked that 'count' is larger than 0 here, so we know that 'ret' is initialized. Changing the 'for' loop into do/while also makes this clear to the compiler. Suggested-by: David Laight <David.Laight@ACULAB.COM> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17wireless: fix bogus maybe-uninitialized warningArnd Bergmann
The hostap_80211_rx() function is supposed to set up the mac addresses for four possible cases, based on two bits of input data. For some reason, gcc decides that it's possible that none of the these four cases apply and the addresses remain uninitialized: drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function ‘hostap_80211_rx’: arch/x86/include/asm/string_32.h:77:14: warning: ‘src’ may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function ‘libipw_rx’: arch/x86/include/asm/string_32.h:77:14: error: ‘dst’ may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)&dst+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized] This warning is clearly nonsense, but changing the last case into 'default' makes it obvious to the compiler too, which avoids the warning and probably leads to better object code too. The same code is duplicated several times in the kernel, so this patch uses the same workaround for all copies. The exact configuration was hit only very rarely in randconfig builds and I only saw it in three drivers, but I assume that all of them are potentially affected, and it's better to keep the code consistent. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17p54: memset(0) whole arrayJiri Slaby
gcc 7 complains: drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan': drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] Fix that by passing the correct size to memset. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17brcmfmac: print name of connect status eventRafał Miłecki
This simplifies debugging. Format %s (%u) comes from similar debugging message in brcmf_fweh_event_worker. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rsi: Host to device command frame vap_capabilites modified with new field ↵Prameela Rani Garnepudi
vap status * Command frame vap_capabilites is modified to use for vap add, vap delete and vap update in firmware, hence new filed vap status is added. * When interface is down this frame needs to be send with vap status delete. Otherwise it is considered as wrong frame for the same interface in firmware. * vap_update status is reserved for future. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rsi: Fix memory leak in module unloadPrameela Rani Garnepudi
Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set. Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in function rsi_mac80211_detach() Memory leak found and fixed for below structures in function rsi_mac80211_detach() * channel list for each supported band * rsi debugfs info Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17wlcore: Allow scans when in AP modeJames Minor
When in AP mode, scans can be done without changing firmware to the multi-role firmware. Allow the interface to scan if forced in the scan request. Signed-off-by: James Minor <james.minor@ni.com> Signed-off-by: Xander Huff <xander.huff@ni.com> Reviewed-by: Ben Shelton <ben.shelton@ni.com> Reviewed-by: Jaeden Amero <jaeden.amero@ni.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rtlwifi: Remove address of Free Software FoundationLarry Finger
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rtlwifi: rtl8192c: Remove address of Free Software FoundationLarry Finger
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rtlwifi: rtl8188ee: Remove address of Free Software FoundationLarry Finger
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rtlwifi: rtl8723ae: Remove address of Free Software FoundationLarry Finger
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rtlwifi: rtl8192cu: Remove address of Free Software FoundationLarry Finger
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rtlwifi: rtl8192ce: Remove address of Free Software FoundationLarry Finger
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-11-17rtlwifi: rtl8192se: Remove address of Free Software FoundationLarry Finger
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>