summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-09-07Merge branch 'for-upstream' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2019-09-06 Here's the main bluetooth-next pull request for the 5.4 kernel. - Cleanups & fixes to btrtl driver - Fixes for Realtek devices in btusb, e.g. for suspend handling - Firmware loading support for BCM4345C5 - hidp_send_message() return value handling fixes - Added support for utilizing Fast Advertising Interval - Various other minor cleanups & fixes Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07nfp: flower: cmsg rtnl locks can timeout reify messagesFred Lotter
Flower control message replies are handled in different locations. The truly high priority replies are handled in the BH (tasklet) context, while the remaining replies are handled in a predefined Linux work queue. The work queue handler orders replies into high and low priority groups, and always start servicing the high priority replies within the received batch first. Reply Type: Rtnl Lock: Handler: CMSG_TYPE_PORT_MOD no BH tasklet (mtu) CMSG_TYPE_TUN_NEIGH no BH tasklet CMSG_TYPE_FLOW_STATS no BH tasklet CMSG_TYPE_PORT_REIFY no WQ high CMSG_TYPE_PORT_MOD yes WQ high (link/mtu) CMSG_TYPE_MERGE_HINT yes WQ low CMSG_TYPE_NO_NEIGH no WQ low CMSG_TYPE_ACTIVE_TUNS no WQ low CMSG_TYPE_QOS_STATS no WQ low CMSG_TYPE_LAG_CONFIG no WQ low A subset of control messages can block waiting for an rtnl lock (from both work queue priority groups). The rtnl lock is heavily contended for by external processes such as systemd-udevd, systemd-network and libvirtd, especially during netdev creation, such as when flower VFs and representors are instantiated. Kernel netlink instrumentation shows that external processes (such as systemd-udevd) often use successive rtnl_trylock() sequences, which can result in an rtnl_lock() blocked control message to starve for longer periods of time during rtnl lock contention, i.e. netdev creation. In the current design a single blocked control message will block the entire work queue (both priorities), and introduce a latency which is nondeterministic and dependent on system wide rtnl lock usage. In some extreme cases, one blocked control message at exactly the wrong time, just before the maximum number of VFs are instantiated, can block the work queue for long enough to prevent VF representor REIFY replies from getting handled in time for the 40ms timeout. The firmware will deliver the total maximum number of REIFY message replies in around 300us. Only REIFY and MTU update messages require replies within a timeout period (of 40ms). The MTU-only updates are already done directly in the BH (tasklet) handler. Move the REIFY handler down into the BH (tasklet) in order to resolve timeouts caused by a blocked work queue waiting on rtnl locks. Signed-off-by: Fred Lotter <frederik.lotter@netronome.com> Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: hns3: make array spec_opcode static const, makes object smallerColin Ian King
Don't populate the array spec_opcode on the stack but instead make it static const. Makes the object code smaller by 48 bytes. Before: text data bss dec hex filename 6914 1040 128 8082 1f92 hns3/hns3vf/hclgevf_cmd.o After: text data bss dec hex filename 6866 1040 128 8034 1f62 hns3/hns3vf/hclgevf_cmd.o (gcc version 9.2.1, amd64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07be2net: make two arrays static const, makes object smallerColin Ian King
Don't populate the arrays on the stack but instead make them static const. Makes the object code smaller by 281 bytes. Before: text data bss dec hex filename 87553 5672 0 93225 16c29 benet/be_cmds.o After: text data bss dec hex filename 87112 5832 0 92944 16b10 benet/be_cmds.o (gcc version 9.2.1, amd64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07ionic: Remove unused including <linux/version.h>YueHaibing
Remove including <linux/version.h> that don't need it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: gso: Fix skb_segment splat when splitting gso_size mangled skb having ↵Shmulik Ladkani
linear-headed frag_list Historically, support for frag_list packets entering skb_segment() was limited to frag_list members terminating on exact same gso_size boundaries. This is verified with a BUG_ON since commit 89319d3801d1 ("net: Add frag_list support to skb_segment"), quote: As such we require all frag_list members terminate on exact MSS boundaries. This is checked using BUG_ON. As there should only be one producer in the kernel of such packets, namely GRO, this requirement should not be difficult to maintain. However, since commit 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper"), the "exact MSS boundaries" assumption no longer holds: An eBPF program using bpf_skb_change_proto() DOES modify 'gso_size', but leaves the frag_list members as originally merged by GRO with the original 'gso_size'. Example of such programs are bpf-based NAT46 or NAT64. This lead to a kernel BUG_ON for flows involving: - GRO generating a frag_list skb - bpf program performing bpf_skb_change_proto() or bpf_skb_adjust_room() - skb_segment() of the skb See example BUG_ON reports in [0]. In commit 13acc94eff12 ("net: permit skb_segment on head_frag frag_list skb"), skb_segment() was modified to support the "gso_size mangling" case of a frag_list GRO'ed skb, but *only* for frag_list members having head_frag==true (having a page-fragment head). Alas, GRO packets having frag_list members with a linear kmalloced head (head_frag==false) still hit the BUG_ON. This commit adds support to skb_segment() for a 'head_skb' packet having a frag_list whose members are *non* head_frag, with gso_size mangled, by disabling SG and thus falling-back to copying the data from the given 'head_skb' into the generated segmented skbs - as suggested by Willem de Bruijn [1]. Since this approach involves the penalty of skb_copy_and_csum_bits() when building the segments, care was taken in order to enable this solution only when required: - untrusted gso_size, by testing SKB_GSO_DODGY is set (SKB_GSO_DODGY is set by any gso_size mangling functions in net/core/filter.c) - the frag_list is non empty, its item is a non head_frag, *and* the headlen of the given 'head_skb' does not match the gso_size. [0] https://lore.kernel.org/netdev/20190826170724.25ff616f@pixies/ https://lore.kernel.org/netdev/9265b93f-253d-6b8c-f2b8-4b54eff1835c@fb.com/ [1] https://lore.kernel.org/netdev/CA+FuTSfVsgNDi7c=GUU8nMg2hWxF2SjCNLXetHeVPdnxAW5K-w@mail.gmail.com/ Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07Merge branch 'stmmac-next'David S. Miller
Jose Abreu says: ==================== net: stmmac: Improvements and fixes for -next Improvements and fixes for recently introduced features. All for -next tree. More info in commit logs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: stmmac: Limit max speeds of XGMAC if asked toJose Abreu
We may have some SoCs that can't achieve XGMAC max speed. Limit it if asked to. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: stmmac: selftests: Add Split Header testJose Abreu
Add a test to validate that Split Header feature is working correctly. It works by using the rececently introduced counter that increments each time a packet with split header is received. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: stmmac: dwmac4: Enable RX Jumbo frame supportJose Abreu
We are already doing it by default in the TX path so we can also enable Jumbo Frame support in the RX path independently of MTU value. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: stmmac: selftests: Set RX tail pointer in Flow Control testJose Abreu
We need to set the RX tail pointer so that RX engine starts working again after finishing the Flow Control test. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: stmmac: selftests: Add missing checks for support of SAJose Abreu
Add checks for support of Source Address Insertion/Replacement before running the test. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07ext4: add missing bigalloc documentation.Ayush Ranjan
There was a broken link for bigalloc. The page https://ext4.wiki.kernel.org/index.php/Bigalloc was not migrated into the current documentation sources. This patch adds the contents of that missing page into the section for Bigalloc itself. Signed-off-by: Ayush Ranjan <ayushr2@illinois.edu> Link: https://lore.kernel.org/r/20190831154419.GA30357@fa19-cs241-404.cs.illinois.edu Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2019-09-07ipmr: remove hard code cache_resolve_queue_len limitHangbin Liu
This is a re-post of previous patch wrote by David Miller[1]. Phil Karn reported[2] that on busy networks with lots of unresolved multicast routing entries, the creation of new multicast group routes can be extremely slow and unreliable. The reason is we hard-coded multicast route entries with unresolved source addresses(cache_resolve_queue_len) to 10. If some multicast route never resolves and the unresolved source addresses increased, there will be no ability to create new multicast route cache. To resolve this issue, we need either add a sysctl entry to make the cache_resolve_queue_len configurable, or just remove cache_resolve_queue_len limit directly, as we already have the socket receive queue limits of mrouted socket, pointed by David. >From my side, I'd perfer to remove the cache_resolve_queue_len limit instead of creating two more(IPv4 and IPv6 version) sysctl entry. [1] https://lkml.org/lkml/2018/7/22/11 [2] https://lkml.org/lkml/2018/7/21/343 v3: instead of remove cache_resolve_queue_len totally, let's only remove the hard code limit when allocate the unresolved cache, as Eric Dumazet suggested, so we don't need to re-count it in other places. v2: hold the mfc_unres_lock while walking the unresolved list in queue_count(), as Nikolay Aleksandrov remind. Reported-by: Phil Karn <karn@ka9q.net> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07ipv6: addrconf_f6i_alloc - fix non-null pointer check to !IS_ERR()Maciej Żenczykowski
Fixes a stupid bug I recently introduced... ip6_route_info_create() returns an ERR_PTR(err) and not a NULL on error. Fixes: d55a2e374a94 ("net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)'") Cc: David Ahern <dsahern@gmail.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Maciej Żenczykowski <maze@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07isdn/capi: check message length in capi_write()Eric Biggers
syzbot reported: BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700 CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313 capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700 do_loop_readv_writev fs/read_write.c:703 [inline] do_iter_write+0x83e/0xd80 fs/read_write.c:961 vfs_writev fs/read_write.c:1004 [inline] do_writev+0x397/0x840 fs/read_write.c:1039 __do_sys_writev fs/read_write.c:1112 [inline] __se_sys_writev+0x9b/0xb0 fs/read_write.c:1109 __x64_sys_writev+0x4a/0x70 fs/read_write.c:1109 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 [...] The problem is that capi_write() is reading past the end of the message. Fix it by checking the message's length in the needed places. Reported-and-tested-by: syzbot+0849c524d9c634f5ae66@syzkaller.appspotmail.com Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07Merge branch 'hv_netvsc-features'David S. Miller
Haiyang Zhang says: ==================== hv_netvsc: Enable sg as tunable, sync offload settings to VF NIC This patch set fixes an issue in SG tuning, and sync offload settings from synthetic NIC to VF NIC. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07hv_netvsc: Sync offloading features to VF NICHaiyang Zhang
VF NIC may go down then come up during host servicing events. This causes the VF NIC offloading feature settings to roll back to the defaults. This patch can synchronize features from synthetic NIC to the VF NIC during ndo_set_features (ethtool -K), and netvsc_register_vf when VF comes back after host events. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Cc: Mark Bloch <markb@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07hv_netvsc: Allow scatter-gather feature to be tunableHaiyang Zhang
In a previous patch, the NETIF_F_SG was missing after the code changes. That caused the SG feature to be "fixed". This patch includes it into hw_features, so it is tunable again. Fixes: 23312a3be999 ("netvsc: negotiate checksum and segmentation parameters") Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07Merge tag 'mlx5-updates-2019-09-05' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2019-09-05 1) Allover mlx5 cleanups 2) Added port congestion counters to ethtool stats: Add 3 counters per priority to ethtool using PPCNT: 2.1) rx_prio[p]_buf_discard - the number of packets discarded by device due to lack of per host receive buffers 2.2) rx_prio[p]_cong_discard - the number of packets discarded by device due to per host congestion 2.3) rx_prio[p]_marked - the number of packets ECN marked by device due to per host congestion ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net/ibmvnic: free reset work of removed device from queueJuliet Kim
Commit 36f1031c51a2 ("ibmvnic: Do not process reset during or after device removal") made the change to exit reset if the driver has been removed, but does not free reset work items of the adapter from queue. Ensure all reset work items are freed when breaking out of the loop early. Fixes: 36f1031c51a2 ("ibmnvic: Do not process reset during or after device removal”) Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07tcp: ulp: fix possible crash in tcp_diag_get_aux_size()Eric Dumazet
tcp_diag_get_aux_size() can be called with sockets in any state. icsk_ulp_ops is only present for full sockets. For SYN_RECV or TIME_WAIT ones we would access garbage. Fixes: 61723b393292 ("tcp: ulp: add functions to dump ulp-specific information") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Luke Hsiao <lukehsiao@google.com> Reported-by: Neal Cardwell <ncardwell@google.com> Cc: Davide Caratti <dcaratti@redhat.com> Acked-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: fib_notifier: move fib_notifier_ops from struct net into per-net structJiri Pirko
No need for fib_notifier_ops to be in struct net. It is used only by fib_notifier as a private data. Use net_generic to introduce per-net fib_notifier struct and move fib_notifier_ops there. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net: phylink: Fix flow control resolutionStefan Chulski
Regarding to IEEE 802.3-2015 standard section 2 28B.3 Priority resolution - Table 28-3 - Pause resolution In case of Local device Pause=1 AsymDir=0, Link partner Pause=1 AsymDir=1, Local device resolution should be enable PAUSE transmit, disable PAUSE receive. And in case of Local device Pause=1 AsymDir=1, Link partner Pause=1 AsymDir=0, Local device resolution should be enable PAUSE receive, disable PAUSE transmit. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Stefan Chulski <stefanc@marvell.com> Reported-by: Shaul Ben-Mayor <shaulb@marvell.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07ethernet: micrel: Use DIV_ROUND_CLOSEST directly to make it readablezhong jiang
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07Merge tag 'tag-chrome-platform-fixes-for-v5.3-rc6' into for-nextBenson Leung
chrome-platform fixes for v5.3-rc6 Fixes: 1. platform/chrome: cros_ec_ishtp: fix crash during suspend - Fixes a kernel crash during suspend/resume of cros_ec_ishtp Signed-off-by: Benson Leung <bleung@chromium.org>
2019-09-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Add nft_reg_store64() and nft_reg_load64() helpers, from Ander Juaristi. 2) Time matching support, also from Ander Juaristi. 3) VLAN support for nfnetlink_log, from Michael Braun. 4) Support for set element deletions from the packet path, also from Ander. 5) Remove __read_mostly from conntrack spinlock, from Li RongQing. 6) Support for updating stateful objects, this also includes the initial client for this infrastructure: the quota extension. A follow up fix for the control plane also comes in this batch. Patches from Fernando Fernandez Mancera. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07net/hamradio/6pack: Fix the size of a sk_buff used in 'sp_bump()'Christophe JAILLET
We 'allocate' 'count' bytes here. In fact, 'dev_alloc_skb' already add some extra space for padding, so a bit more is allocated. However, we use 1 byte for the KISS command, then copy 'count' bytes, so count+1 bytes. Explicitly allocate and use 1 more byte to be safe. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07Merge branch '100GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2019-09-05 This series contains updates to ice driver. Brett fixes the setting of num_q_vectors by using the maximum number between the allocated transmit and receive queues. Anirudh simplifies the code to use a helper function to return the main VSI, which is the first element in the pf->vsi array. Adds a pointer check to prevent a NULL pointer dereference. Adds a check to ensure we do not initialize DCB on devices that are not DCB capable. Does some housekeeping on the code to remove unnecessary indirection and reduce the PF structure by removing elements that are not needed since the values they were storing can be readily gotten from ice_get_avail_*_count()'s. Updates the printed strings to make it easier to search the logs for driver capabilities. Jesse cleans up unnecessary function arguments. Updated the code to use prefetch() to add some efficiency to the driver to avoid a cache miss. Did some housekeeping on the code to remove the configurable transmit work limit via ethtool which ended up creating performance overhead. Made additional performance enhancements by updating the driver to start out with a reasonable number of descriptors by changing the default to 2048. Mitch fixes the reset logic for VFs by clearing VF_MBX_ARQLEN register when the source of the reset is not PFR. Lukasz updates the driver to include a similar fix for the i40e driver by reporting link down for VF's when the PF queues are not enabled. Akeem updates the driver to report the VF link status once we get VF resources so that we can reflect the link status similarly to how the PF reports link speed. Ashish updates the transmit context structure based on recent changes to the hardware specification. Dave updates the DCB logic to allow a delayed registration for MIB change events so that the driver is not accepting events before it is ready for them. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07PCI: Get rid of dev->has_secondary_link flagMika Westerberg
In some systems, the Device/Port Type in the PCI Express Capabilities register incorrectly identifies upstream ports as downstream ports. d0751b98dfa3 ("PCI: Add dev->has_secondary_link to track downstream PCIe links") addressed this by adding pci_dev.has_secondary_link, which is set for downstream ports. But this is confusing because pci_pcie_type() sometimes gives the wrong answer, and it's not obvious that we should use pci_dev.has_secondary_link instead. Reduce the confusion by correcting the type of the port itself so that pci_pcie_type() returns the actual type regardless of what the Device/Port Type register claims it is. Update the users to call pci_pcie_type() and pcie_downstream_port() accordingly, and remove pci_dev.has_secondary_link completely. Link: https://lore.kernel.org/linux-pci/20190703133953.GK128603@google.com/ Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20190822085553.62697-2-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-09-07PCI: Make pcie_downstream_port() available outside of access.cMika Westerberg
pcie_downstream_port() is useful in other places where code needs to determine whether the PCIe port is downstream so make it available outside of access.c. Link: https://lore.kernel.org/r/20190822085553.62697-1-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-09-07Merge tag 'wireless-drivers-next-for-davem-2019-09-07' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.4 Second set of patches for 5.4. Lots of changes for iwlwifi and mt76, but also smaller changes to other drivers. Major changes: iwlwifi * remove broken and unused runtime power management mode for PCIe devices, removes IWLWIFI_PCIE_RTPM Kconfig option as well * support new ACPI value for per-platform antenna gain * support for single antenna diversity * support for new WoWLAN FW API brcmfmac * add reset debugfs file for testing firmware restart mt76 * DFS pattern detector for mt7615 (DFS channels not enabled yet) * Channel Switch Announcement (CSA) support for mt7615 * new device support for mt76x0 * support for more ciphers in mt7615 * smart carrier sense on mt7615 * survey support on mt7615 * multiple interfaces on mt76x02u rtw88 * enable MSI interrupt ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller
Alexei Starovoitov says: ==================== pull-request: bpf 2019-09-06 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) verifier precision tracking fix, from Alexei. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-07libnvdimm: Enable unit test infrastructure compile checksDan Williams
The infrastructure to mock core libnvdimm routines for unit testing purposes is prone to bitrot relative to refactoring of that core. Arrange for the unit test core to be built when CONFIG_COMPILE_TEST=y. This does not result in a functional unit test environment, it is only a helper for 0day to catch unit test build regressions. Note that there are a few x86isms in the implementation, so this does not bother compile testing this architectures other than 64-bit x86. Link: https://lore.kernel.org/r/156763690875.2556198.15786177395425033830.stgit@dwillia2-desk3.amr.corp.intel.com Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07mm, notifier: Catch sleeping/blocking for !blockableDaniel Vetter
We need to make sure implementations don't cheat and don't have a possible schedule/blocking point deeply burried where review can't catch it. I'm not sure whether this is the best way to make sure all the might_sleep() callsites trigger, and it's a bit ugly in the code flow. But it gets the job done. Inspired by an i915 patch series which did exactly that, because the rules haven't been entirely clear to us. Link: https://lore.kernel.org/r/20190826201425.17547-5-daniel.vetter@ffwll.ch Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Reviewed-by: Jérôme Glisse <jglisse@redhat.com> (v4) Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07kernel.h: Add non_block_start/end()Daniel Vetter
In some special cases we must not block, but there's not a spinlock, preempt-off, irqs-off or similar critical section already that arms the might_sleep() debug checks. Add a non_block_start/end() pair to annotate these. This will be used in the oom paths of mmu-notifiers, where blocking is not allowed to make sure there's forward progress. Quoting Michal: "The notifier is called from quite a restricted context - oom_reaper - which shouldn't depend on any locks or sleepable conditionals. The code should be swift as well but we mostly do care about it to make a forward progress. Checking for sleepable context is the best thing we could come up with that would describe these demands at least partially." Peter also asked whether we want to catch spinlocks on top, but Michal said those are less of a problem because spinlocks can't have an indirect dependency upon the page allocator and hence close the loop with the oom reaper. Suggested by Michal Hocko. Link: https://lore.kernel.org/r/20190826201425.17547-4-daniel.vetter@ffwll.ch Acked-by: Christian König <christian.koenig@amd.com> (v1) Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07drm/radeon: guard against calling an unpaired radeon_mn_unregister()Jason Gunthorpe
This check was accidently deleted in the below commit. There are cases where the driver will call unregister even though it hasn't registered anything. CPU 0 Unable to handle kernel paging request at virtual address 0000001c, epc == 808de6d4, ra == 804d32ec Call Trace: [<808de6d4>] mutex_lock+0x8/0x44 [<804d32ec>] radeon_mn_unregister+0x3c/0xb0 [<8041583c>] radeon_gem_object_free+0x18/0x2c [<803a451c>] drm_gem_object_release_handle+0x74/0xac [<803a45d0>] drm_gem_handle_delete+0x7c/0x128 [<803a5bf4>] drm_ioctl_kernel+0xb0/0x108 [<803a5e74>] drm_ioctl+0x200/0x3a8 [<803e07b4>] radeon_drm_ioctl+0x54/0xc0 [<801214dc>] do_vfs_ioctl+0x4e8/0x81c [<80121864>] ksys_ioctl+0x54/0xb0 [<8001100c>] syscall_common+0x34/0x58 Link: https://lore.kernel.org/r/2fc7ef14-e89a-1f2d-381d-1c9b05da02d3@gmail.com Fixes: 534e5f84b7a9 ("drm/radeon: use mmu_notifier_get/put for struct radeon_mn") Reported-by: Petr Cvek <petrcvekcz@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07csky: add missing brackets in a macro for tlb.hJason Gunthorpe
As an earlier patch made the macro argument more complicated, compilation now fails with: In file included from mm/madvise.c:30: mm/madvise.c: In function 'madvise_free_single_vma': arch/csky/include/asm/tlb.h:11:11: error: invalid type argument of '->' (have 'struct mmu_gather') Link: https://lore.kernel.org/r/20190901193601.GB5208@mellanox.com Fixes: 923bfc561e75 ("pagewalk: separate function pointers from iterator data") Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07pagewalk: use lockdep_assert_held for locking validationChristoph Hellwig
Use lockdep to check for held locks instead of using home grown asserts. Link: https://lore.kernel.org/r/20190828141955.22210-4-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07pagewalk: separate function pointers from iterator dataChristoph Hellwig
The mm_walk structure currently mixed data and code. Split out the operations vectors into a new mm_walk_ops structure, and while we are changing the API also declare the mm_walk structure inside the walk_page_range and walk_page_vma functions. Based on patch from Linus Torvalds. Link: https://lore.kernel.org/r/20190828141955.22210-3-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07mm: split out a new pagewalk.h header from mm.hChristoph Hellwig
Add a new header for the two handful of users of the walk_page_range / walk_page_vma interface instead of polluting all users of mm.h with it. Link: https://lore.kernel.org/r/20190828141955.22210-2-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07mm/mmu_notifiers: annotate with might_sleep()Daniel Vetter
Since mmu notifiers don't exist for many processes, but could block in interesting places, add some annotations. This should help make sure the core mm keeps up its end of the mmu notifier contract. The checks here are outside of all notifier checks because of that. They compile away without CONFIG_DEBUG_ATOMIC_SLEEP. Link: https://lore.kernel.org/r/20190826201425.17547-6-daniel.vetter@ffwll.ch Suggested-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07mm/mmu_notifiers: prime lockdepDaniel Vetter
We want to teach lockdep that mmu notifiers can be called from direct reclaim paths, since on many CI systems load might never reach that level (e.g. when just running fuzzer or small functional tests). I've put the annotation into mmu_notifier_register since only when we have mmu notifiers registered is there any point in teaching lockdep about them. Also, we already have a kmalloc(, GFP_KERNEL), so this is safe. Link: https://lore.kernel.org/r/20190826201425.17547-3-daniel.vetter@ffwll.ch Suggested-by: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07mm/mmu_notifiers: add a lockdep map for invalidate_range_start/endDaniel Vetter
This is a similar idea to the fs_reclaim fake lockdep lock. It's fairly easy to provoke a specific notifier to be run on a specific range: Just prep it, and then munmap() it. A bit harder, but still doable, is to provoke the mmu notifiers for all the various callchains that might lead to them. But both at the same time is really hard to reliably hit, especially when you want to exercise paths like direct reclaim or compaction, where it's not easy to control what exactly will be unmapped. By introducing a lockdep map to tie them all together we allow lockdep to see a lot more dependencies, without having to actually hit them in a single challchain while testing. On Jason's suggestion this is is rolled out for both invalidate_range_start and invalidate_range_end. They both have the same calling context, hence we can share the same lockdep map. Note that the annotation for invalidate_ranage_start is outside of the mm_has_notifiers(), to make sure lockdep is informed about all paths leading to this context irrespective of whether mmu notifiers are present for a given context. We don't do that on the invalidate_range_end side to avoid paying the overhead twice, there the lockdep annotation is pushed down behind the mm_has_notifiers() check. Link: https://lore.kernel.org/r/20190826201425.17547-2-daniel.vetter@ffwll.ch Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07Merge tag 'iwlwifi-next-for-kalle-2019-09-06' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Patches intended for v5.4 * Remove (broken) d0i3 support; * Debug infrastructure work continues; * Bump support FW API version to 50; * Fix for the SN value in certain suspend/resume situations; * Some work on new FW scan APIs; * Work on LTR FW APIs; * New FW channel-switch support; * Support new ACPI value for per-platform antenna gain; * Support for single antenna diversity; * Support for new WoWLAN FW API; * Initial refactoring of the device selection code; * A bunch of clean-ups; * Other small fixes and improvements;
2019-09-07ALSA: firewire-lib: remove WARN_ON() at destruction of AMDTP domainTakashi Sakamoto
The destructor of AMDTP domain has WARN_ON() for the list of associated AMDTP stream. Although this reminds a case that developers forget to program consumer drivers to stop AMDTP domain, it hits when AMDTP domain is not initialized yet. This occurs when initialization of sound card fails as well and it's superfluous. This commit removes the WARN_ON. Although the API to AMDTP domain does nothing, it's left for future usage. Fixes: 3ec3d7a3ff106 ("ALSA: firewire-lib: add AMDTP domain structure to handle several isoc contexts") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20190906131414.15370-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-09-07EDAC/amd64: Add PCI device IDs for family 17h, model 70hIsaac Vaughn
Add the new Family 17h Model 70h PCI IDs (device 18h functions 0 and 6) to the AMD64 EDAC module. [ bp: s/f17_base_addr_to_cs_size/f17_addr_mask_to_cs_size/g ] Signed-off-by: Isaac Vaughn <isaac.vaughn@knights.ucf.edu> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: James Morse <james.morse@arm.com> Cc: linux-edac@vger.kernel.org Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Robert Richter <rrichter@marvell.com> Cc: Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/20190906192131.8ced0ca112146f32d82b6cae@knights.ucf.edu
2019-09-06Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fix from James Bottomley: "Just a single lpfc fix adjusting the number of available queues for high CPU count systems" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: lpfc: Raise config max for lpfc_fcp_mq_threshold variable
2019-09-06f2fs: convert inline_data in prior to i_size_writeJaegeuk Kim
In below call path, we change i_size before inline conversion, however, if we failed to convert inline inode, the inode may have wrong i_size which is larger than max inline size, result inline inode corruption. - f2fs_setattr - truncate_setsize - f2fs_convert_inline_inode This patch reorders truncate_setsize() and f2fs_convert_inline_inode() to guarantee inline_data has valid i_size. Fixes: 0cab80ee0c9e ("f2fs: fix to convert inline inode in ->setattr") Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2019-09-06f2fs: fix error path of f2fs_convert_inline_page()Chao Yu
In error path of f2fs_convert_inline_page(), we missed to truncate newly reserved block in .i_addrs[0] once we failed in get_node_info(), fix it. Fixes: 7735730d39d7 ("f2fs: fix to propagate error from __get_meta_page()") Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-18 14:37:54 +0000