kernel/linux.git, branch v5.18.15

Linux 5.18.15

2022-07-29T15:28:18+00:00

Link: https://lore.kernel.org/r/20220727161021.428340041@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Bagas Sanjaya Tested-by: Jiri Slaby Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

watch-queue: remove spurious double semicolon

2022-07-29T15:28:17+00:00

commit 44e29e64cf1ac0cffb152e0532227ea6d002aa28 upstream. Sedat Dilek noticed that I had an extraneous semicolon at the end of a line in the previous patch. It's harmless, but unintentional, and while compilers just treat it as an extra empty statement, for all I know some other tooling might warn about it. So clean it up before other people notice too ;) Fixes: 353f7988dd84 ("watchqueue: make sure to serialize 'wqueue->defunct' properly") Reported-by: Sedat Dilek Signed-off-by: Linus Torvalds Reported-by: Sedat Dilek Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states

2022-07-29T15:28:17+00:00

commit 391153522d186f19a008d824bb3a05950351ce6c upstream. The IMR was assumed to be preserved when suspending to S4 and S5 states, but community reports invalidate that assumption, the hardware seems to be powered off and the IMR memory content cleared. Make sure regular boot with firmware download is used for S4 and S5. BugLink: https://github.com/thesofproject/sof/issues/5892 Fixes: 5fb5f51185126 ("ASoC: SOF: Intel: hda-loader: add IMR restore support") Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20220616201818.130802-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: pm: add definitions for S4 and S5 states

2022-07-29T15:28:17+00:00

commit 9d2d462713384538477703e68577b05131c7d97d upstream. We currently don't have a means to differentiate between S3, S4 and S5. Add definitions so that we have select different code paths depending on the target state in follow-up patches. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20220616201818.130802-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2

2022-07-29T15:28:17+00:00

commit a933084558c61cac8c902d2474b39444d87fba46 upstream. The existing code only deals with S0 and S3, let's start adding S1 and S2. No functional change. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20220616201818.130802-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

watchqueue: make sure to serialize 'wqueue->defunct' properly

2022-07-29T15:28:17+00:00

commit 353f7988dd8413c47718f7ca79c030b6fb62cfe5 upstream. When the pipe is closed, we mark the associated watchqueue defunct by calling watch_queue_clear(). However, while that is protected by the watchqueue lock, new watchqueue entries aren't actually added under that lock at all: they use the pipe->rd_wait.lock instead, and looking up that pipe happens without any locking. The watchqueue code uses the RCU read-side section to make sure that the wqueue entry itself hasn't disappeared, but that does not protect the pipe_info in any way. So make sure to actually hold the wqueue lock when posting watch events, properly serializing against the pipe being torn down. Reported-by: Noam Rathaus Cc: Greg KH Cc: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86/alternative: Report missing return thunk details

2022-07-29T15:28:17+00:00

commit 65cdf0d623bedf0e069bb64ed52e8bb20105e2ba upstream. Debugging missing return thunks is easier if we can see where they're happening. Suggested-by: Peter Zijlstra Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/lkml/Ys66hwtFcGbYmoiZ@hirez.programming.kicks-ass.net/ Signed-off-by: Greg Kroah-Hartman

x86/amd: Use IBPB for firmware calls

2022-07-29T15:28:17+00:00

commit 28a99e95f55c61855983d36a88c05c178d966bb7 upstream. On AMD IBRS does not prevent Retbleed; as such use IBPB before a firmware call to flush the branch history state. And because in order to do an EFI call, the kernel maps a whole lot of the kernel page table into the EFI page table, do an IBPB just in case in order to prevent the scenario of poisoning the BTB and causing an EFI call using the unprotected RET there. [ bp: Massage. ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220715194550.793957-1-cascardo@canonical.com Signed-off-by: Greg Kroah-Hartman

exfat: use updated exfat_chain directly during renaming

2022-07-29T15:28:16+00:00

commit 204e6ceaa1035cb7b92b156517e88842ebb4c7ff upstream. In order for a file to access its own directory entry set, exfat_inode_info(ei) has two copied values. One is ei->dir, which is a snapshot of exfat_chain of the parent directory, and the other is ei->entry, which is the offset of the start of the directory entry set in the parent directory. Since the parent directory can be updated after the snapshot point, it should be used only for accessing one's own directory entry set. However, as of now, during renaming, it could try to traverse or to allocate clusters via snapshot values, it does not make sense. This potential problem has been revealed when exfat_update_parent_info() was removed by commit d8dad2588add ("exfat: fix referencing wrong parent directory information after renaming"). However, I don't think it's good idea to bring exfat_update_parent_info() back. Instead, let's use the updated exfat_chain of parent directory diectly. Fixes: d8dad2588add ("exfat: fix referencing wrong parent directory information after renaming") Reported-by: Wang Yugui Signed-off-by: Sungjong Seo Tested-by: Wang Yugui Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman

exfat: fix referencing wrong parent directory information after renaming

2022-07-29T15:28:16+00:00

[ Upstream commit d8dad2588addd1d861ce19e7df3b702330f0c7e3 ] During renaming, the parent directory information maybe updated. But the file/directory still references to the old parent directory information. This bug will cause 2 problems. (1) The renamed file can not be written. [10768.175172] exFAT-fs (sda1): error, failed to bmap (inode : 7afd50e4 iblock : 0, err : -5) [10768.184285] exFAT-fs (sda1): Filesystem has been set read-only ash: write error: Input/output error (2) Some dentries of the renamed file/directory are not set to deleted after removing the file/directory. exfat_update_parent_info() is a workaround for the wrong parent directory information being used after renaming. Now that bug is fixed, this is no longer needed, so remove it. Fixes: 5f2aa075070c ("exfat: add inode operations") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Yuezhang Mo Reviewed-by: Andy Wu Reviewed-by: Aoyama Wataru Reviewed-by: Daniel Palmer Reviewed-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin