commit 6ccc74c083c0d472ac64f3733f5b7bf3f99f261e Author: Greg Kroah-Hartman Date: Tue Apr 21 09:05:05 2020 +0200 Linux 5.4.34 commit b538aacc94006412059471a94a80f2f58bf6ab3d Author: John Allen Date: Thu Apr 9 10:34:29 2020 -0500 x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE commit bdf89df3c54518eed879d8fac7577fcfb220c67e upstream. Future AMD CPUs will have microcode patches that exceed the default 4K patch size. Raise our limit. Signed-off-by: John Allen Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org # v4.14.. Link: https://lkml.kernel.org/r/20200409152931.GA685273@mojo.amd.com Signed-off-by: Greg Kroah-Hartman commit 856a74fd7e61a2d2cdb88198967b4ab5ce172a25 Author: Maurizio Lombardi Date: Fri Mar 13 18:06:55 2020 +0100 scsi: target: fix hang when multiple threads try to destroy the same iscsi session [ Upstream commit 57c46e9f33da530a2485fa01aa27b6d18c28c796 ] A number of hangs have been reported against the target driver; they are due to the fact that multiple threads may try to destroy the iscsi session at the same time. This may be reproduced for example when a "targetcli iscsi/iqn.../tpg1 disable" command is executed while a logout operation is underway. When this happens, two or more threads may end up sleeping and waiting for iscsit_close_connection() to execute "complete(session_wait_comp)". Only one of the threads will wake up and proceed to destroy the session structure, the remaining threads will hang forever. Note that if the blocked threads are somehow forced to wake up with complete_all(), they will try to free the same iscsi session structure destroyed by the first thread, causing double frees, memory corruptions etc... With this patch, the threads that want to destroy the iscsi session will increase the session refcount and will set the "session_close" flag to 1; then they wait for the driver to close the remaining active connections. When the last connection is closed, iscsit_close_connection() will wake up all the threads and will wait for the session's refcount to reach zero; when this happens, iscsit_close_connection() will destroy the session structure because no one is referencing it anymore. INFO: task targetcli:5971 blocked for more than 120 seconds. Tainted: P OE 4.15.0-72-generic #81~16.04.1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. targetcli D 0 5971 1 0x00000080 Call Trace: __schedule+0x3d6/0x8b0 ? vprintk_func+0x44/0xe0 schedule+0x36/0x80 schedule_timeout+0x1db/0x370 ? __dynamic_pr_debug+0x8a/0xb0 wait_for_completion+0xb4/0x140 ? wake_up_q+0x70/0x70 iscsit_free_session+0x13d/0x1a0 [iscsi_target_mod] iscsit_release_sessions_for_tpg+0x16b/0x1e0 [iscsi_target_mod] iscsit_tpg_disable_portal_group+0xca/0x1c0 [iscsi_target_mod] lio_target_tpg_enable_store+0x66/0xe0 [iscsi_target_mod] configfs_write_file+0xb9/0x120 __vfs_write+0x1b/0x40 vfs_write+0xb8/0x1b0 SyS_write+0x5c/0xe0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Link: https://lore.kernel.org/r/20200313170656.9716-3-mlombard@redhat.com Reported-by: Matt Coleman Tested-by: Matt Coleman Tested-by: Rahul Kundu Signed-off-by: Maurizio Lombardi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 992e469b4c44aae98672c9b6739f51ce30c2e1fa Author: Maurizio Lombardi Date: Fri Mar 13 18:06:54 2020 +0100 scsi: target: remove boilerplate code [ Upstream commit e49a7d994379278d3353d7ffc7994672752fb0ad ] iscsit_free_session() is equivalent to iscsit_stop_session() followed by a call to iscsit_close_session(). Link: https://lore.kernel.org/r/20200313170656.9716-2-mlombard@redhat.com Tested-by: Rahul Kundu Signed-off-by: Maurizio Lombardi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4b3380e007b219879c4e65dafae9bbbec2bea344 Author: Reinette Chatre Date: Tue Mar 17 09:26:45 2020 -0700 x86/resctrl: Fix invalid attempt at removing the default resource group commit b0151da52a6d4f3951ea24c083e7a95977621436 upstream. The default resource group ("rdtgroup_default") is associated with the root of the resctrl filesystem and should never be removed. New resource groups can be created as subdirectories of the resctrl filesystem and they can be removed from user space. There exists a safeguard in the directory removal code (rdtgroup_rmdir()) that ensures that only subdirectories can be removed by testing that the directory to be removed has to be a child of the root directory. A possible deadlock was recently fixed with 334b0f4e9b1b ("x86/resctrl: Fix a deadlock due to inaccurate reference"). This fix involved associating the private data of the "mon_groups" and "mon_data" directories to the resource group to which they belong instead of NULL as before. A consequence of this change was that the original safeguard code preventing removal of "mon_groups" and "mon_data" found in the root directory failed resulting in attempts to remove the default resource group that ends in a BUG: kernel BUG at mm/slub.c:3969! invalid opcode: 0000 [#1] SMP PTI Call Trace: rdtgroup_rmdir+0x16b/0x2c0 kernfs_iop_rmdir+0x5c/0x90 vfs_rmdir+0x7a/0x160 do_rmdir+0x17d/0x1e0 do_syscall_64+0x55/0x1d0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by improving the directory removal safeguard to ensure that subdirectories of the resctrl root directory can only be removed if they are a child of the resctrl filesystem's root _and_ not associated with the default resource group. Fixes: 334b0f4e9b1b ("x86/resctrl: Fix a deadlock due to inaccurate reference") Reported-by: Sai Praneeth Prakhya Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov Tested-by: Sai Praneeth Prakhya Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/884cbe1773496b5dbec1b6bd11bb50cffa83603d.1584461853.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman commit 3652782e3a87984efd24adf8efcb33e89778acc9 Author: James Morse Date: Fri Feb 21 16:21:05 2020 +0000 x86/resctrl: Preserve CDP enable over CPU hotplug commit 9fe0450785abbc04b0ed5d3cf61fcdb8ab656b4b upstream. Resctrl assumes that all CPUs are online when the filesystem is mounted, and that CPUs remember their CDP-enabled state over CPU hotplug. This goes wrong when resctrl's CDP-enabled state changes while all the CPUs in a domain are offline. When a domain comes online, enable (or disable!) CDP to match resctrl's current setting. Fixes: 5ff193fbde20 ("x86/intel_rdt: Add basic resctrl filesystem support") Suggested-by: Reinette Chatre Signed-off-by: James Morse Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20200221162105.154163-1-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman commit 6b5e8e7cbe242183ab9f8298c8644fcfe6182a96 Author: Grygorii Strashko Date: Wed Apr 8 22:15:32 2020 +0300 irqchip/ti-sci-inta: Fix processing of masked irqs commit 3688b0db5c331f4ec3fa5eb9f670a4b04f530700 upstream. The ti_sci_inta_irq_handler() does not take into account INTA IRQs state (masked/unmasked) as it uses INTA_STATUS_CLEAR_j register to get INTA IRQs status, which provides raw status value. This causes hard IRQ handlers to be called or threaded handlers to be scheduled many times even if corresponding INTA IRQ is masked. Above, first of all, affects the LEVEL interrupts processing and causes unexpected behavior up the system stack or crash. Fix it by using the Interrupt Masked Status INTA_STATUSM_j register which provides masked INTA IRQs status. Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver") Signed-off-by: Grygorii Strashko Signed-off-by: Marc Zyngier Reviewed-by: Lokesh Vutla Link: https://lore.kernel.org/r/20200408191532.31252-1-grygorii.strashko@ti.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9d2759006e29130b50842810516e3dc9bdb7e07d Author: Jan Kara Date: Tue Mar 31 12:50:16 2020 +0200 ext4: do not zeroout extents beyond i_disksize commit 801674f34ecfed033b062a0f217506b93c8d5e8a upstream. We do not want to create initialized extents beyond end of file because for e2fsck it is impossible to distinguish them from a case of corrupted file size / extent tree and so it complains like: Inode 12, i_size is 147456, should be 163840. Fix? no Code in ext4_ext_convert_to_initialized() and ext4_split_convert_extents() try to make sure it does not create initialized extents beyond inode size however they check against inode->i_size which is wrong. They should instead check against EXT4_I(inode)->i_disksize which is the current inode size on disk. That's what e2fsck is going to see in case of crash before all dirty data is written. This bug manifests as generic/456 test failure (with recent enough fstests where fsx got fixed to properly pass FALLOC_KEEP_SIZE_FL flags to the kernel) when run with dioread_lock mount option. CC: stable@vger.kernel.org Fixes: 21ca087a3891 ("ext4: Do not zero out uninitialized extents beyond i_size") Reviewed-by: Lukas Czerner Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Link: https://lore.kernel.org/r/20200331105016.8674-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 653b425309524e6c21a9252d7ae07da0f11068d5 Author: Hans de Goede Date: Tue Apr 7 20:11:16 2020 +0200 i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHT commit d79294d0de12ddd1420110813626d691f440b86f upstream. We already set DPM_FLAG_SMART_PREPARE, so we completely skip all callbacks (other then prepare) where possible, quoting from dw_i2c_plat_prepare(): /* * If the ACPI companion device object is present for this device, it * may be accessed during suspend and resume of other devices via I2C * operation regions, so tell the PM core and middle layers to avoid * skipping system suspend/resume callbacks for it in that case. */ return !has_acpi_companion(dev); Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend() to leave the controller runtime-suspended even if dw_i2c_plat_prepare() returned 0. Leaving the controller runtime-suspended normally, when the I2C controller is suspended during the suspend_late phase, is not an issue because the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it. But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c leaves the controller alive until the suspend_noirq phase, because it may be used by the _PS3 ACPI methods of PCI devices and PCI devices are left powered on until the suspend_noirq phase. Between the suspend_late and resume_early phases runtime-pm is disabled. So for any ACPI I2C OPRegion accesses done after the suspend_late phase, the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the controller is left runtime-suspended. i2c_dw_xfer() has a check to catch this condition (rather then waiting for the I2C transfer to timeout because the controller is suspended). acpi_subsys_suspend() leaving the controller runtime-suspended in combination with an ACPI I2C OPRegion access done after the suspend_late phase triggers this check, leading to the following error being logged on a Bay Trail based Lenovo Thinkpad 8 tablet: [ 93.275882] i2c_designware 80860F41:00: Transfer while suspended [ 93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280 ... [ 93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred [ 93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280 ... [ 93.276340] Call Trace: [ 93.276366] __i2c_transfer+0x121/0x520 [ 93.276379] i2c_transfer+0x4c/0x100 [ 93.276392] i2c_acpi_space_handler+0x219/0x510 [ 93.276408] ? up+0x40/0x60 [ 93.276419] ? i2c_acpi_notify+0x130/0x130 [ 93.276433] acpi_ev_address_space_dispatch+0x1e1/0x252 ... So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses to work until the suspend_noirq phase, we need the controller to be runtime-resumed during the suspend phase if it is runtime-suspended suspended at that time. This means that we must not set the DPM_FLAG_SMART_SUSPEND on these platforms. On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag to make sure the controller stays functional until the suspend_noirq phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND flag when that flag is set. Cc: stable@vger.kernel.org Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers") Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Rafael J. Wysocki Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit e2b80bf26956f7b8e2271bc772a28a75d9978a4d Author: Prike Liang Date: Mon Apr 13 21:41:14 2020 +0800 drm/amdgpu: fix the hw hang during perform system reboot and reset commit b2a7e9735ab2864330be9d00d7f38c961c28de5d upstream. The system reboot failed as some IP blocks enter power gate before perform hw resource destory. Meanwhile use unify interface to set device CGPG to ungate state can simplify the amdgpu poweroff or reset ungate guard. Fixes: 487eca11a321ef ("drm/amdgpu: fix gfx hang during suspend with video playback (v2)") Signed-off-by: Prike Liang Tested-by: Mengbing Wang Tested-by: Paul Menzel Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 251f13126e232ad61cd404c682f16a7060b1b70f Author: Sergei Lopatin Date: Wed Jun 26 14:56:59 2019 +0500 drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled commit 8c7f0a44b4b4ef16df8f44fbaee6d1f5d1593c83 upstream. Should prevent flicker if PP_OVERDRIVE_MASK is set. bug: https://bugs.freedesktop.org/show_bug.cgi?id=102646 bug: https://bugs.freedesktop.org/show_bug.cgi?id=108941 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1088 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/628 Signed-off-by: Sergei Lopatin Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit eecd70c77ff3d01ebadba93b1d7608ec8dad90dd Author: Maxim Mikityanskiy Date: Mon Nov 4 12:02:14 2019 +0200 net/mlx5e: Use preactivate hook to set the indirection table [ Upstream commit fe867cac9e1967c553e4ac2aece5fc8675258010 ] mlx5e_ethtool_set_channels updates the indirection table before switching to the new channels. If the switch fails, the indirection table is new, but the channels are old, which is wrong. Fix it by using the preactivate hook of mlx5e_safe_switch_channels to update the indirection table at the stage when nothing can fail anymore. As the code that updates the indirection table is now encapsulated into a new function, use that function in the attach flow when the driver has to reduce the number of channels, and prepare the code for the next commit. Fixes: 85082dba0a ("net/mlx5e: Correctly handle RSS indirection table when changing number of channels") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 57f578bce415ecada803c0620efbe965a538780f Author: Maxim Mikityanskiy Date: Thu Oct 31 09:39:34 2019 +0200 net/mlx5e: Rename hw_modify to preactivate [ Upstream commit dca147b3dce5abb5284ff747211960fd2db5ec2e ] mlx5e_safe_switch_channels accepts a callback to be called before activating new channels. It is intended to configure some hardware parameters in cases where channels are recreated because some configuration has changed. Recently, this callback has started being used to update the driver's internal MLX5E_STATE_XDP_OPEN flag, and the following patches also intend to use this callback for software preparations. This patch renames the hw_modify callback to preactivate, so that the name fits better. Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 67284c11399f3ef64b368ccd00cad89decdbb835 Author: Maxim Mikityanskiy Date: Tue Sep 3 17:38:43 2019 +0300 net/mlx5e: Encapsulate updating netdev queues into a function [ Upstream commit c2c95271f9f39ea9b34db2301b3b6c5105cdb447 ] As a preparation for one of the following commits, create a function to encapsulate the code that notifies the kernel about the new amount of RX and TX queues. The code will be called multiple times in the next commit. Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit cae385538886a353bd3429294ceca98dc969982d Author: Tuomas Tynkkynen Date: Fri Apr 10 15:32:57 2020 +0300 mac80211_hwsim: Use kstrndup() in place of kasprintf() commit 7ea862048317aa76d0f22334202779a25530980c upstream. syzbot reports a warning: precision 33020 too large WARNING: CPU: 0 PID: 9618 at lib/vsprintf.c:2471 set_precision+0x150/0x180 lib/vsprintf.c:2471 vsnprintf+0xa7b/0x19a0 lib/vsprintf.c:2547 kvasprintf+0xb2/0x170 lib/kasprintf.c:22 kasprintf+0xbb/0xf0 lib/kasprintf.c:59 hwsim_del_radio_nl+0x63a/0x7e0 drivers/net/wireless/mac80211_hwsim.c:3625 genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline] ... entry_SYSCALL_64_after_hwframe+0x49/0xbe Thus it seems that kasprintf() with "%.*s" format can not be used for duplicating a string with arbitrary length. Replace it with kstrndup(). Note that later this string is limited to NL80211_WIPHY_NAME_MAXLEN == 64, but the code is simpler this way. Reported-by: syzbot+6693adf1698864d21734@syzkaller.appspotmail.com Reported-by: syzbot+a4aee3f42d7584d76761@syzkaller.appspotmail.com Cc: stable@kernel.org Signed-off-by: Tuomas Tynkkynen Link: https://lore.kernel.org/r/20200410123257.14559-1-tuomas.tynkkynen@iki.fi [johannes: add note about length limit] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a8ce3412e8a22279e1bdc81c3c2bacd3785c1577 Author: Sumit Garg Date: Tue Apr 7 15:40:55 2020 +0530 mac80211: fix race in ieee80211_register_hw() commit 52e04b4ce5d03775b6a78f3ed1097480faacc9fd upstream. A race condition leading to a kernel crash is observed during invocation of ieee80211_register_hw() on a dragonboard410c device having wcn36xx driver built as a loadable module along with a wifi manager in user-space waiting for a wifi device (wlanX) to be active. Sequence diagram for a particular kernel crash scenario: user-space ieee80211_register_hw() ieee80211_tasklet_handler() ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | |<---phy0----wiphy_register() | |-----iwd if_add---->| | | |<---IRQ----(RX packet) | Kernel crash | | due to unallocated | | workqueue. | | | | | alloc_ordered_workqueue() | | | | | Misc wiphy init. | | | | | ieee80211_if_add() | | | | As evident from above sequence diagram, this race condition isn't specific to a particular wifi driver but rather the initialization sequence in ieee80211_register_hw() needs to be fixed. So re-order the initialization sequence and the updated sequence diagram would look like: user-space ieee80211_register_hw() ieee80211_tasklet_handler() ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | alloc_ordered_workqueue() | | | | | Misc wiphy init. | | | | |<---phy0----wiphy_register() | |-----iwd if_add---->| | | |<---IRQ----(RX packet) | | | | ieee80211_if_add() | | | | Cc: stable@vger.kernel.org Signed-off-by: Sumit Garg Link: https://lore.kernel.org/r/1586254255-28713-1-git-send-email-sumit.garg@linaro.org [Johannes: fix rtnl imbalances] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 21350f28b2265e0475f17b81280b1e9feff988a9 Author: Johannes Berg Date: Sun Apr 12 00:40:30 2020 +0200 nl80211: fix NL80211_ATTR_FTM_RESPONDER policy commit 0e012b4e4b5ec8e064be3502382579dd0bb43269 upstream. The nested policy here should be established using the NLA_POLICY_NESTED() macro so the length is properly filled in. Cc: stable@vger.kernel.org Fixes: 81e54d08d9d8 ("cfg80211: support FTM responder configuration/statistics") Link: https://lore.kernel.org/r/20200412004029.9d0722bb56c8.Ie690bfcc4a1a61ff8d8ca7e475d59fcaa52fb2da@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit aa5b11bb333ca433af0bc679cfbfd98a9c9fa4a5 Author: Josef Bacik Date: Thu Apr 2 15:51:18 2020 -0400 btrfs: check commit root generation in should_ignore_root commit 4d4225fc228e46948486d8b8207955f0c031b92e upstream. Previously we would set the reloc root's last snapshot to transid - 1. However there was a problem with doing this, and we changed it to setting the last snapshot to the generation of the commit node of the fs root. This however broke should_ignore_root(). The assumption is that if we are in a generation newer than when the reloc root was created, then we would find the reloc root through normal backref lookups, and thus can ignore any fs roots we find with an old enough reloc root. Now that the last snapshot could be considerably further in the past than before, we'd end up incorrectly ignoring an fs root. Thus we'd find no nodes for the bytenr we were searching for, and we'd fail to relocate anything. We'd loop through the relocate code again and see that there were still used space in that block group, attempt to relocate those bytenr's again, fail in the same way, and just loop like this forever. This is tricky in that we have to not modify the fs root at all during this time, so we need to have a block group that has data in this fs root that is not shared by any other root, which is why this has been difficult to reproduce. Fixes: 054570a1dc94 ("Btrfs: fix relocation incorrectly dropping data references") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0026e356e51ab3b54322eeb445c75a087ede5b9d Author: Xiao Yang Date: Tue Apr 14 09:51:45 2020 +0800 tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation commit 0bbe7f719985efd9adb3454679ecef0984cb6800 upstream. Traced event can trigger 'snapshot' operation(i.e. calls snapshot_trigger() or snapshot_count_trigger()) when register_snapshot_trigger() has completed registration but doesn't allocate buffer for 'snapshot' event trigger. In the rare case, 'snapshot' operation always detects the lack of allocated buffer so make register_snapshot_trigger() allocate buffer first. trigger-snapshot.tc in kselftest reproduces the issue on slow vm: ----------------------------------------------------------- cat trace ... ftracetest-3028 [002] .... 236.784290: sched_process_fork: comm=ftracetest pid=3028 child_comm=ftracetest child_pid=3036 <...>-2875 [003] .... 240.460335: tracing_snapshot_instance_cond: *** SNAPSHOT NOT ALLOCATED *** <...>-2875 [003] .... 240.460338: tracing_snapshot_instance_cond: *** stopping trace here! *** ----------------------------------------------------------- Link: http://lkml.kernel.org/r/20200414015145.66236-1-yangx.jy@cn.fujitsu.com Cc: stable@vger.kernel.org Fixes: 93e31ffbf417a ("tracing: Add 'snapshot' event trigger command") Signed-off-by: Xiao Yang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit a0aaafe7ce4bedbfce1f92dc8b4060a0c7eec820 Author: Vasily Averin Date: Tue Apr 14 21:33:16 2020 +0100 keys: Fix proc_keys_next to increase position index commit 86d32f9a7c54ad74f4514d7fef7c847883207291 upstream. If seq_file .next function does not change position index, read after some lseek can generate unexpected output: $ dd if=/proc/keys bs=1 # full usual output 0f6bfdf5 I--Q--- 2 perm 3f010000 1000 1000 user 4af2f79ab8848d0a: 740 1fb91b32 I--Q--- 3 perm 1f3f0000 1000 65534 keyring _uid.1000: 2 27589480 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 2f33ab67 I--Q--- 152 perm 3f030000 0 0 keyring _ses: 2 33f1d8fa I--Q--- 4 perm 3f030000 1000 1000 keyring _ses: 1 3d427fda I--Q--- 2 perm 3f010000 1000 1000 user 69ec44aec7678e5a: 740 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1 521+0 records in 521+0 records out 521 bytes copied, 0,00123769 s, 421 kB/s But a read after lseek in middle of last line results in the partial last line and then a repeat of the final line: $ dd if=/proc/keys bs=500 skip=1 dd: /proc/keys: cannot skip to specified offset g _uid_ses.1000: 1 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1 0+1 records in 0+1 records out 97 bytes copied, 0,000135035 s, 718 kB/s and a read after lseek beyond end of file results in the last line being shown: $ dd if=/proc/keys bs=1000 skip=1 # read after lseek beyond end of file dd: /proc/keys: cannot skip to specified offset 3ead4096 I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1 0+1 records in 0+1 records out 76 bytes copied, 0,000119981 s, 633 kB/s See https://bugzilla.kernel.org/show_bug.cgi?id=206283 Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...") Signed-off-by: Vasily Averin Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f32a339e0321cdfbe8cab7e2d9359bd6120384eb Author: Mark Rutland Date: Tue Apr 14 11:42:48 2020 +0100 arm64: vdso: don't free unallocated pages commit 9cc3d0c6915aee5140f8335d41bbc3ff1b79aa4e upstream. The aarch32_vdso_pages[] array never has entries allocated in the C_VVAR or C_VDSO slots, and as the array is zero initialized these contain NULL. However in __aarch32_alloc_vdso_pages() when aarch32_alloc_kuser_vdso_page() fails we attempt to free the page whose struct page is at NULL, which is obviously nonsensical. This patch removes the erroneous page freeing. Fixes: 7c1deeeb0130 ("arm64: compat: VDSO setup for compat layer") Cc: # 5.3.x- Cc: Vincenzo Frascino Acked-by: Will Deacon Signed-off-by: Mark Rutland Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 5209e5f05bf218da317476ebea5d4d6a5319ef66 Author: Takashi Iwai Date: Sun Apr 12 10:13:31 2020 +0200 ALSA: usb-audio: Check mapping at creating connector controls, too commit 934b96594ed66b07dbc7e576d28814466df3a494 upstream. Add the mapping check to build_connector_control() so that the device specific quirk can provide the node to skip for the badly behaving connector controls. As an example, ALC1220-VB-based codec implements the skip entry for the broken SPDIF connector detection. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: Link: https://lore.kernel.org/r/20200412081331.4742-5-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 250db03053923d30f21143f052b542de626f1683 Author: Takashi Iwai Date: Sun Apr 12 10:13:30 2020 +0200 ALSA: usb-audio: Don't create jack controls for PCM terminals commit 7dc3c5a0172e6c0449502103356c3628d05bc0e0 upstream. Some funky firmwares set the connector flag even on PCM terminals although it doesn't make sense (and even actually the firmware doesn't react properly!). Let's skip creation of jack controls in such a case. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: Link: https://lore.kernel.org/r/20200412081331.4742-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aae6e154680f4e6247b0fbc2ced659e2f9f2e4d0 Author: Takashi Iwai Date: Sun Apr 12 10:13:29 2020 +0200 ALSA: usb-audio: Don't override ignore_ctl_error value from the map commit 3507245b82b4362dc9721cbc328644905a3efa22 upstream. The mapping table may contain also ignore_ctl_error flag for devices that are known to behave wild. Since this flag always writes the card's own ignore_ctl_error flag, it overrides the value already set by the module option, so it doesn't follow user's expectation. Let's fix the code not to clear the flag that has been set by user. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: Link: https://lore.kernel.org/r/20200412081331.4742-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9acfd1ac016a3d32686723454d4b6812dcae4703 Author: Takashi Iwai Date: Sun Apr 12 10:13:28 2020 +0200 ALSA: usb-audio: Filter error from connector kctl ops, too commit 48cc42973509afac24e83d6edc23901d102872d1 upstream. The ignore_ctl_error option should filter the error at kctl accesses, but there was an overlook: mixer_ctl_connector_get() returns an error from the request. This patch covers the forgotten code path and apply filter_error() properly. The locking error is still returned since this is a fatal error that has to be reported even with ignore_ctl_error option. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: Link: https://lore.kernel.org/r/20200412081331.4742-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0eb7bcf3ad329562bb560deeb82638ccad492b2a Author: Adam Barber Date: Fri Apr 10 17:00:32 2020 +0800 ALSA: hda/realtek - Enable the headset mic on Asus FX505DT commit 4963d66b8a26c489958063abb6900ea6ed8e4836 upstream. On Asus FX505DT with Realtek ALC233, the headset mic is connected to pin 0x19, with default 0x411111f0. Enable headset mic by reconfiguring the pin to an external mic associated with the headphone on 0x21. Mic jack detection was also found to be working. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207131 Signed-off-by: Adam Barber Cc: Link: https://lore.kernel.org/r/20200410090032.2759-1-barberadam995@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 549a48900d8e26e08e449e6c6a4362d4850a9239 Author: Colin Ian King Date: Sat Feb 8 22:07:20 2020 +0000 ASoC: Intel: mrfld: return error codes when an error occurs commit 3025571edd9df653e1ad649f0638368a39d1bbb5 upstream. Currently function sst_platform_get_resources always returns zero and error return codes set by the function are never returned. Fix this by returning the error return code in variable ret rather than the hard coded zero. Addresses-Coverity: ("Unused value") Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Signed-off-by: Colin Ian King Acked-by: Cezary Rojewski Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200208220720.36657-1-colin.king@canonical.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 86ec55651fd2db6d35e24d332726d76714455360 Author: Colin Ian King Date: Tue Nov 19 11:36:40 2019 +0000 ASoC: Intel: mrfld: fix incorrect check on p->sink commit f5e056e1e46fcbb5f74ce560792aeb7d57ce79e6 upstream. The check on p->sink looks bogus, I believe it should be p->source since the following code blocks are related to p->source. Fix this by replacing p->sink with p->source. Fixes: 24c8d14192cc ("ASoC: Intel: mrfld: add DSP core controls") Signed-off-by: Colin Ian King Addresses-Coverity: ("Copy-paste error") Link: https://lore.kernel.org/r/20191119113640.166940-1-colin.king@canonical.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 538b623fed6dbf2f38442fcf5e77b67e11b9944e Author: Thinh Nguyen Date: Thu Mar 5 13:23:49 2020 -0800 usb: dwc3: gadget: Don't clear flags before transfer ended commit a114c4ca64bd522aec1790c7e5c60c882f699d8f upstream. We track END_TRANSFER command completion. Don't clear transfer started/ended flag prematurely. Otherwise, we'd run into the problem with restarting transfer before END_TRANSFER command finishes. Fixes: 6d8a019614f3 ("usb: dwc3: gadget: check for Missed Isoc from event status") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 3bffb20603cd9b8a3a5f955bec031014ebad4c29 Author: Angus Ainslie (Purism) Date: Thu Feb 27 14:17:26 2020 +0100 arm64: dts: librem5-devkit: add a vbus supply to usb0 commit dde061b865598ad91f50140760e1d224e5045db9 upstream. Without a VBUS supply the dwc3 driver won't go into otg mode. Fixes: eb4ea0857c83 ("arm64: dts: fsl: librem5: Add a device tree for the Librem5 devkit") Signed-off-by: Angus Ainslie (Purism) Signed-off-by: Martin Kepplinger Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 3a8dc1e91561ffe54534d7f4b9f404114064fa9d Author: Oleksandr Suvorov Date: Tue Feb 4 13:11:47 2020 +0200 ARM: dts: imx7-colibri: fix muxing of usbc_det pin commit 7007f2eca0f258710899ca486da00546d03db0ed upstream. USB_C_DET pin shouldn't be in ethernet group. Creating a separate group allows one to use this pin as an USB ID pin. Fixes: b326629f25b7 ("ARM: dts: imx7: add Toradex Colibri iMX7S/iMX7D suppor") Signed-off-by: Oleksandr Suvorov Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit c2c5d07090d4f41d992a792000353fb80c70cc41 Author: Claudiu Beznea Date: Fri Jan 17 13:36:48 2020 +0200 clk: at91: usb: use proper usbs_mask commit d7a83d67a1694c42cc95fc0755d823f7ca3bfcfb upstream. Use usbs_mask passed as argument. The usbs_mask is different for SAM9X60. Fixes: 2423eeaead6f8 ("clk: at91: usb: Add sam9x60 support") Signed-off-by: Claudiu Beznea Link: https://lkml.kernel.org/r/1579261009-4573-4-git-send-email-claudiu.beznea@microchip.com Acked-by: Alexandre Belloni Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 90c1f740ddf87893430c0c764c437f482737e1e9 Author: Claudiu Beznea Date: Fri Jan 17 13:36:47 2020 +0200 clk: at91: sam9x60: fix usb clock parents commit 43b203d32b77d1b1b2209e22837f49767020553e upstream. SAM9X60's USB clock has 3 parents: plla, upll and main_osc. Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver") Signed-off-by: Claudiu Beznea Link: https://lkml.kernel.org/r/1579261009-4573-3-git-send-email-claudiu.beznea@microchip.com Acked-by: Alexandre Belloni Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit c874d9d116d816d36eb1bb1be28909aa6d538860 Author: Josh Triplett Date: Sat Mar 28 15:34:15 2020 -0700 ext4: fix incorrect inodes per group in error message commit b9c538da4e52a7b79dfcf4cfa487c46125066dfb upstream. If ext4_fill_super detects an invalid number of inodes per group, the resulting error message printed the number of blocks per group, rather than the number of inodes per group. Fix it to print the correct value. Fixes: cd6bb35bf7f6d ("ext4: use more strict checks for inodes_per_block on mount") Link: https://lore.kernel.org/r/8be03355983a08e5d4eed480944613454d7e2550.1585434649.git.josh@joshtriplett.org Reviewed-by: Andreas Dilger Signed-off-by: Josh Triplett Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit dd7b410c9b0105ef5ef0adf01b781f93e0c3a3c1 Author: Josh Triplett Date: Sat Mar 28 14:54:01 2020 -0700 ext4: fix incorrect group count in ext4_fill_super error message commit df41460a21b06a76437af040d90ccee03888e8e5 upstream. ext4_fill_super doublechecks the number of groups before mounting; if that check fails, the resulting error message prints the group count from the ext4_sb_info sbi, which hasn't been set yet. Print the freshly computed group count instead (which at that point has just been computed in "blocks_count"). Signed-off-by: Josh Triplett Fixes: 4ec1102813798 ("ext4: Add sanity checks for the superblock before mounting the filesystem") Link: https://lore.kernel.org/r/8b957cd1513fcc4550fe675c10bcce2175c33a49.1585431964.git.josh@joshtriplett.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 44c70ed66c930edb1ea4a0be5395d00f500cb947 Author: Bruno Meneguele Date: Tue Mar 31 10:06:30 2020 -0300 net/bpfilter: remove superfluous testing message commit 41c55ea6c2a7ca4c663eeec05bdf54f4e2419699 upstream. A testing message was brought by 13d0f7b814d9 ("net/bpfilter: fix dprintf usage for /dev/kmsg") but should've been deleted before patch submission. Although it doesn't cause any harm to the code or functionality itself, it's totally unpleasant to have it displayed on every loop iteration with no real use case. Thus remove it unconditionally. Fixes: 13d0f7b814d9 ("net/bpfilter: fix dprintf usage for /dev/kmsg") Signed-off-by: Bruno Meneguele Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 229563dc6b040bd5dabc169a29205e9266f2b282 Author: Sven Van Asbroeck Date: Wed Apr 1 19:01:06 2020 +0200 pwm: pca9685: Fix PWM/GPIO inter-operation commit 9cc5f232a4b6a0ef6e9b57876d61b88f61bdd7c2 upstream. This driver allows pwms to be requested as gpios via gpiolib. Obviously, it should not be allowed to request a GPIO when its corresponding PWM is already requested (and vice versa). So it requires some exclusion code. Given that the PWMm and GPIO cores are not synchronized with respect to each other, this exclusion code will also require proper synchronization. Such a mechanism was in place, but was inadvertently removed by Uwe's clean-up in commit e926b12c611c ("pwm: Clear chip_data in pwm_put()"). Upon revisiting the synchronization mechanism, we found that theoretically, it could allow two threads to successfully request conflicting PWMs/GPIOs. Replace with a bitmap which tracks PWMs in-use, plus a mutex. As long as PWM and GPIO's respective request/free functions modify the in-use bitmap while holding the mutex, proper synchronization will be guaranteed. Reported-by: YueHaibing Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()") Cc: Mika Westerberg Cc: Uwe Kleine-König Cc: YueHaibing Link: https://lkml.org/lkml/2019/5/31/963 Signed-off-by: Sven Van Asbroeck Reviewed-by: Mika Westerberg [cg: Tested on an i.MX6Q board with two NXP PCA9685 chips] Tested-by: Clemens Gruber Reviewed-by: Sven Van Asbroeck # cg's rebase Link: https://lore.kernel.org/lkml/20200330160238.GD2817345@ulmo/ Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 0a4c06f0db064f68bcaf2b9084bf6d5de523e90b Author: Jin Yao Date: Fri Mar 13 21:46:07 2020 +0800 perf report: Fix no branch type statistics report issue commit c3b10649a80e9da2892c1fd3038c53abd57588f6 upstream. Previously we could get the report of branch type statistics. For example: # perf record -j any,save_type ... # t perf report --stdio # # Branch Statistics: # COND_FWD: 40.6% COND_BWD: 4.1% CROSS_4K: 24.7% CROSS_2M: 12.3% COND: 44.7% UNCOND: 0.0% IND: 6.1% CALL: 24.5% RET: 24.7% But now for the recent perf, it can't report the branch type statistics. It's a regression issue caused by commit 40c39e304641 ("perf report: Fix a no annotate browser displayed issue"), which only counts the branch type statistics for browser mode. This patch moves the branch_type_count() outside of ui__has_annotation() checking, then branch type statistics can work for stdio mode. Fixes: 40c39e304641 ("perf report: Fix a no annotate browser displayed issue") Signed-off-by: Jin Yao Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200313134607.12873-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 4542e583e2b82e573b94e4afcc5ca3c04288aae1 Author: Dan Carpenter Date: Tue Feb 25 19:20:06 2020 +0300 acpi/nfit: improve bounds checking for 'func' commit 01091c496f920e634ea84b689f480c39016752a8 upstream. The 'func' variable can come from the user in the __nd_ioctl(). If it's too high then the (1 << func) shift in acpi_nfit_clear_to_send() is undefined. In acpi_nfit_ctl() we pass 'func' to test_bit(func, &dsm_mask) which could result in an out of bounds access. To fix these issues, I introduced the NVDIMM_CMD_MAX (31) define and updated nfit_dsm_revid() to use that define as well instead of magic numbers. Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") Signed-off-by: Dan Carpenter Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/20200225161927.hvftuq7kjn547fyj@kili.mountain Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 5815a5d70def3f785d847e77acb48efe90b6a23c Author: zhangyi (F) Date: Mon Feb 17 19:27:06 2020 +0800 jbd2: improve comments about freeing data buffers whose page mapping is NULL commit 780f66e59231fcf882f36c63f287252ee47cc75a upstream. Improve comments in jbd2_journal_commit_transaction() to describe why we don't need to clear the buffer_mapped bit for freeing file mapping buffers whose page mapping is NULL. Link: https://lore.kernel.org/r/20200217112706.20085-1-yi.zhang@huawei.com Fixes: c96dceeabf76 ("jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer") Suggested-by: Jan Kara Reviewed-by: Jan Kara Signed-off-by: zhangyi (F) Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 8078d3af4af79828a228243b734a499d78986cc6 Author: Pi-Hsun Shih Date: Fri Feb 14 16:26:38 2020 +0800 platform/chrome: cros_ec_rpmsg: Fix race with host event commit f775ac78fcfc6bdc96bdda07029d11f2a5e84869 upstream. Host event can be sent by remoteproc by any time, and cros_ec_rpmsg_callback would be called after cros_ec_rpmsg_create_ept. But the cros_ec_device is initialized after that, which cause host event handler to use cros_ec_device that are not initialized properly yet. Fix this by don't schedule host event handler before cros_ec_register returns. Instead, remember that we have a pending host event, and schedule host event handler after cros_ec_register. Fixes: 71cddb7097e2 ("platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed.") Signed-off-by: Pi-Hsun Shih Signed-off-by: Enric Balletbo i Serra Signed-off-by: Greg Kroah-Hartman commit 777c8c9f11a829ee8de93df285fad9e28d3b8835 Author: Can Guo Date: Mon Feb 10 19:40:48 2020 -0800 scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic commit c63d6099a7959ecc919b2549dc6b71f53521f819 upstream. The async version of ufshcd_hold(async == true), which is only called in queuecommand path as for now, is expected to work in atomic context, thus it should not sleep or schedule out. When it runs into the condition that clocks are ON but link is still in hibern8 state, it should bail out without flushing the clock ungate work. Fixes: f2a785ac2312 ("scsi: ufshcd: Fix race between clk scaling and ungate work") Link: https://lore.kernel.org/r/1581392451-28743-6-git-send-email-cang@codeaurora.org Reviewed-by: Hongwu Su Reviewed-by: Asutosh Das Reviewed-by: Bean Huo Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 66458aa271b0a93d6d6965117c583a304121a120 Author: Amir Goldstein Date: Tue Nov 19 15:36:14 2019 +0200 ovl: fix value of i_ino for lower hardlink corner case commit 300b124fcf6ad2cd99a7b721e0f096785e0a3134 upstream. Commit 6dde1e42f497 ("ovl: make i_ino consistent with st_ino in more cases"), relaxed the condition nfs_export=on in order to set the value of i_ino to xino map of real ino. Specifically, it also relaxed the pre-condition that index=on for consistent i_ino. This opened the corner case of lower hardlink in ovl_get_inode(), which calls ovl_fill_inode() with ino=0 and then ovl_init_inode() is called to set i_ino to lower real ino without the xino mapping. Pass the correct values of ino;fsid in this case to ovl_fill_inode(), so it can initialize i_ino correctly. Fixes: 6dde1e42f497 ("ovl: make i_ino consistent with st_ino in more ...") Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit c85a7109f905f7848735ef50d7e63e5534c4e95d Author: Greg Kroah-Hartman Date: Sat Apr 18 11:29:04 2020 +0200 Revert "ACPI: EC: Do not clear boot_ec_is_ecdt in acpi_ec_add()" This reverts commit ce7a61a0d57d2dd613941d8aef82a5b54fb2e396 which is commit 65a691f5f8f0bb63d6a82eec7b0ffd193d8d8a5f upstream. Rafael writes: It has not been marked for -stable or otherwise requested to be included AFAICS. Also it depends on other mainline commits that have not been included into 5.6.5. Reported-by: Toralf Förster Reported-by: Rafael J. Wysocki Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4f2fb2a1990ab1773936cff893c424331315b743 Author: Florian Fainelli Date: Tue Apr 14 15:39:52 2020 -0700 net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes [ Upstream commit 806fd188ce2a4f8b587e83e73c478e6484fbfa55 ] After commit bfcb813203e619a8960a819bf533ad2a108d8105 ("net: dsa: configure the MTU for switch ports") my Lamobo R1 platform which uses an allwinner,sun7i-a20-gmac compatible Ethernet MAC started to fail by rejecting a MTU of 1536. The reason for that is that the DMA capabilities are not readable on this version of the IP, and there is also no 'tx-fifo-depth' property being provided in Device Tree. The property is documented as optional, and is not provided. Chen-Yu indicated that the FIFO sizes are 4KB for TX and 16KB for RX, so provide these values through platform data as an immediate fix until various Device Tree sources get updated accordingly. Fixes: eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values") Suggested-by: Chen-Yu Tsai Signed-off-by: Florian Fainelli Acked-by: Chen-Yu Tsai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a06a51d592921a1ee5c13b43d1d0ce0daaadc535 Author: Parav Pandit Date: Fri Apr 3 03:57:30 2020 -0500 net/mlx5e: Fix pfnum in devlink port attribute [ Upstream commit 7482d9cb5b974b7ad1a58fa8714f7a8c05b5d278 ] Cited patch missed to extract PCI pf number accurately for PF and VF port flavour. It considered PCI device + function number. Due to this, device having non zero device number shown large pfnum. Hence, use only PCI function number; to avoid similar errors, derive pfnum one time for all port flavours. Fixes: f60f315d339e ("net/mlx5e: Register devlink ports for physical link, PCI PF, VFs") Reviewed-by: Jiri Pirko Signed-off-by: Parav Pandit Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit e25122586403ac84b58c0d6c8d80de0e1782594b Author: Dmytro Linkin Date: Wed Apr 1 14:41:27 2020 +0300 net/mlx5e: Fix nest_level for vlan pop action [ Upstream commit 70f478ca085deec4d6c1f187f773f5827ddce7e8 ] Current value of nest_level, assigned from net_device lower_level value, does not reflect the actual number of vlan headers, needed to pop. For ex., if we have untagged ingress traffic sended over vlan devices, instead of one pop action, driver will perform two pop actions. To fix that, calculate nest_level as difference between vlan device and parent device lower_levels. Fixes: f3b0a18bb6cb ("net: remove unnecessary variables and callback") Signed-off-by: Dmytro Linkin Signed-off-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit cb8892f52ec90d5359695613ff678944e1d53981 Author: Eran Ben Elisha Date: Tue Mar 24 15:04:26 2020 +0200 net/mlx5e: Add missing release firmware call [ Upstream commit d19987ccf57501894fdd8fadc2e55e4a3dd57239 ] Once driver finishes flashing the firmware image, it should release it. Fixes: 9c8bca2637b8 ("mlx5: Move firmware flash implementation to devlink") Signed-off-by: Eran Ben Elisha Reviewed-by: Aya Levin Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 34310505d404ea68c3f94468da3bfe61216c4169 Author: Moshe Shemesh Date: Mon Mar 30 10:21:49 2020 +0300 net/mlx5: Fix frequent ioread PCI access during recovery [ Upstream commit 8c702a53bb0a79bfa203ba21ef1caba43673c5b7 ] High frequency of PCI ioread calls during recovery flow may cause the following trace on powerpc: [ 248.670288] EEH: 2100000 reads ignored for recovering device at location=Slot1 driver=mlx5_core pci addr=0000:01:00.1 [ 248.670331] EEH: Might be infinite loop in mlx5_core driver [ 248.670361] CPU: 2 PID: 35247 Comm: kworker/u192:11 Kdump: loaded Tainted: G OE ------------ 4.14.0-115.14.1.el7a.ppc64le #1 [ 248.670425] Workqueue: mlx5_health0000:01:00.1 health_recover_work [mlx5_core] [ 248.670471] Call Trace: [ 248.670492] [c00020391c11b960] [c000000000c217ac] dump_stack+0xb0/0xf4 (unreliable) [ 248.670548] [c00020391c11b9a0] [c000000000045818] eeh_check_failure+0x5c8/0x630 [ 248.670631] [c00020391c11ba50] [c00000000068fce4] ioread32be+0x114/0x1c0 [ 248.670692] [c00020391c11bac0] [c00800000dd8b400] mlx5_error_sw_reset+0x160/0x510 [mlx5_core] [ 248.670752] [c00020391c11bb60] [c00800000dd75824] mlx5_disable_device+0x34/0x1d0 [mlx5_core] [ 248.670822] [c00020391c11bbe0] [c00800000dd8affc] health_recover_work+0x11c/0x3c0 [mlx5_core] [ 248.670891] [c00020391c11bc80] [c000000000164fcc] process_one_work+0x1bc/0x5f0 [ 248.670955] [c00020391c11bd20] [c000000000167f8c] worker_thread+0xac/0x6b0 [ 248.671015] [c00020391c11bdc0] [c000000000171618] kthread+0x168/0x1b0 [ 248.671067] [c00020391c11be30] [c00000000000b65c] ret_from_kernel_thread+0x5c/0x80 Reduce the PCI ioread frequency during recovery by using msleep() instead of cond_resched() Fixes: 3e5b72ac2f29 ("net/mlx5: Issue SW reset on FW assert") Signed-off-by: Moshe Shemesh Reviewed-by: Feras Daoud Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 1ff0732cf8055131050fa0c26c49429d6e725505 Author: René van Dorst Date: Mon Apr 6 05:42:54 2020 +0800 net: ethernet: mediatek: move mt7623 settings out off the mt7530 [ Upstream commit a5d75538295b06bc6ade1b9da07b9bee57d1c677 ] Moving mt7623 logic out off mt7530, is required to make hardware setting consistent after we introduce phylink to mtk driver. Fixes: b8fc9f30821e ("net: ethernet: mediatek: Add basic PHYLINK support") Reviewed-by: Sean Wang Tested-by: Sean Wang Signed-off-by: René van Dorst Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f749a8bfdd38cfbfd6f3099ed00e4cc442ca341e Author: René van Dorst Date: Mon Apr 6 05:42:53 2020 +0800 net: dsa: mt7530: move mt7623 settings out off the mt7530 [ Upstream commit 84d2f7b708c374a15a2abe092a74e0e47d018286 ] Moving mt7623 logic out off mt7530, is required to make hardware setting consistent after we introduce phylink to mtk driver. Fixes: ca366d6c889b ("net: dsa: mt7530: Convert to PHYLINK API") Reviewed-by: Sean Wang Tested-by: Sean Wang Signed-off-by: René van Dorst Tested-by: Frank Wunderlich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb54dcca3fb5696c493690e3922eca9567791b34 Author: Gilberto Bertin Date: Fri Apr 10 18:20:59 2020 +0200 net: tun: record RX queue in skb before do_xdp_generic() [ Upstream commit 3fe260e00cd0bf0be853c48fcc1e19853df615bb ] This allows netif_receive_generic_xdp() to correctly determine the RX queue from which the skb is coming, so that the context passed to the XDP program will contain the correct RX queue index. Signed-off-by: Gilberto Bertin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f6b264f2a04c7be92a11819961970d16c91449da Author: Konstantin Khlebnikov Date: Mon Apr 6 14:39:32 2020 +0300 net: revert default NAPI poll timeout to 2 jiffies [ Upstream commit a4837980fd9fa4c70a821d11831698901baef56b ] For HZ < 1000 timeout 2000us rounds up to 1 jiffy but expires randomly because next timer interrupt could come shortly after starting softirq. For commonly used CONFIG_HZ=1000 nothing changes. Fixes: 7acf8a1e8a28 ("Replace 2 jiffies with sysctl netdev_budget_usecs to enable softirq tuning") Reported-by: Dmitry Yakunin Signed-off-by: Konstantin Khlebnikov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 61260486790e22de1e31dd178a0925bc5b8e4d9e Author: Wang Wenhu Date: Wed Apr 8 19:53:53 2020 -0700 net: qrtr: send msgs from local of same id as broadcast [ Upstream commit 6dbf02acef69b0742c238574583b3068afbd227c ] If the local node id(qrtr_local_nid) is not modified after its initialization, it equals to the broadcast node id(QRTR_NODE_BCAST). So the messages from local node should not be taken as broadcast and keep the process going to send them out anyway. The definitions are as follow: static unsigned int qrtr_local_nid = NUMA_NO_NODE; Fixes: fdf5fd397566 ("net: qrtr: Broadcast messages only from control port") Signed-off-by: Wang Wenhu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 81dc4e9bff98f9be1136bf658a226dfe5a603a56 Author: Atsushi Nemoto Date: Fri Apr 10 12:16:16 2020 +0900 net: phy: micrel: use genphy_read_status for KSZ9131 [ Upstream commit 68dac3eb50be32957ae6e1e6da9281a3b7c6658b ] KSZ9131 will not work with some switches due to workaround for KSZ9031 introduced in commit d2fd719bcb0e83cb39cfee22ee800f98a56eceb3 ("net/phy: micrel: Add workaround for bad autoneg"). Use genphy_read_status instead of dedicated ksz9031_read_status. Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver") Signed-off-by: Atsushi Nemoto Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a9a851f0ec67939e4a08b66b49d2206edd051584 Author: Tim Stallard Date: Fri Apr 3 21:26:21 2020 +0100 net: ipv6: do not consider routes via gateways for anycast address check [ Upstream commit 03e2a984b6165621f287fadf5f4b5cd8b58dcaba ] The behaviour for what is considered an anycast address changed in commit 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception"). This now considers the first address in a subnet where there is a route via a gateway to be an anycast address. This breaks path MTU discovery and traceroutes when a host in a remote network uses the address at the start of a prefix (eg 2600:: advertised as 2600::/48 in the DFZ) as ICMP errors will not be sent to anycast addresses. This patch excludes any routes with a gateway, or via point to point links, like the behaviour previously from rt6_is_gw_or_nonexthop in net/ipv6/route.c. This can be tested with: ip link add v1 type veth peer name v2 ip netns add test ip netns exec test ip link set lo up ip link set v2 netns test ip link set v1 up ip netns exec test ip link set v2 up ip addr add 2001:db8::1/64 dev v1 nodad ip addr add 2001:db8:100:: dev lo nodad ip netns exec test ip addr add 2001:db8::2/64 dev v2 nodad ip netns exec test ip route add unreachable 2001:db8:1::1 ip netns exec test ip route add 2001:db8:100::/64 via 2001:db8::1 ip netns exec test sysctl net.ipv6.conf.all.forwarding=1 ip route add 2001:db8:1::1 via 2001:db8::2 ping -I 2001:db8::1 2001:db8:1::1 -c1 ping -I 2001:db8:100:: 2001:db8:1::1 -c1 ip addr delete 2001:db8:100:: dev lo ip netns delete test Currently the first ping will get back a destination unreachable ICMP error, but the second will never get a response, with "icmp6_send: acast source" logged. After this patch, both get destination unreachable ICMP replies. Fixes: 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception") Signed-off-by: Tim Stallard Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 22e56cb2f9519dec5ceae24b216b3708baa96a51 Author: Taras Chornyi Date: Thu Apr 9 20:25:24 2020 +0300 net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin [ Upstream commit 690cc86321eb9bcee371710252742fb16fe96824 ] When CONFIG_IP_MULTICAST is not set and multicast ip is added to the device with autojoin flag or when multicast ip is deleted kernel will crash. steps to reproduce: ip addr add 224.0.0.0/32 dev eth0 ip addr del 224.0.0.0/32 dev eth0 or ip addr add 224.0.0.0/32 dev eth0 autojoin Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088 pc : _raw_write_lock_irqsave+0x1e0/0x2ac lr : lock_sock_nested+0x1c/0x60 Call trace: _raw_write_lock_irqsave+0x1e0/0x2ac lock_sock_nested+0x1c/0x60 ip_mc_config.isra.28+0x50/0xe0 inet_rtm_deladdr+0x1a8/0x1f0 rtnetlink_rcv_msg+0x120/0x350 netlink_rcv_skb+0x58/0x120 rtnetlink_rcv+0x14/0x20 netlink_unicast+0x1b8/0x270 netlink_sendmsg+0x1a0/0x3b0 ____sys_sendmsg+0x248/0x290 ___sys_sendmsg+0x80/0xc0 __sys_sendmsg+0x68/0xc0 __arm64_sys_sendmsg+0x20/0x30 el0_svc_common.constprop.2+0x88/0x150 do_el0_svc+0x20/0x80 el0_sync_handler+0x118/0x190 el0_sync+0x140/0x180 Fixes: 93a714d6b53d ("multicast: Extend ip address command to enable multicast group join/leave on") Signed-off-by: Taras Chornyi Signed-off-by: Vadym Kochan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3ca85474311041466cf8e5bac8af49eb1228ab81 Author: DENG Qingfang Date: Tue Apr 14 14:34:08 2020 +0800 net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode [ Upstream commit e045124e93995fe01e42ed530003ddba5d55db4f ] In VLAN-unaware mode, the Egress Tag (EG_TAG) field in Port VLAN Control register must be set to Consistent to let tagged frames pass through as is, otherwise their tags will be stripped. Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: DENG Qingfang Reviewed-by: Florian Fainelli Tested-by: René van Dorst Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 016e3531d5c1380741d7d1464306395caf7aef4c Author: Michael Weiß Date: Tue Apr 7 13:11:48 2020 +0200 l2tp: Allow management of tunnels and session in user namespace [ Upstream commit 2abe05234f2e892728c388169631e4b99f354c86 ] Creation and management of L2TPv3 tunnels and session through netlink requires CAP_NET_ADMIN. However, a process with CAP_NET_ADMIN in a non-initial user namespace gets an EPERM due to the use of the genetlink GENL_ADMIN_PERM flag. Thus, management of L2TP VPNs inside an unprivileged container won't work. We replaced the GENL_ADMIN_PERM by the GENL_UNS_ADMIN_PERM flag similar to other network modules which also had this problem, e.g., openvswitch (commit 4a92602aa1cd "openvswitch: allow management from inside user namespaces") and nl80211 (commit 5617c6cd6f844 "nl80211: Allow privileged operations from user namespaces"). I tested this in the container runtime trustm3 (trustm3.github.io) and was able to create l2tp tunnels and sessions in unpriviliged (user namespaced) containers using a private network namespace. For other runtimes such as docker or lxc this should work, too. Signed-off-by: Michael Weiß Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 22ea267a9cd667c27fa48edb198b2a741661a737 Author: Taehee Yoo Date: Tue Apr 7 13:23:21 2020 +0000 hsr: check protocol version in hsr_newlink() [ Upstream commit 4faab8c446def7667adf1f722456c2f4c304069c ] In the current hsr code, only 0 and 1 protocol versions are valid. But current hsr code doesn't check the version, which is received by userspace. Test commands: ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1 version 4 In the test commands, version 4 is invalid. So, the command should be failed. After this patch, following error will occur. "Error: hsr: Only versions 0..1 are supported." Fixes: ee1c27977284 ("net/hsr: Added support for HSR v1") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ced57064a0858731351fa640714d8cfc6fb7399a Author: Sebastian Andrzej Siewior Date: Thu Apr 16 17:57:40 2020 +0200 amd-xgbe: Use __napi_schedule() in BH context [ Upstream commit d518691cbd3be3dae218e05cca3f3fc9b2f1aa77 ] The driver uses __napi_schedule_irqoff() which is fine as long as it is invoked with disabled interrupts by everybody. Since the commit mentioned below the driver may invoke xgbe_isr_task() in tasklet/softirq context. This may lead to list corruption if another driver uses __napi_schedule_irqoff() in IRQ context. Use __napi_schedule() which safe to use from IRQ and softirq context. Fixes: 85b85c853401d ("amd-xgbe: Re-issue interrupt if interrupt status not cleared") Signed-off-by: Sebastian Andrzej Siewior Acked-by: Tom Lendacky Cc: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman