commit b5dbcd05792a4bad2c9bb3c4658c854e72c444b7 Author: Greg Kroah-Hartman Date: Fri May 7 10:51:38 2021 +0200 Linux 5.4.117 Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Hulk Robot Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20210505112324.729798712@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 0ee3bfc2c31ec4aabd542aa6b7aa6609bf40c7a1 Author: Jason Gunthorpe Date: Thu Mar 4 21:30:03 2021 -0400 vfio: Depend on MMU commit b2b12db53507bc97d96f6b7cb279e831e5eafb00 upstream. VFIO_IOMMU_TYPE1 does not compile with !MMU: ../drivers/vfio/vfio_iommu_type1.c: In function 'follow_fault_pfn': ../drivers/vfio/vfio_iommu_type1.c:536:22: error: implicit declaration of function 'pte_write'; did you mean 'vfs_write'? [-Werror=implicit-function-declaration] So require it. Suggested-by: Cornelia Huck Signed-off-by: Jason Gunthorpe Message-Id: <0-v1-02cb5500df6e+78-vfio_no_mmu_jgg@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit b246759284d6a2bc5b6f1009caeeb3abce2ec9ff Author: Ondrej Mosnacek Date: Wed Feb 24 22:56:28 2021 +0100 perf/core: Fix unconditional security_locked_down() call commit 08ef1af4de5fe7de9c6d69f1e22e51b66e385d9b upstream. Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task's type has the corresponding "lockdown" class permission ("integrity" or "confidentiality") allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when its result would be honored. Fixes: b0c8fdc7fdb7 ("lockdown: Lock down perf when in confidentiality mode") Signed-off-by: Ondrej Mosnacek Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Paul Moore Link: https://lkml.kernel.org/r/20210224215628.192519-1-omosnace@redhat.com Signed-off-by: Greg Kroah-Hartman commit a1e6a0d1e6cf2c68f31c410e60c5e7a56ffc3e9a Author: Miklos Szeredi Date: Mon Apr 12 12:00:37 2021 +0200 ovl: allow upperdir inside lowerdir commit 708fa01597fa002599756bf56a96d0de1677375c upstream. Commit 146d62e5a586 ("ovl: detect overlapping layers") made sure we don't have overlapping layers, but it also broke the arguably valid use case of mount -olowerdir=/,upperdir=/subdir,.. where upperdir overlaps lowerdir on the same filesystem. This has been causing regressions. Revert the check, but only for the specific case where upperdir and/or workdir are subdirectories of lowerdir. Any other overlap (e.g. lowerdir is subdirectory of upperdir, etc) case is crazy, so leave the check in place for those. Overlaps are detected at lookup time too, so reverting the mount time check should be safe. Fixes: 146d62e5a586 ("ovl: detect overlapping layers") Cc: # v5.2 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 8198962021fd9089dfb433750dcc8c5c48041c8b Author: Dan Carpenter Date: Fri Dec 13 13:48:28 2019 +0300 scsi: ufs: Unlock on a couple error paths commit bb14dd1564c90d333f51e69dd6fc880b8233ce11 upstream. We introduced a few new error paths, but we can't return directly, we first have to unlock "hba->clk_scaling_lock" first. Fixes: a276c19e3e98 ("scsi: ufs: Avoid busy-waiting by eliminating tag conflicts") Link: https://lore.kernel.org/r/20191213104828.7i64cpoof26rc4fw@kili.mountain Reviewed-by: Bart Van Assche Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 91aa2644a3abd4cc1f7ade6ba499e93e79186c62 Author: Mark Pearson Date: Wed Apr 7 17:20:15 2021 -0400 platform/x86: thinkpad_acpi: Correct thermal sensor allocation commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream. On recent Thinkpad platforms it was reported that temp sensor 11 was always incorrectly displaying 66C. It turns out the reason for this is that this location in EC RAM is not a temperature sensor but is the power supply ID (offset 0xC2). Based on feedback from the Lenovo firmware team the EC RAM version can be determined and for the current version (3) only the 0x78 to 0x7F range is used for temp sensors. I don't have any details for earlier versions so I have left the implementation unaltered there. Note - in this block only 0x78 and 0x79 are officially designated (CPU & GPU sensors). The use of the other locations in the block will vary from platform to platform; but the existing logic to detect a sensor presence holds. Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 164f743918222392f912fb7d629f12aefa9d28a2 Author: Chris Chiu Date: Wed Apr 21 01:46:51 2021 +0800 USB: Add reset-resume quirk for WD19's Realtek Hub commit ca91fd8c7643d93bfc18a6fec1a0d3972a46a18a upstream. Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work after the system resumes from suspend with remote wakeup enabled device connected: [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71) [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71) Information of this hub: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5 D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=5487 Rev= 1.47 S: Manufacturer=Dell Inc. S: Product=Dell dock C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms The failure results from the ETIMEDOUT by chance when turning on the suspend feature for the specified port of the hub. The port seems to be in an unknown state so the hub_activate during resume fails the hub_port_status, then the hub will fail to work. The quirky hub needs the reset-resume quirk to function correctly. Acked-by: Alan Stern Signed-off-by: Chris Chiu Cc: stable Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman commit 5922dfc42ac84a0007ce66ba5f4ed7b8a5aaed0a Author: Kai-Heng Feng Date: Mon Apr 12 21:54:53 2021 +0800 USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet commit 8f23fe35ff1e5491b4d279323a8209a31f03ae65 upstream. This is another branded 8153 device that doesn't work well with LPM enabled: [ 400.597506] r8152 5-1.1:1.0 enx482ae3a2a6f0: Tx status -71 So disable LPM to resolve the issue. Signed-off-by: Kai-Heng Feng BugLink: https://bugs.launchpad.net/bugs/1922651 Link: https://lore.kernel.org/r/20210412135455.791971-1-kai.heng.feng@canonical.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 314192f055d9eb84ce507666307c0e2708e923e1 Author: Takashi Iwai Date: Wed Apr 7 16:45:49 2021 +0200 ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX commit 64f40f9be14106e7df0098c427cb60be645bddb7 upstream. ToneLab EX guitar pedal device requires the same quirk like ToneLab ST for supporting the MIDI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212593 Cc: Link: https://lore.kernel.org/r/20210407144549.1530-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6cede11149bf9ebb095c6b53e3ac3365b295a2ad Author: Thomas Richter Date: Wed Apr 21 14:04:00 2021 +0200 perf ftrace: Fix access to pid in array when setting a pid filter [ Upstream commit 671b60cb6a897a5b3832fe57657152f2c3995e25 ] Command 'perf ftrace -v -- ls' fails in s390 (at least 5.12.0rc6). The root cause is a missing pointer dereference which causes an array element address to be used as PID. Fix this by extracting the PID. Output before: # ./perf ftrace -v -- ls function_graph tracer is used write '-263732416' to tracing/set_ftrace_pid failed: Invalid argument failed to set ftrace pid # Output after: ./perf ftrace -v -- ls function_graph tracer is used # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 4) | rcu_read_lock_sched_held() { 4) 0.552 us | rcu_lockdep_current_cpu_online(); 4) 6.124 us | } Reported-by: Alexander Schmidt Signed-off-by: Thomas Richter Acked-by: Namhyung Kim Cc: Heiko Carstens Cc: Sumanth Korikkar Cc: Sven Schnelle Cc: Vasily Gorbik Link: http://lore.kernel.org/lkml/20210421120400.2126433-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ad4659935e11de4b9e3502edaa9237baa44b12f0 Author: Zhen Lei Date: Thu Apr 15 16:34:16 2021 +0800 perf data: Fix error return code in perf_data__create_dir() [ Upstream commit f2211881e737cade55e0ee07cf6a26d91a35a6fe ] Although 'ret' has been initialized to -1, but it will be reassigned by the "ret = open(...)" statement in the for loop. So that, the value of 'ret' is unknown when asprintf() failed. Reported-by: Hulk Robot Signed-off-by: Zhen Lei Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210415083417.3740-1-thunder.leizhen@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit cbc6b467610c9de141848cf1d4a92042a5b5e6fb Author: Jiri Kosina Date: Sat Apr 17 11:13:39 2021 +0200 iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_gen2_enqueue_hcmd() commit e7020bb068d8be50a92f48e36b236a1a1ef9282e upstream. Analogically to what we did in 2800aadc18a6 ("iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()"), we must apply the same fix to iwl_pcie_gen2_enqueue_hcmd(), as it's being called from exactly the same contexts. Reported-by: Heiner Kallweit Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2104171112390.18270@cbobk.fhfr.pm Signed-off-by: Jari Ruusu Signed-off-by: Greg Kroah-Hartman commit c7166a529e2b606f71da267b08a50c8b9a21c6b7 Author: Arnd Bergmann Date: Tue May 4 12:44:33 2021 +0200 avoid __memcat_p link failure The kernel test robot reports a link error when the stm driver is a loadable module on any v5.4 kernel: > ERROR: "__memcat_p" [drivers/hwtracing/stm/stm_core.ko] undefined! This was fixed in mainline with commit 7273ad2b08f8 ("kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y"), which is fairly intrusive. Fix the v5.4 specific issue with a minimal subset of that patch, linking only the failing object into the kernel. Kernels before v4.20 are not affected. Reported-by: kernel test robot Link: https://groups.google.com/g/clang-built-linux/c/H-PrABqYShg Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 8ba25a9ef9b9ca84d085aea4737e6c0852aa5bfd Author: Daniel Borkmann Date: Thu Apr 29 15:19:37 2021 +0000 bpf: Fix leakage of uninitialized bpf stack under speculation commit 801c6058d14a82179a7ee17a4b532cac6fad067f upstream. The current implemented mechanisms to mitigate data disclosure under speculation mainly address stack and map value oob access from the speculative domain. However, Piotr discovered that uninitialized BPF stack is not protected yet, and thus old data from the kernel stack, potentially including addresses of kernel structures, could still be extracted from that 512 bytes large window. The BPF stack is special compared to map values since it's not zero initialized for every program invocation, whereas map values /are/ zero initialized upon their initial allocation and thus cannot leak any prior data in either domain. In the non-speculative domain, the verifier ensures that every stack slot read must have a prior stack slot write by the BPF program to avoid such data leaking issue. However, this is not enough: for example, when the pointer arithmetic operation moves the stack pointer from the last valid stack offset to the first valid offset, the sanitation logic allows for any intermediate offsets during speculative execution, which could then be used to extract any restricted stack content via side-channel. Given for unprivileged stack pointer arithmetic the use of unknown but bounded scalars is generally forbidden, we can simply turn the register-based arithmetic operation into an immediate-based arithmetic operation without the need for masking. This also gives the benefit of reducing the needed instructions for the operation. Given after the work in 7fedb63a8307 ("bpf: Tighten speculative pointer arithmetic mask"), the aux->alu_limit already holds the final immediate value for the offset register with the known scalar. Thus, a simple mov of the immediate to AX register with using AX as the source for the original instruction is sufficient and possible now in this case. Reported-by: Piotr Krysiuk Signed-off-by: Daniel Borkmann Tested-by: Piotr Krysiuk Reviewed-by: Piotr Krysiuk Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 53e0db429b37a32b8fc706d0d90eb4583ad13848 Author: Daniel Borkmann Date: Fri Apr 30 16:21:46 2021 +0200 bpf: Fix masking negation logic upon negative dst register commit b9b34ddbe2076ade359cd5ce7537d5ed019e9807 upstream. The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation. Fixes: 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") Signed-off-by: Daniel Borkmann Tested-by: Piotr Krysiuk Reviewed-by: Piotr Krysiuk Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit b0c8fe7ef79755c2ad4e7e41f1a1e7ed5822bef2 Author: Jiri Kosina Date: Tue Mar 2 11:26:55 2021 +0100 iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd() commit 2800aadc18a64c96b051bcb7da8a7df7d505db3f upstream. It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs disabled (e.g. from LED core). We can't enable BHs in such a situation. Turn the unconditional BH-enable/BH-disable code into hardirq-disable/conditional-enable. This fixes the warning below. WARNING: CPU: 1 PID: 1139 at kernel/softirq.c:178 __local_bh_enable_ip+0xa5/0xf0 CPU: 1 PID: 1139 Comm: NetworkManager Not tainted 5.12.0-rc1-00004-gb4ded168af79 #7 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 RIP: 0010:__local_bh_enable_ip+0xa5/0xf0 Code: f7 69 e8 ee 23 14 00 fb 66 0f 1f 44 00 00 65 8b 05 f0 f4 f7 69 85 c0 74 3f 48 83 c4 08 5b c3 65 8b 05 9b fe f7 69 85 c0 75 8e <0f> 0b eb 8a 48 89 3c 24 e8 4e 20 14 00 48 8b 3c 24 eb 91 e8 13 4e RSP: 0018:ffffafd580b13298 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000201 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000201 RDI: ffffffffc1272389 RBP: ffff96517ae4c018 R08: 0000000000000001 R09: 0000000000000000 R10: ffffafd580b13178 R11: 0000000000000001 R12: ffff96517b060000 R13: 0000000000000000 R14: ffffffff80000000 R15: 0000000000000001 FS: 00007fc604ebefc0(0000) GS:ffff965267480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fb3fef13b2 CR3: 0000000109112004 CR4: 00000000003706e0 Call Trace: ? _raw_spin_unlock_bh+0x1f/0x30 iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi] iwl_trans_txq_send_hcmd+0x6c/0x430 [iwlwifi] iwl_trans_send_cmd+0x88/0x170 [iwlwifi] ? lock_acquire+0x277/0x3d0 iwl_mvm_send_cmd+0x32/0x80 [iwlmvm] iwl_mvm_led_set+0xc2/0xe0 [iwlmvm] ? led_trigger_event+0x46/0x70 led_trigger_event+0x46/0x70 ieee80211_do_open+0x5c5/0xa20 [mac80211] ieee80211_open+0x67/0x90 [mac80211] __dev_open+0xd4/0x150 __dev_change_flags+0x19e/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x30d/0x1230 ? lock_is_held_type+0xb4/0x120 ? __nla_validate_parse.part.7+0x57/0xcb0 ? __lock_acquire+0x2e1/0x1a50 __rtnl_newlink+0x560/0x910 ? __lock_acquire+0x2e1/0x1a50 ? __lock_acquire+0x2e1/0x1a50 ? lock_acquire+0x277/0x3d0 ? sock_def_readable+0x5/0x290 ? lock_is_held_type+0xb4/0x120 ? find_held_lock+0x2d/0x90 ? sock_def_readable+0xb3/0x290 ? lock_release+0x166/0x2a0 ? lock_is_held_type+0x90/0x120 rtnl_newlink+0x47/0x70 rtnetlink_rcv_msg+0x25c/0x470 ? netlink_deliver_tap+0x97/0x3e0 ? validate_linkmsg+0x350/0x350 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1b2/0x280 netlink_sendmsg+0x336/0x450 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1ed/0x250 ? copy_msghdr_from_user+0x5c/0x90 ___sys_sendmsg+0x88/0xd0 ? lock_is_held_type+0xb4/0x120 ? find_held_lock+0x2d/0x90 ? lock_release+0x166/0x2a0 ? __fget_files+0xfe/0x1d0 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 ? lockdep_hardirqs_on_prepare+0xd9/0x170 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc605c9572d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 da ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 2e ef ff ff 48 RSP: 002b:00007fffc83789f0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055ef468570c0 RCX: 00007fc605c9572d RDX: 0000000000000000 RSI: 00007fffc8378a30 RDI: 000000000000000c RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007fffc8378b80 R14: 00007fffc8378b7c R15: 0000000000000000 irq event stamp: 170785 hardirqs last enabled at (170783): [] __local_bh_enable_ip+0x82/0xf0 hardirqs last disabled at (170784): [] _raw_read_lock_irqsave+0x8d/0x90 softirqs last enabled at (170782): [] iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi] softirqs last disabled at (170785): [] iwl_pcie_enqueue_hcmd+0x116/0xa00 [iwlwifi] Signed-off-by: Jiri Kosina Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-rc3 Acked-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2103021125430.12405@cbobk.fhfr.pm Signed-off-by: Jari Ruusu Signed-off-by: Greg Kroah-Hartman commit 43b515c5294208870d00be76f82730a67923c8fb Author: Nick Lowe Date: Mon Dec 21 22:25:02 2020 +0000 igb: Enable RSS for Intel I211 Ethernet Controller commit 6e6026f2dd2005844fb35c3911e8083c09952c6c upstream. The Intel I211 Ethernet Controller supports 2 Receive Side Scaling (RSS) queues. It should not be excluded from having this feature enabled. Via commit c883de9fd787 ("igb: rename igb define to be more generic") E1000_MRQC_ENABLE_RSS_4Q was renamed to E1000_MRQC_ENABLE_RSS_MQ to indicate that this is a generic bit flag to enable queues and not a flag that is specific to devices that support 4 queues The bit flag enables 2, 4 or 8 queues appropriately depending on the part. Tested with a multicore CPU and frames were then distributed as expected. This issue appears to have been introduced because of confusion caused by the prior name. Signed-off-by: Nick Lowe Tested-by: David Switzer Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 354520d3ea81d010edd4d39e4d491c7cf80c6ca5 Author: Phillip Potter Date: Thu Apr 1 23:36:07 2021 +0100 net: usb: ax88179_178a: initialize local variables before use commit bd78980be1a68d14524c51c4b4170782fada622b upstream. Use memset to initialize local array in drivers/net/usb/ax88179_178a.c, and also set a local u16 and u32 variable to 0. Fixes a KMSAN found uninit-value bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=00371c73c72f72487c1d0bfe0cc9d00de339d5aa Reported-by: syzbot+4993e4a0e237f1b53747@syzkaller.appspotmail.com Signed-off-by: Phillip Potter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 55714a57f369f782faba20ef56ac4472ba54b886 Author: Rafael J. Wysocki Date: Tue Apr 13 16:01:00 2021 +0200 ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade() commit 6998a8800d73116187aad542391ce3b2dd0f9e30 upstream. Commit 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by ACPI tables") attempted to address an issue with reserving the memory occupied by ACPI tables, but it broke the initrd-based table override mechanism relied on by multiple users. To restore the initrd-based ACPI table override functionality, move the acpi_boot_table_init() invocation in setup_arch() on x86 after the acpi_table_upgrade() one. Fixes: 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by ACPI tables") Reported-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Cc: George Kennedy Signed-off-by: Greg Kroah-Hartman commit b3041510f0fca598e0311a9df82337f811799d6b Author: Rafael J. Wysocki Date: Tue Mar 23 20:26:52 2021 +0100 ACPI: tables: x86: Reserve memory occupied by ACPI tables commit 1a1c130ab7575498eed5bcf7220037ae09cd1f8a upstream. The following problem has been reported by George Kennedy: Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail in __free_pages_core()") the following use after free occurs intermittently when ACPI tables are accessed. BUG: KASAN: use-after-free in ibft_init+0x134/0xc49 Read of size 4 at addr ffff8880be453004 by task swapper/0/1 CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1-7a7fd0d #1 Call Trace: dump_stack+0xf6/0x158 print_address_description.constprop.9+0x41/0x60 kasan_report.cold.14+0x7b/0xd4 __asan_report_load_n_noabort+0xf/0x20 ibft_init+0x134/0xc49 do_one_initcall+0xc4/0x3e0 kernel_init_freeable+0x5af/0x66b kernel_init+0x16/0x1d0 ret_from_fork+0x22/0x30 ACPI tables mapped via kmap() do not have their mapped pages reserved and the pages can be "stolen" by the buddy allocator. Apparently, on the affected system, the ACPI table in question is not located in "reserved" memory, like ACPI NVS or ACPI Data, that will not be used by the buddy allocator, so the memory occupied by that table has to be explicitly reserved to prevent the buddy allocator from using it. In order to address this problem, rearrange the initialization of the ACPI tables on x86 to locate the initial tables earlier and reserve the memory occupied by them. The other architectures using ACPI should not be affected by this change. Link: https://lore.kernel.org/linux-acpi/1614802160-29362-1-git-send-email-george.kennedy@oracle.com/ Reported-by: George Kennedy Tested-by: George Kennedy Signed-off-by: Rafael J. Wysocki Reviewed-by: Mike Rapoport Cc: 5.10+ # 5.10+ Signed-off-by: Greg Kroah-Hartman commit 91b08c5319a5fa7c933a9f4606d9ffb90b14470c Author: Romain Naour Date: Tue Apr 20 22:12:10 2021 +0100 mips: Do not include hi and lo in clobber list for R6 commit 1d7ba0165d8206ac073f7ac3b14fc0836b66eae7 upstream. From [1] "GCC 10 (PR 91233) won't silently allow registers that are not architecturally available to be present in the clobber list anymore, resulting in build failure for mips*r6 targets in form of: ... .../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target 146 | __asm__ volatile ( \ | ^~~~~~~ This is because base R6 ISA doesn't define hi and lo registers w/o DSP extension. This patch provides the alternative clobber list for r6 targets that won't include those registers." Since kernel 5.4 and mips support for generic vDSO [2], the kernel fail to build for mips r6 cpus with gcc 10 for the same reason as glibc. [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=020b2a97bb15f807c0482f0faee2184ed05bcad8 [2] '24640f233b46 ("mips: Add support for generic vDSO")' Signed-off-by: Romain Naour Signed-off-by: Sudip Mukherjee Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman