aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-04-22RDMA/uverbs: Fix a race with disassociate and exit_mmap()Jason Gunthorpe1-0/+4
If uverbs_user_mmap_disassociate() is called while the mmap is concurrently doing exit_mmap then the ordering of the rdma_user_mmap_entry_put() is not reliable. The put must be done before uvers_user_mmap_disassociate() returns, otherwise there can be a use after free on the ucontext, and a left over entry in the xarray. If the put is not done here then it is done during rdma_umap_close() later. Add the missing put to the error exit path. WARNING: CPU: 7 PID: 7111 at drivers/infiniband/core/rdma_core.c:810 uverbs_destroy_ufile_hw+0x2a5/0x340 [ib_uverbs] Modules linked in: bonding ipip tunnel4 geneve ip6_udp_tunnel udp_tunnel ip6_gre ip6_tunnel tunnel6 ip_gre ip_tunnel gre mlx5_ib mlx5_core mlxfw pci_hyperv_intf act_ct nf_flow_table ptp pps_core rdma_ucm ib_uverbs ib_ipoib ib_umad 8021q garp mrp openvswitch nsh nf_conncount nfsv3 nfs_acl xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype iptable_filter xt_conntrack br_netfilter bridge stp llc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache overlay rpcrdma ib_isert iscsi_target_mod ib_iser kvm_intel ib_srpt iTCO_wdt target_core_mod iTCO_vendor_support kvm ib_srp nf_nat irqbypass crc32_pclmul crc32c_intel nf_conntrack rfkill nf_defrag_ipv6 virtio_net nf_defrag_ipv4 pcspkr ghash_clmulni_intel i2c_i801 net_failover failover i2c_core lpc_ich mfd_core rdma_cm ib_cm iw_cm button ib_core sunrpc sch_fq_codel ip_tables serio_raw [last unloaded: tunnel4] CPU: 7 PID: 7111 Comm: python3 Tainted: G W 5.6.0-rc6-for-upstream-dbg-2020-03-21_06-41-26-18 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:uverbs_destroy_ufile_hw+0x2a5/0x340 [ib_uverbs] Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 74 49 8b 84 24 08 01 00 00 48 85 c0 0f 84 13 ff ff ff 48 89 ef ff d0 e9 09 ff ff ff <0f> 0b e9 77 ff ff ff e8 0f d8 fa e0 e9 c5 fd ff ff e8 05 d8 fa e0 RSP: 0018:ffff88840e0779a0 EFLAGS: 00010286 RAX: dffffc0000000000 RBX: ffff8882a7721c00 RCX: 0000000000000000 RDX: 1ffff11054ee469f RSI: ffffffff8446d7e0 RDI: ffff8882a77234f8 RBP: ffff8882a7723400 R08: ffffed1085c0112c R09: 0000000000000001 R10: 0000000000000001 R11: ffffed1085c0112b R12: ffff888403c30000 R13: 0000000000000002 R14: ffff8882a7721cb0 R15: ffff8882a7721cd0 FS: 00007f2046089700(0000) GS:ffff88842de00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7cfe9a6e20 CR3: 000000040b8ac006 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_uverbs_remove_one+0x273/0x480 [ib_uverbs] ? up_write+0x15c/0x4a0 remove_client_context+0xa6/0xf0 [ib_core] disable_device+0x12d/0x200 [ib_core] ? remove_client_context+0xf0/0xf0 [ib_core] ? mnt_get_count+0x1d0/0x1d0 __ib_unregister_device+0x79/0x150 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] __mlx5_ib_remove+0x91/0x110 [mlx5_ib] ? __mlx5_ib_remove+0x110/0x110 [mlx5_ib] mlx5_remove_device+0x241/0x310 [mlx5_core] mlx5_unregister_device+0x4d/0x1e0 [mlx5_core] mlx5_unload_one+0xc0/0x260 [mlx5_core] remove_one+0x5c/0x160 [mlx5_core] pci_device_remove+0xef/0x2a0 ? pcibios_free_irq+0x10/0x10 device_release_driver_internal+0x1d8/0x470 unbind_store+0x152/0x200 ? sysfs_kf_write+0x3b/0x180 ? sysfs_file_ops+0x160/0x160 kernfs_fop_write+0x284/0x460 ? __sb_start_write+0x243/0x3a0 vfs_write+0x197/0x4a0 ksys_write+0x156/0x1e0 ? __x64_sys_read+0xb0/0xb0 ? do_syscall_64+0x73/0x1330 ? do_syscall_64+0x73/0x1330 do_syscall_64+0xe7/0x1330 ? down_write_nested+0x3e0/0x3e0 ? syscall_return_slowpath+0x970/0x970 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe ? lockdep_hardirqs_off+0x1de/0x2d0 ? trace_hardirqs_off_thunk+0x1a/0x1c entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f20a3ff0cdb Code: 53 48 89 d5 48 89 f3 48 83 ec 18 48 89 7c 24 08 e8 5a fd ff ff 48 89 ea 41 89 c0 48 89 de 48 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 90 fd ff ff 48 RSP: 002b:00007f2046087040 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f2038016df0 RCX: 00007f20a3ff0cdb RDX: 000000000000000d RSI: 00007f2038016df0 RDI: 0000000000000018 RBP: 000000000000000d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000100 R11: 0000000000000293 R12: 00007f2046e29630 R13: 00007f20280035a0 R14: 0000000000000018 R15: 00007f2038016df0 Fixes: c043ff2cfb7f ("RDMA: Connect between the mmap entry and the umap_priv structure") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-04-22RDMA/mlx5: Set GRH fields in query QP on RoCEAharon Landau1-1/+3
GRH fields such as sgid_index, hop limit, et. are set in the QP context when QP is created/modified. Currently, when query QP is performed, we fill the GRH fields only if the GRH bit is set in the QP context, but this bit is not set for RoCE. Adjust the check so we will set all relevant data for the RoCE too. Since this data is returned to userspace, the below is an ABI regression. Fixes: d8966fcd4c25 ("IB/core: Use rdma_ah_attr accessor functions") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Aharon Landau <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-04-22net: phy: microchip_t1: add lan87xx_phy_init to initialize the lan87xx phy.Yuiko Oshino1-0/+171
lan87xx_phy_init() initializes the lan87xx phy hardware including its TC10 Wake-up and Sleep features. Fixes: 3e50d2da5850 ("Add driver for Microchip LAN87XX T1 PHYs") Signed-off-by: Yuiko Oshino <[email protected]> v0->v1: - Add more details in the commit message and source comments. - Update to the latest initialization sequences. - Add access_ereg_modify_changed(). - Fix access_ereg() to access SMI bank correctly. Signed-off-by: David S. Miller <[email protected]>
2020-04-22usb: typec: altmode: Fix typec_altmode_get_partner sometimes returning an ↵Naoki Kiryu1-1/+4
invalid pointer Before this commit, typec_altmode_get_partner would return a const struct typec_altmode * pointing to address 0x08 when to_altmode(adev)->partner was NULL. Add a check for to_altmode(adev)->partner being NULL to fix this. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1785972 Fixes: 5f54a85db5df ("usb: typec: Make sure an alt mode exist before getting its partner") Cc: [email protected] Signed-off-by: Naoki Kiryu <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-22mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllersAdrian Hunter1-0/+3
BIOS writers have begun the practice of setting 40 ohm eMMC driver strength even though the eMMC may not support it, on the assumption that the kernel will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH [offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid. This is done to avoid changing the value for different boards. Putting aside the merits of this approach, it is clear the eMMC's mask of supported driver strengths is more reliable than the value provided by BIOS. Add validation accordingly. Signed-off-by: Adrian Hunter <[email protected]> Fixes: 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-04-22PM: sleep: core: Switch back to async_schedule_dev()Kai-Heng Feng1-1/+1
Commit 8b9ec6b73277 ("PM core: Use new async_schedule_dev command") introduced a new function for better performance. However commit f2a424f6c613 ("PM / core: Introduce dpm_async_fn() helper") went back to the non-optimized version, async_schedule(). So switch back to the sync_schedule_dev() to improve performance Fixes: f2a424f6c613 ("PM / core: Introduce dpm_async_fn() helper") Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-04-22hyper-v: Use UUID API for exporting the GUIDAndy Shevchenko1-2/+2
There is export_guid() function which exports guid_t to the u8 array. Use it instead of open coding variant. This allows to hide the uuid_t internals. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2020-04-22USB: serial: garmin_gps: add sanity checking for data lengthOliver Neukum1-2/+2
We must not process packets shorter than a packet ID Signed-off-by: Oliver Neukum <[email protected]> Reported-and-tested-by: [email protected] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2020-04-22scsi: target/iblock: fix WRITE SAME zeroingDavid Disseldorp1-1/+1
SBC4 specifies that WRITE SAME requests with the UNMAP bit set to zero "shall perform the specified write operation to each LBA specified by the command". Commit 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout") modified the iblock backend to call blkdev_issue_zeroout() when handling WRITE SAME requests with UNMAP=0 and a zero data segment. The iblock blkdev_issue_zeroout() call incorrectly provides a flags parameter of 0 (bool false), instead of BLKDEV_ZERO_NOUNMAP. The bool false parameter reflects the blkdev_issue_zeroout() API prior to commit ee472d835c26 ("block: add a flags argument to (__)blkdev_issue_zeroout") which was merged shortly before 2237498f0b5c. Link: https://lore.kernel.org/r/[email protected] Fixes: 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout") Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: David Disseldorp <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-04-21scsi: qla2xxx: check UNLOADING before posting async workMartin Wilck1-0/+3
qlt_free_session_done() tries to post async PRLO / LOGO, and waits for the completion of these async commands. If UNLOADING is set, this is doomed to timeout, because the async logout command will never complete. The only way to avoid waiting pointlessly is to fail posting these commands in the first place if the driver is in UNLOADING state. In general, posting any command should be avoided when the driver is UNLOADING. With this patch, "rmmod qla2xxx" completes without noticeable delay. Link: https://lore.kernel.org/r/[email protected] Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip") Acked-by: Arun Easi <[email protected]> Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin Wilck <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-04-21scsi: qla2xxx: set UNLOADING before waiting for session deletionMartin Wilck1-18/+14
The purpose of the UNLOADING flag is to avoid port login procedures to continue when a controller is in the process of shutting down. It makes sense to set this flag before starting session teardown. Furthermore, use atomic test_and_set_bit() to avoid the shutdown being run multiple times in parallel. In qla2x00_disable_board_on_pci_error(), the test for UNLOADING is postponed until after the check for an already disabled PCI board. Link: https://lore.kernel.org/r/[email protected] Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip") Reviewed-by: Arun Easi <[email protected]> Reviewed-by: Daniel Wagner <[email protected]> Reviewed-by: Roman Bolshakov <[email protected]> Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin Wilck <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-04-21scsi: core: Allow the state change from SDEV_QUIESCE to SDEV_BLOCKDexuan Cui1-0/+1
The APIs scsi_host_block()/scsi_host_unblock() were recently added by commit 2bb955840c1d ("scsi: core: add scsi_host_(block,unblock) helper function") and so far the APIs are only used by: commit 3d3ca53b1639 ("scsi: aacraid: use scsi_host_(block,unblock) to block I/O"). However, from reading the code, I think the APIs don't really work for aacraid, because, in the resume path of hibernation, when aac_suspend() -> scsi_host_block() is called, scsi_device_quiesce() has set the state to SDEV_QUIESCE, so aac_suspend() -> scsi_host_block() returns -EINVAL. Fix the issue by allowing the state change. Link: https://lore.kernel.org/r/[email protected] Fixes: 2bb955840c1d ("scsi: core: add scsi_host_(block,unblock) helper function") Reviewed-by: Ewan D. Milne <[email protected]> Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Dexuan Cui <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-04-21tty: riscv: Using RISCV_SBI_V01 instead of RISCV_SBIKefeng Wang2-2/+2
As shown in SBI v0.2, the legacy console SBI functions (sbi_console_getchar() and sbi_console_putchar()) are expected to be deprecated; they have no replacement. Let's HVC_RISCV_SBI and SERIAL_EARLYCON_RISCV_SBI depends on RISCV_SBI_V01. Fixes: efca13989250 ("RISC-V: Introduce a new config for SBI v0.1") Signed-off-by: Kefeng Wang <[email protected]> Reviewed-by: Anup Patel <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-04-21net: stmmac: Enable SERDES power up/down sequenceVoon Weifeng3-0/+235
This patch is to enable Intel SERDES power up/down sequence. The SERDES converts 8/10 bits data to SGMII signal. Below is an example of HW configuration for SGMII mode. The SERDES is located in the PHY IF in the diagram below. <-----------------GBE Controller---------->|<--External PHY chip--> +----------+ +----+ +---+ +----------+ | EQoS | <-GMII->| DW | < ------ > |PHY| <-SGMII-> | External | | MAC | |xPCS| |IF | | PHY | +----------+ +----+ +---+ +----------+ ^ ^ ^ ^ | | | | +---------------------MDIO-------------------------+ PHY IF configuration and status registers are accessible through mdio address 0x15 which is defined as mdio_adhoc_addr. During D0, The driver will need to power up PHY IF by changing the power state to P0. Likewise, for D3, the driver sets PHY IF power state to P3. Signed-off-by: Voon Weifeng <[email protected]> Signed-off-by: Ong Boon Leong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-21net: broadcom: convert to devm_platform_ioremap_resource_byname()Dejin Zheng1-22/+11
Use the function devm_platform_ioremap_resource_byname() to simplify source code which calls the functions platform_get_resource_byname() and devm_ioremap_resource(). Remove also a few error messages which became unnecessary with this software refactoring. Suggested-by: Markus Elfring <[email protected]> Signed-off-by: Dejin Zheng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-21macvlan: fix null dereference in macvlan_device_event()Taehee Yoo1-1/+1
In the macvlan_device_event(), the list_first_entry_or_null() is used. This function could return null pointer if there is no node. But, the macvlan module doesn't check the null pointer. So, null-ptr-deref would occur. bond0 | +----+-----+ | | macvlan0 macvlan1 | | dummy0 dummy1 The problem scenario. If dummy1 is removed, 1. ->dellink() of dummy1 is called. 2. NETDEV_UNREGISTER of dummy1 notification is sent to macvlan module. 3. ->dellink() of macvlan1 is called. 4. NETDEV_UNREGISTER of macvlan1 notification is sent to bond module. 5. __bond_release_one() is called and it internally calls dev_set_mac_address(). 6. dev_set_mac_address() calls the ->ndo_set_mac_address() of macvlan1, which is macvlan_set_mac_address(). 7. macvlan_set_mac_address() calls the dev_set_mac_address() with dummy1. 8. NETDEV_CHANGEADDR of dummy1 is sent to macvlan module. 9. In the macvlan_device_event(), it calls list_first_entry_or_null(). At this point, dummy1 and macvlan1 were removed. So, list_first_entry_or_null() will return NULL. Test commands: ip netns add nst ip netns exec nst ip link add bond0 type bond for i in {0..10} do ip netns exec nst ip link add dummy$i type dummy ip netns exec nst ip link add macvlan$i link dummy$i \ type macvlan mode passthru ip netns exec nst ip link set macvlan$i master bond0 done ip netns del nst Splat looks like: [ 40.585687][ T146] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEI [ 40.587249][ T146] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 40.588342][ T146] CPU: 1 PID: 146 Comm: kworker/u8:2 Not tainted 5.7.0-rc1+ #532 [ 40.589299][ T146] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 40.590469][ T146] Workqueue: netns cleanup_net [ 40.591045][ T146] RIP: 0010:macvlan_device_event+0x4e2/0x900 [macvlan] [ 40.591905][ T146] Code: 00 00 00 00 00 fc ff df 80 3c 06 00 0f 85 45 02 00 00 48 89 da 48 b8 00 00 00 00 00 fc ff d2 [ 40.594126][ T146] RSP: 0018:ffff88806116f4a0 EFLAGS: 00010246 [ 40.594783][ T146] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 40.595653][ T146] RDX: 0000000000000000 RSI: ffff88806547ddd8 RDI: ffff8880540f1360 [ 40.596495][ T146] RBP: ffff88804011a808 R08: fffffbfff4fb8421 R09: fffffbfff4fb8421 [ 40.597377][ T146] R10: ffffffffa7dc2107 R11: 0000000000000000 R12: 0000000000000008 [ 40.598186][ T146] R13: ffff88804011a000 R14: ffff8880540f1000 R15: 1ffff1100c22de9a [ 40.599012][ T146] FS: 0000000000000000(0000) GS:ffff888067800000(0000) knlGS:0000000000000000 [ 40.600004][ T146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 40.600665][ T146] CR2: 00005572d3a807b8 CR3: 000000005fcf4003 CR4: 00000000000606e0 [ 40.601485][ T146] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 40.602461][ T146] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 40.603443][ T146] Call Trace: [ 40.603871][ T146] ? nf_tables_dump_setelem+0xa0/0xa0 [nf_tables] [ 40.604587][ T146] ? macvlan_uninit+0x100/0x100 [macvlan] [ 40.605212][ T146] ? __module_text_address+0x13/0x140 [ 40.605842][ T146] notifier_call_chain+0x90/0x160 [ 40.606477][ T146] dev_set_mac_address+0x28e/0x3f0 [ 40.607117][ T146] ? netdev_notify_peers+0xc0/0xc0 [ 40.607762][ T146] ? __module_text_address+0x13/0x140 [ 40.608440][ T146] ? notifier_call_chain+0x90/0x160 [ 40.609097][ T146] ? dev_set_mac_address+0x1f0/0x3f0 [ 40.609758][ T146] dev_set_mac_address+0x1f0/0x3f0 [ 40.610402][ T146] ? __local_bh_enable_ip+0xe9/0x1b0 [ 40.611071][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding] [ 40.611823][ T146] ? netdev_notify_peers+0xc0/0xc0 [ 40.612461][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding] [ 40.613213][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding] [ 40.613963][ T146] ? __local_bh_enable_ip+0xe9/0x1b0 [ 40.614631][ T146] ? bond_time_in_interval.isra.31+0x90/0x90 [bonding] [ 40.615484][ T146] ? __bond_release_one+0x9f0/0x12c0 [bonding] [ 40.616230][ T146] __bond_release_one+0x9f0/0x12c0 [bonding] [ 40.616949][ T146] ? bond_enslave+0x47c0/0x47c0 [bonding] [ 40.617642][ T146] ? lock_downgrade+0x730/0x730 [ 40.618218][ T146] ? check_flags.part.42+0x450/0x450 [ 40.618850][ T146] ? __mutex_unlock_slowpath+0xd0/0x670 [ 40.619519][ T146] ? trace_hardirqs_on+0x30/0x180 [ 40.620117][ T146] ? wait_for_completion+0x250/0x250 [ 40.620754][ T146] bond_netdev_event+0x822/0x970 [bonding] [ 40.621460][ T146] ? __module_text_address+0x13/0x140 [ 40.622097][ T146] notifier_call_chain+0x90/0x160 [ 40.622806][ T146] rollback_registered_many+0x660/0xcf0 [ 40.623522][ T146] ? netif_set_real_num_tx_queues+0x780/0x780 [ 40.624290][ T146] ? notifier_call_chain+0x90/0x160 [ 40.624957][ T146] ? netdev_upper_dev_unlink+0x114/0x180 [ 40.625686][ T146] ? __netdev_adjacent_dev_unlink_neighbour+0x30/0x30 [ 40.626421][ T146] ? mutex_is_locked+0x13/0x50 [ 40.627016][ T146] ? unregister_netdevice_queue+0xf2/0x240 [ 40.627663][ T146] unregister_netdevice_many.part.134+0x13/0x1b0 [ 40.628362][ T146] default_device_exit_batch+0x2d9/0x390 [ 40.628987][ T146] ? unregister_netdevice_many+0x40/0x40 [ 40.629615][ T146] ? dev_change_net_namespace+0xcb0/0xcb0 [ 40.630279][ T146] ? prepare_to_wait_exclusive+0x2e0/0x2e0 [ 40.630943][ T146] ? ops_exit_list.isra.9+0x97/0x140 [ 40.631554][ T146] cleanup_net+0x441/0x890 [ ... ] Fixes: e289fd28176b ("macvlan: fix the problem when mac address changes for passthru mode") Reported-by: [email protected] Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-21e1000: remove unneeded conversion to boolJason Yan1-1/+1
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/ethernet/intel/e1000/e1000_main.c:1479:44-49: WARNING: conversion to bool not needed here Signed-off-by: Jason Yan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-21i40e: Remove unneeded conversion to boolJason Yan1-2/+2
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/ethernet/intel/i40e/i40e_main.c:1614:52-57: WARNING: conversion to bool not needed here drivers/net/ethernet/intel/i40e/i40e_main.c:11439:52-57: WARNING: conversion to bool not needed here Signed-off-by: Jason Yan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-21ptp: Remove unneeded conversion to boolJason Yan1-2/+2
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/ptp/ptp_ines.c:403:55-60: WARNING: conversion to bool not needed here drivers/ptp/ptp_ines.c:404:55-60: WARNING: conversion to bool not needed here Signed-off-by: Jason Yan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-21Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds25-69/+107
Pull virtio fixes and cleanups from Michael Tsirkin: - Some bug fixes - Cleanup a couple of issues that surfaced meanwhile - Disable vhost on ARM with OABI for now - to be fixed fully later in the cycle or in the next release. * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (24 commits) vhost: disable for OABI virtio: drop vringh.h dependency virtio_blk: add a missing include virtio-balloon: Avoid using the word 'report' when referring to free page hinting virtio-balloon: make virtballoon_free_page_report() static vdpa: fix comment of vdpa_register_device() vdpa: make vhost, virtio depend on menu vdpa: allow a 32 bit vq alignment drm/virtio: fix up for include file changes remoteproc: pull in slab.h rpmsg: pull in slab.h virtio_input: pull in slab.h remoteproc: pull in slab.h virtio-rng: pull in slab.h virtgpu: pull in uaccess.h tools/virtio: make asm/barrier.h self contained tools/virtio: define aligned attribute virtio/test: fix up after IOTLB changes vhost: Create accessors for virtqueues private_data vdpasim: Return status in vdpasim_get_status ...
2020-04-21xhci: Don't clear hub TT buffer on ep0 protocol stallMathias Nyman1-5/+11
The default control endpoint ep0 can return a STALL indicating the device does not support the control transfer requests. This is called a protocol stall and does not halt the endpoint. xHC behaves a bit different. Its internal endpoint state will always be halted on any stall, even if the device side of the endpiont is not halted. So we do need to issue the reset endpoint command to clear the xHC host intenal endpoint halt state, but should not request the HS hub to clear the TT buffer unless device side of endpoint is halted. Clearing the hub TT buffer at protocol stall caused ep0 to become unresponsive for some FS/LS devices behind HS hubs, and class drivers failed to set the interface due to timeout: usb 1-2.1: 1:1: usb_set_interface failed (-110) Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Cc: <[email protected]> # v5.3 Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-21xhci: prevent bus suspend if a roothub port detected a over-current conditionMathias Nyman1-0/+9
Suspending the bus and host controller while a port is in a over-current condition may halt the host. Also keep the roothub running if over-current is active. Cc: <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-21xhci: Fix handling halted endpoint even if endpoint ring appears emptyMathias Nyman3-10/+39
If a class driver cancels its only URB then the endpoint ring buffer will appear empty to the xhci driver. xHC hardware may still process cached TRBs, and complete with a STALL, halting the endpoint. This halted endpoint was not handled correctly by xhci driver as events on empty rings were all assumed to be spurious events. xhci driver refused to restart the ring with EP_HALTED flag set, so class driver was never informed the endpoint halted even if it queued new URBs. The host side of the endpoint needs to be reset, and dequeue pointer should be moved in order to clear the cached TRBs and resetart the endpoint. Small adjustments in finding the new dequeue pointer are needed to support the case of stall on an empty ring and unknown current TD. Cc: <[email protected]> cc: Jeremy Compostella <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-21iwlwifi: fix WGDS check when WRDS is disabledLuca Coelho2-16/+18
In the reference BIOS implementation, WRDS can be disabled without disabling WGDS. And this happens in most cases where WRDS is disabled, causing the WGDS without WRDS check and issue an error. To avoid this issue, we change the check so that we only considered it an error if the WRDS entry doesn't exist. If the entry (or the selected profile is disabled for any other reason), we just silently ignore WGDS. Cc: [email protected] # 4.14+ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205513 Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20200417133700.72ad25c3998b.I875d935cefd595ed7f640ddcfc7bc802627d2b7f@changeid
2020-04-21iwlwifi: mvm: fix inactive TID removal return value usageJohannes Berg1-2/+2
The function iwl_mvm_remove_inactive_tids() returns bool, so we should just check "if (ret)", not "if (ret >= 0)" (which would do nothing useful here). We obviously therefore cannot use the return value of the function for the free_queue, we need to use the queue (i) we're currently dealing with instead. Cc: [email protected] # v5.4+ Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20200417100405.9d862ed72535.I9e27ccc3ee3c8855fc13682592b571581925dfbd@changeid
2020-04-21iwlwifi: mvm: Do not declare support for ACK Enabled AggregationIlan Peer1-4/+2
As this was not supposed to be enabled to begin with. Cc: [email protected] # v4.19+ Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20200417100405.53dbc3c6c36b.Idfe118546b92cc31548b2211472a5303c7de5909@changeid
2020-04-21iwlwifi: mvm: limit maximum queue appropriatelyJohannes Berg2-3/+8
Due to some hardware issues, queue 31 isn't usable on devices that have 32 queues (7000, 8000, 9000 families), which is correctly reflected in the configuration and TX queue initialization. However, the firmware API and queue allocation code assumes that there are 32 queues, and if something actually attempts to use #31 this leads to a NULL-pointer dereference since it's not allocated. Fix this by limiting to 31 in the IWL_MVM_DQA_MAX_DATA_QUEUE, and also add some code to catch this earlier in the future, if the configuration changes perhaps. Cc: [email protected] # v4.9+ Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20200417100405.98a79be2db6a.I3a4af6b03b87a6bc18db9b1ff9a812f397bee1fc@changeid
2020-04-21iwlwifi: pcie: indicate correct RB size to deviceJohannes Berg1-4/+14
In the context info, we need to indicate the correct RB size to the device so that it will not think we have 4k when we only use 2k. This seems to not have caused any issues right now, likely because the hardware no longer supports putting multiple entries into a single RB, and practically all of the entries should be smaller than 2k. Nevertheless, it's a bug, and we must advertise the right size to the device. Note that right now we can only tell it 2k vs. 4k, so for the cases where we have more, still use 4k. This needs to be fixed by the firmware first. Signed-off-by: Johannes Berg <[email protected]> Fixes: cfdc20efebdc ("iwlwifi: pcie: use partial pages if applicable") Cc: [email protected] # v5.6 Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20200417100405.ae6cd345764f.I0985c55223decf70182b9ef1d8edf4179f537853@changeid
2020-04-21iwlwifi: mvm: beacon statistics shouldn't go backwardsMordechay Goodstein1-2/+11
We reset statistics also in case that we didn't reassoc so in this cases keep last beacon counter. Cc: [email protected] # v4.19+ Signed-off-by: Mordechay Goodstein <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20200417100405.1f9142751fbc.Ifbfd0f928a0a761110b8f4f2ca5483a61fb21131@changeid
2020-04-21iwlwifi: pcie: actually release queue memory in TVQMJohannes Berg1-0/+3
The iwl_trans_pcie_dyn_txq_free() function only releases the frames that may be left on the queue by calling iwl_pcie_gen2_txq_unmap(), but doesn't actually free the DMA ring or byte-count tables for the queue. This leads to pretty large memory leaks (at least before my queue size improvements), in particular in monitor/sniffer mode on channel hopping since this happens on every channel change. This was also now more evident after the move to a DMA pool for the byte count tables, showing messages such as BUG iwlwifi:bc (...): Objects remaining in iwlwifi:bc on __kmem_cache_shutdown() This fixes https://bugzilla.kernel.org/show_bug.cgi?id=206811. Signed-off-by: Johannes Berg <[email protected]> Fixes: 6b35ff91572f ("iwlwifi: pcie: introduce a000 TX queues management") Cc: [email protected] # v4.14+ Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20200417100405.f5f4c4193ec1.Id5feebc9b4318041913a9c89fc1378bb5454292c@changeid
2020-04-21Merge tag 'zynqmp-soc-for-v5.7-rc3' of https://github.com/Xilinx/linux-xlnx ↵Arnd Bergmann2-3/+3
into arm/fixes arm64: soc: ZynqMP SoC fixes for v5.7 - Fix firmware driver dependency - Fix one spare warning in firmware driver * tag 'zynqmp-soc-for-v5.7-rc3' of https://github.com/Xilinx/linux-xlnx: firmware: xilinx: make firmware_debugfs_root static drivers: soc: xilinx: fix firmware driver Kconfig dependency Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-04-21Drivers: hv: Move AEOI determination to architecture dependent codeMichael Kelley1-5/+1
Hyper-V on ARM64 doesn't provide a flag for the AEOI recommendation in ms_hyperv.hints, so having the test in architecture independent code doesn't work. Resolve this by moving the check of the flag to an architecture dependent helper function. No functionality is changed. Signed-off-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2020-04-21iwlwifi: actually check allocated conf_tlv pointerChris Rorvick1-1/+1
Commit 71bc0334a637 ("iwlwifi: check allocated pointer when allocating conf_tlvs") attempted to fix a typoe introduced by commit 17b809c9b22e ("iwlwifi: dbg: move debug data to a struct") but does not implement the check correctly. Fixes: 71bc0334a637 ("iwlwifi: check allocated pointer when allocating conf_tlvs") Tweeted-by: @grsecurity Signed-off-by: Chris Rorvick <[email protected]> Signed-off-by: Sedat Dilek <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-04-20net/mlx5e: Get the latest values from counters in switchdev modeZhu Yanjun1-1/+6
In the switchdev mode, when running "cat /sys/class/net/NIC/statistics/tx_packets", the ppcnt register is accessed to get the latest values. But currently this command can not get the correct values from ppcnt. From firmware manual, before getting the 802_3 counters, the 802_3 data layout should be set to the ppcnt register. When the command "cat /sys/class/net/NIC/statistics/tx_packets" is run, before updating 802_3 data layout with ppcnt register, the monitor counters are tested. The test result will decide the 802_3 data layout is updated or not. Actually the monitor counters do not support to monitor rx/tx stats of 802_3 in switchdev mode. So the rx/tx counters change will not trigger monitor counters. So the 802_3 data layout will not be updated in ppcnt register. Finally this command can not get the latest values from ppcnt register with 802_3 data layout. Fixes: 5c7e8bbb0257 ("net/mlx5e: Use monitor counters for update stats") Signed-off-by: Zhu Yanjun <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-20net/mlx5: Kconfig: convert imply usage to weak dependencySaeed Mahameed1-4/+4
MLX5_CORE uses the 'imply' keyword to depend on VXLAN, PTP_1588_CLOCK, MLXFW and PCI_HYPERV_INTERFACE. This was useful to force vxlan, ptp, etc.. to be reachable to mlx5 regardless of their config states. Due to the changes in the cited commit below, the semantics of 'imply' was changed to not force any restriction on the implied config. As a result of this change, the compilation of MLX5_CORE=y and VXLAN=m would result in undefined references, as VXLAN now would stay as 'm'. To fix this we change MLX5_CORE to have a weak dependency on these modules/configs and make sure they are reachable, by adding: depend on symbol || !symbol. For example: VXLAN=m MLX5_CORE=y, this will force MLX5_CORE to m Fixes: def2fbffe62c ("kconfig: allow symbols implied by y to become m") Signed-off-by: Saeed Mahameed <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Nicolas Pitre <[email protected]> Cc: Arnd Bergmann <[email protected]> Reported-by: Randy Dunlap <[email protected]>
2020-04-20net/mlx5e: Don't trigger IRQ multiple times on XSK wakeup to avoid WQ overrunsMaxim Mikityanskiy4-5/+15
XSK wakeup function triggers NAPI by posting a NOP WQE to a special XSK ICOSQ. When the application floods the driver with wakeup requests by calling sendto() in a certain pattern that ends up in mlx5e_trigger_irq, the XSK ICOSQ may overflow. Multiple NOPs are not required and won't accelerate the process, so avoid posting a second NOP if there is one already on the way. This way we also avoid increasing the queue size (which might not help anyway). Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-20net/mlx5: CT: Change idr to xarray to protect parallel tuple id allocationPaul Blakey1-11/+12
After allowing parallel tuple insertion, we get the following trace: [ 5505.142249] ------------[ cut here ]------------ [ 5505.148155] WARNING: CPU: 21 PID: 13313 at lib/radix-tree.c:581 delete_node+0x16c/0x180 [ 5505.295553] CPU: 21 PID: 13313 Comm: kworker/u50:22 Tainted: G OE 5.6.0+ #78 [ 5505.304824] Hardware name: Supermicro Super Server/X10DRT-P, BIOS 2.0b 03/30/2017 [ 5505.313740] Workqueue: nf_flow_table_offload flow_offload_work_handler [nf_flow_table] [ 5505.323257] RIP: 0010:delete_node+0x16c/0x180 [ 5505.349862] RSP: 0018:ffffb19184eb7b30 EFLAGS: 00010282 [ 5505.356785] RAX: 0000000000000000 RBX: ffff904ac95b86d8 RCX: ffff904b6f938838 [ 5505.365190] RDX: 0000000000000000 RSI: ffff904ac954b908 RDI: ffff904ac954b920 [ 5505.373628] RBP: ffff904b4ac13060 R08: 0000000000000001 R09: 0000000000000000 [ 5505.382155] R10: 0000000000000000 R11: 0000000000000040 R12: 0000000000000000 [ 5505.390527] R13: ffffb19184eb7bfc R14: ffff904b6bef5800 R15: ffff90482c1203c0 [ 5505.399246] FS: 0000000000000000(0000) GS:ffff904c2fc80000(0000) knlGS:0000000000000000 [ 5505.408621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5505.415739] CR2: 00007f5d27006010 CR3: 0000000058c10006 CR4: 00000000001626e0 [ 5505.424547] Call Trace: [ 5505.428429] idr_alloc_u32+0x7b/0xc0 [ 5505.433803] mlx5_tc_ct_entry_add_rule+0xbf/0x950 [mlx5_core] [ 5505.441354] ? mlx5_fc_create+0x23c/0x370 [mlx5_core] [ 5505.448225] mlx5_tc_ct_block_flow_offload+0x874/0x10b0 [mlx5_core] [ 5505.456278] ? mlx5_tc_ct_block_flow_offload+0x63d/0x10b0 [mlx5_core] [ 5505.464532] nf_flow_offload_tuple.isra.21+0xc5/0x140 [nf_flow_table] [ 5505.472286] ? __kmalloc+0x217/0x2f0 [ 5505.477093] ? flow_rule_alloc+0x1c/0x30 [ 5505.482117] flow_offload_work_handler+0x1d0/0x290 [nf_flow_table] [ 5505.489674] ? process_one_work+0x17c/0x580 [ 5505.494922] process_one_work+0x202/0x580 [ 5505.500082] ? process_one_work+0x17c/0x580 [ 5505.505696] worker_thread+0x4c/0x3f0 [ 5505.510458] kthread+0x103/0x140 [ 5505.514989] ? process_one_work+0x580/0x580 [ 5505.520616] ? kthread_bind+0x10/0x10 [ 5505.525837] ret_from_fork+0x3a/0x50 [ 5505.570841] ---[ end trace 07995de9c56d6831 ]--- This happens from parallel deletes/adds to idr, as idr isn't protected. Fix that by using xarray as the tuple_ids allocator instead of idr. Fixes: 7da182a998d6 ("netfilter: flowtable: Use work entry per offload command") Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Paul Blakey <[email protected]> Reviewed-by: Oz Shlomo <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-20net/mlx5: Fix failing fw tracer allocation on s390Niklas Schnelle1-3/+3
On s390 FORCE_MAX_ZONEORDER is 9 instead of 11, thus a larger kzalloc() allocation as done for the firmware tracer will always fail. Looking at mlx5_fw_tracer_save_trace(), it is actually the driver itself that copies the debug data into the trace array and there is no need for the allocation to be contiguous in physical memory. We can therefor use kvzalloc() instead of kzalloc() and get rid of the large contiguous allcoation. Fixes: f53aaa31cce7 ("net/mlx5: FW tracer, implement tracer logic") Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-04-21tpm/tpm_tis: Free IRQ if probing failsJarkko Sakkinen1-1/+7
Call disable_interrupts() if we have to revert to polling in order not to unnecessarily reserve the IRQ for the life-cycle of the driver. Cc: [email protected] # 4.5.x Reported-by: Hans de Goede <[email protected]> Fixes: e3837e74a06d ("tpm_tis: Refactor the interrupt setup") Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-21tpm: fix wrong return value in tpm_pcr_extendTianjia Zhang1-1/+1
For the algorithm that does not match the bank, a positive value EINVAL is returned here. I think this is a typo error. It is necessary to return an error value. Cc: [email protected] # 5.4.x Fixes: 9f75c8224631 ("KEYS: trusted: correctly initialize digests and fix locking issue") Signed-off-by: Tianjia Zhang <[email protected]> Reviewed-by: Roberto Sassu <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-21tpm: ibmvtpm: retry on H_CLOSED in tpm_ibmvtpm_send()George Wilson1-63/+73
tpm_ibmvtpm_send() can fail during PowerVM Live Partition Mobility resume with an H_CLOSED return from ibmvtpm_send_crq(). The PAPR says, 'The "partner partition suspended" transport event disables the associated CRQ such that any H_SEND_CRQ hcall() to the associated CRQ returns H_Closed until the CRQ has been explicitly enabled using the H_ENABLE_CRQ hcall.' This patch adds a check in tpm_ibmvtpm_send() for an H_CLOSED return from ibmvtpm_send_crq() and in that case calls tpm_ibmvtpm_resume() and retries the ibmvtpm_send_crq() once. Cc: [email protected] # 3.7.x Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Reported-by: Linh Pham <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Signed-off-by: George Wilson <[email protected]> Tested-by: Linh Pham <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-21tpm: Export tpm2_get_cc_attrs_tbl for ibmvtpm driver as moduleStefan Berger1-0/+1
This patch fixes the following problem when the ibmvtpm driver is built as a module: ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko] undefined! make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1 make: *** [Makefile:1298: modules] Error 2 Fixes: 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2") Signed-off-by: Stefan Berger <[email protected]> Reported-by: Sachin Sant <[email protected]> Tested-by: Sachin Sant <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-04-20team: fix hang in team_mode_get()Taehee Yoo1-0/+4
When team mode is changed or set, the team_mode_get() is called to check whether the mode module is inserted or not. If the mode module is not inserted, it calls the request_module(). In the request_module(), it creates a child process, which is the "modprobe" process and waits for the done of the child process. At this point, the following locks were used. down_read(&cb_lock()); by genl_rcv() genl_lock(); by genl_rcv_msc() rtnl_lock(); by team_nl_cmd_options_set() mutex_lock(&team->lock); by team_nl_team_get() Concurrently, the team module could be removed by rmmod or "modprobe -r" The __exit function of team module is team_module_exit(), which calls team_nl_fini() and it tries to acquire following locks. down_write(&cb_lock); genl_lock(); Because of the genl_lock() and cb_lock, this process can't be finished earlier than request_module() routine. The problem secenario. CPU0 CPU1 team_mode_get request_module() modprobe -r team_mode_roundrobin team <--(B) modprobe team <--(A) team_mode_roundrobin By request_module(), the "modprobe team_mode_roundrobin" command will be executed. At this point, the modprobe process will decide that the team module should be inserted before team_mode_roundrobin. Because the team module is being removed. By the module infrastructure, the same module insert/remove operations can't be executed concurrently. So, (A) waits for (B) but (B) also waits for (A) because of locks. So that the hang occurs at this point. Test commands: while : do teamd -d & killall teamd & modprobe -rv team_mode_roundrobin & done The approach of this patch is to hold the reference count of the team module if the team module is compiled as a module. If the reference count of the team module is not zero while request_module() is being called, the team module will not be removed at that moment. So that the above scenario could not occur. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: Taehee Yoo <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20cxgb4: fix large delays in PTP synchronizationRahul Lakkireddy2-21/+9
Fetching PTP sync information from mailbox is slow and can take up to 10 milliseconds. Reduce this unnecessary delay by directly reading the information from the corresponding registers. Fixes: 9c33e4208bce ("cxgb4: Add PTP Hardware Clock (PHC) support") Signed-off-by: Manoj Malviya <[email protected]> Signed-off-by: Rahul Lakkireddy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20vfio: avoid possible overflow in vfio_iommu_type1_pin_pagesYan Zhao1-1/+1
add parentheses to avoid possible vaddr overflow. Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices") Signed-off-by: Yan Zhao <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
2020-04-20vfio: checking of validity of user vaddr in vfio_dma_rwYan Zhao1-2/+2
instead of calling __copy_to/from_user(), use copy_to_from_user() to ensure vaddr range is a valid user address range before accessing them. Fixes: 8d46c0cca5f4 ("vfio: introduce vfio_dma_rw to read/write a range of IOVAs") Signed-off-by: Yan Zhao <[email protected]> Reported-by: Kees Cook <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
2020-04-20net: stmmac: dwmac-meson8b: Add missing boundary to RGMII TX clock arrayMarc Zyngier1-0/+1
Running with KASAN on a VIM3L systems leads to the following splat when probing the Ethernet device: ================================================================== BUG: KASAN: global-out-of-bounds in _get_maxdiv+0x74/0xd8 Read of size 4 at addr ffffa000090615f4 by task systemd-udevd/139 CPU: 1 PID: 139 Comm: systemd-udevd Tainted: G E 5.7.0-rc1-00101-g8624b7577b9c #781 Hardware name: amlogic w400/w400, BIOS 2020.01-rc5 03/12/2020 Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x20/0x30 dump_stack+0xec/0x148 print_address_description.isra.12+0x70/0x35c __kasan_report+0xfc/0x1d4 kasan_report+0x4c/0x68 __asan_load4+0x9c/0xd8 _get_maxdiv+0x74/0xd8 clk_divider_bestdiv+0x74/0x5e0 clk_divider_round_rate+0x80/0x1a8 clk_core_determine_round_nolock.part.9+0x9c/0xd0 clk_core_round_rate_nolock+0xf0/0x108 clk_hw_round_rate+0xac/0xf0 clk_factor_round_rate+0xb8/0xd0 clk_core_determine_round_nolock.part.9+0x9c/0xd0 clk_core_round_rate_nolock+0xf0/0x108 clk_core_round_rate_nolock+0xbc/0x108 clk_core_set_rate_nolock+0xc4/0x2e8 clk_set_rate+0x58/0xe0 meson8b_dwmac_probe+0x588/0x72c [dwmac_meson8b] platform_drv_probe+0x78/0xd8 really_probe+0x158/0x610 driver_probe_device+0x140/0x1b0 device_driver_attach+0xa4/0xb0 __driver_attach+0xcc/0x1c8 bus_for_each_dev+0xf4/0x168 driver_attach+0x3c/0x50 bus_add_driver+0x238/0x2e8 driver_register+0xc8/0x1e8 __platform_driver_register+0x88/0x98 meson8b_dwmac_driver_init+0x28/0x1000 [dwmac_meson8b] do_one_initcall+0xa8/0x328 do_init_module+0xe8/0x368 load_module+0x3300/0x36b0 __do_sys_finit_module+0x120/0x1a8 __arm64_sys_finit_module+0x4c/0x60 el0_svc_common.constprop.2+0xe4/0x268 do_el0_svc+0x98/0xa8 el0_svc+0x24/0x68 el0_sync_handler+0x12c/0x318 el0_sync+0x158/0x180 The buggy address belongs to the variable: div_table.63646+0x34/0xfffffffffffffa40 [dwmac_meson8b] Memory state around the buggy address: ffffa00009061480: fa fa fa fa 00 00 00 01 fa fa fa fa 00 00 00 00 ffffa00009061500: 05 fa fa fa fa fa fa fa 00 04 fa fa fa fa fa fa >ffffa00009061580: 00 03 fa fa fa fa fa fa 00 00 00 00 00 00 fa fa ^ ffffa00009061600: fa fa fa fa 00 01 fa fa fa fa fa fa 01 fa fa fa ffffa00009061680: fa fa fa fa 00 01 fa fa fa fa fa fa 04 fa fa fa ================================================================== Digging into this indeed shows that the clock divider array is lacking a final fence, and that the clock subsystems goes in the weeds. Oh well. Let's add the empty structure that indicates the end of the array. Fixes: bd6f48546b9c ("net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs") Signed-off-by: Marc Zyngier <[email protected]> Cc: Martin Blumenstingl <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20net: systemport: Omit superfluous error message in bcm_sysport_probe()Tang Bin1-1/+0
In the function bcm_sysport_probe(), when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here. Signed-off-by: Tang Bin <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-20tty/sysrq: Export sysrq_mask(), sysrq_toggle_support()Dmitry Safonov1-0/+2
Build fix for serial_core being module: ERROR: modpost: "sysrq_toggle_support" [drivers/tty/serial/serial_core.ko] undefined! ERROR: modpost: "sysrq_mask" [drivers/tty/serial/serial_core.ko] undefined! Fixes: eaee41727e6d ("sysctl/sysrq: Remove __sysrq_enabled copy") Cc: Jiri Slaby <[email protected]> Reported-by: "kernelci.org bot" <[email protected]> Reported-by: Michael Ellerman <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Dmitry Safonov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-20drm/i915/dpcd_bl: Unbreak enable_dpcd_backlight modparamLyude Paul1-0/+1
Looks like I accidentally made it so you couldn't force DPCD backlight support on, whoops. Fix that. Signed-off-by: Lyude Paul <[email protected]> Fixes: 17f5d57915be ("drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel") Cc: Adam Jackson <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: "Ville Syrjälä" <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit d7fb38ae36a2dc97924b075ad1d1a88792777ea9) Signed-off-by: Rodrigo Vivi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.