From: Sasha Levin Date: Tue, 24 Aug 2021 02:59:51 +0000 (-0400) Subject: Fixes for 5.4 X-Git-Tag: v5.13.13~13 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2df0486835cfb12a7e82f997a4b560286d70feaa;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/alsa-hda-fix-the-capture-switch-value-change-notific.patch b/queue-5.4/alsa-hda-fix-the-capture-switch-value-change-notific.patch new file mode 100644 index 00000000000..447fd0748b0 --- /dev/null +++ b/queue-5.4/alsa-hda-fix-the-capture-switch-value-change-notific.patch @@ -0,0 +1,57 @@ +From 434a3bca9c5c811eafa49aaf05f1ab36226dca34 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 11 Aug 2021 18:14:41 +0200 +Subject: ALSA: hda - fix the 'Capture Switch' value change notifications + +From: Jaroslav Kysela + +[ Upstream commit a2befe9380dd04ee76c871568deca00eedf89134 ] + +The original code in the cap_put_caller() function does not +handle correctly the positive values returned from the passed +function for multiple iterations. It means that the change +notifications may be lost. + +Fixes: 352f7f914ebb ("ALSA: hda - Merge Realtek parser code to generic parser") +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213851 +Cc: +Signed-off-by: Jaroslav Kysela +Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/hda_generic.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c +index 7ac3f04ca8c0..e92fcb150e57 100644 +--- a/sound/pci/hda/hda_generic.c ++++ b/sound/pci/hda/hda_generic.c +@@ -3458,7 +3458,7 @@ static int cap_put_caller(struct snd_kcontrol *kcontrol, + struct hda_gen_spec *spec = codec->spec; + const struct hda_input_mux *imux; + struct nid_path *path; +- int i, adc_idx, err = 0; ++ int i, adc_idx, ret, err = 0; + + imux = &spec->input_mux; + adc_idx = kcontrol->id.index; +@@ -3468,9 +3468,13 @@ static int cap_put_caller(struct snd_kcontrol *kcontrol, + if (!path || !path->ctls[type]) + continue; + kcontrol->private_value = path->ctls[type]; +- err = func(kcontrol, ucontrol); +- if (err < 0) ++ ret = func(kcontrol, ucontrol); ++ if (ret < 0) { ++ err = ret; + break; ++ } ++ if (ret > 0) ++ err = 1; + } + mutex_unlock(&codec->control_mutex); + if (err >= 0 && spec->cap_sync_hook) +-- +2.30.2 + diff --git a/queue-5.4/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch b/queue-5.4/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch new file mode 100644 index 00000000000..efa310ca2b7 --- /dev/null +++ b/queue-5.4/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch @@ -0,0 +1,48 @@ +From e4315b501baa4cd85d0466295ec30992c610bd76 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Aug 2021 17:29:45 +0200 +Subject: ASoC: intel: atom: Fix breakage for PCM buffer address setup + +From: Takashi Iwai + +[ Upstream commit 65ca89c2b12cca0d473f3dd54267568ad3af55cc ] + +The commit 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM +buffer address") changed the reference of PCM buffer address to +substream->runtime->dma_addr as the buffer address may change +dynamically. However, I forgot that the dma_addr field is still not +set up for the CONTINUOUS buffer type (that this driver uses) yet in +5.14 and earlier kernels, and it resulted in garbage I/O. The problem +will be fixed in 5.15, but we need to address it quickly for now. + +The fix is to deduce the address again from the DMA pointer with +virt_to_phys(), but from the right one, substream->runtime->dma_area. + +Fixes: 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address") +Reported-and-tested-by: Hans de Goede +Cc: +Acked-by: Mark Brown +Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com +Link: https://lore.kernel.org/r/20210819152945.8510-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c +index 216e88624c5f..7d59846808b5 100644 +--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c ++++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c +@@ -127,7 +127,7 @@ static void sst_fill_alloc_params(struct snd_pcm_substream *substream, + snd_pcm_uframes_t period_size; + ssize_t periodbytes; + ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream); +- u32 buffer_addr = substream->runtime->dma_addr; ++ u32 buffer_addr = virt_to_phys(substream->runtime->dma_area); + + channels = substream->runtime->channels; + period_size = substream->runtime->period_size; +-- +2.30.2 + diff --git a/queue-5.4/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch b/queue-5.4/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch new file mode 100644 index 00000000000..c412b88af0c --- /dev/null +++ b/queue-5.4/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch @@ -0,0 +1,124 @@ +From 18499f192e90aa0cdb275483fb117bf1ddf4d8ab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Aug 2021 14:26:24 +1000 +Subject: btrfs: prevent rename2 from exchanging a subvol with a directory from + different parents + +From: NeilBrown + +[ Upstream commit 3f79f6f6247c83f448c8026c3ee16d4636ef8d4f ] + +Cross-rename lacks a check when that would prevent exchanging a +directory and subvolume from different parent subvolume. This causes +data inconsistencies and is caught before commit by tree-checker, +turning the filesystem to read-only. + +Calling the renameat2 with RENAME_EXCHANGE flags like + + renameat2(AT_FDCWD, namesrc, AT_FDCWD, namedest, (1 << 1)) + +on two paths: + + namesrc = dir1/subvol1/dir2 + namedest = subvol2/subvol3 + +will cause key order problem with following write time tree-checker +report: + + [1194842.307890] BTRFS critical (device loop1): corrupt leaf: root=5 block=27574272 slot=10 ino=258, invalid previous key objectid, have 257 expect 258 + [1194842.322221] BTRFS info (device loop1): leaf 27574272 gen 8 total ptrs 11 free space 15444 owner 5 + [1194842.331562] BTRFS info (device loop1): refs 2 lock_owner 0 current 26561 + [1194842.338772] item 0 key (256 1 0) itemoff 16123 itemsize 160 + [1194842.338793] inode generation 3 size 16 mode 40755 + [1194842.338801] item 1 key (256 12 256) itemoff 16111 itemsize 12 + [1194842.338809] item 2 key (256 84 2248503653) itemoff 16077 itemsize 34 + [1194842.338817] dir oid 258 type 2 + [1194842.338823] item 3 key (256 84 2363071922) itemoff 16043 itemsize 34 + [1194842.338830] dir oid 257 type 2 + [1194842.338836] item 4 key (256 96 2) itemoff 16009 itemsize 34 + [1194842.338843] item 5 key (256 96 3) itemoff 15975 itemsize 34 + [1194842.338852] item 6 key (257 1 0) itemoff 15815 itemsize 160 + [1194842.338863] inode generation 6 size 8 mode 40755 + [1194842.338869] item 7 key (257 12 256) itemoff 15801 itemsize 14 + [1194842.338876] item 8 key (257 84 2505409169) itemoff 15767 itemsize 34 + [1194842.338883] dir oid 256 type 2 + [1194842.338888] item 9 key (257 96 2) itemoff 15733 itemsize 34 + [1194842.338895] item 10 key (258 12 256) itemoff 15719 itemsize 14 + [1194842.339163] BTRFS error (device loop1): block=27574272 write time tree block corruption detected + [1194842.339245] ------------[ cut here ]------------ + [1194842.443422] WARNING: CPU: 6 PID: 26561 at fs/btrfs/disk-io.c:449 csum_one_extent_buffer+0xed/0x100 [btrfs] + [1194842.511863] CPU: 6 PID: 26561 Comm: kworker/u17:2 Not tainted 5.14.0-rc3-git+ #793 + [1194842.511870] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008 + [1194842.511876] Workqueue: btrfs-worker-high btrfs_work_helper [btrfs] + [1194842.511976] RIP: 0010:csum_one_extent_buffer+0xed/0x100 [btrfs] + [1194842.512068] RSP: 0018:ffffa2c284d77da0 EFLAGS: 00010282 + [1194842.512074] RAX: 0000000000000000 RBX: 0000000000001000 RCX: ffff928867bd9978 + [1194842.512078] RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff928867bd9970 + [1194842.512081] RBP: ffff92876b958000 R08: 0000000000000001 R09: 00000000000c0003 + [1194842.512085] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 + [1194842.512088] R13: ffff92875f989f98 R14: 0000000000000000 R15: 0000000000000000 + [1194842.512092] FS: 0000000000000000(0000) GS:ffff928867a00000(0000) knlGS:0000000000000000 + [1194842.512095] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + [1194842.512099] CR2: 000055f5384da1f0 CR3: 0000000102fe4000 CR4: 00000000000006e0 + [1194842.512103] Call Trace: + [1194842.512128] ? run_one_async_free+0x10/0x10 [btrfs] + [1194842.631729] btree_csum_one_bio+0x1ac/0x1d0 [btrfs] + [1194842.631837] run_one_async_start+0x18/0x30 [btrfs] + [1194842.631938] btrfs_work_helper+0xd5/0x1d0 [btrfs] + [1194842.647482] process_one_work+0x262/0x5e0 + [1194842.647520] worker_thread+0x4c/0x320 + [1194842.655935] ? process_one_work+0x5e0/0x5e0 + [1194842.655946] kthread+0x135/0x160 + [1194842.655953] ? set_kthread_struct+0x40/0x40 + [1194842.655965] ret_from_fork+0x1f/0x30 + [1194842.672465] irq event stamp: 1729 + [1194842.672469] hardirqs last enabled at (1735): [] console_trylock_spinning+0x185/0x1a0 + [1194842.672477] hardirqs last disabled at (1740): [] console_trylock_spinning+0x15c/0x1a0 + [1194842.672482] softirqs last enabled at (1666): [] __do_softirq+0x2e1/0x50a + [1194842.672491] softirqs last disabled at (1651): [] __irq_exit_rcu+0xa7/0xd0 + +The corrupted data will not be written, and filesystem can be unmounted +and mounted again (all changes since the last commit will be lost). + +Add the missing check for new_ino so that all non-subvolumes must reside +under the same parent subvolume. There's an exception allowing to +exchange two subvolumes from any parents as the directory representing a +subvolume is only a logical link and does not have any other structures +related to the parent subvolume, unlike files, directories etc, that +are always in the inode namespace of the parent subvolume. + +Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") +CC: stable@vger.kernel.org # 4.7+ +Reviewed-by: Nikolay Borisov +Signed-off-by: NeilBrown +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/inode.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c +index b044b1d910de..54b607a3cc3f 100644 +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -9702,8 +9702,14 @@ static int btrfs_rename_exchange(struct inode *old_dir, + bool root_log_pinned = false; + bool dest_log_pinned = false; + +- /* we only allow rename subvolume link between subvolumes */ +- if (old_ino != BTRFS_FIRST_FREE_OBJECTID && root != dest) ++ /* ++ * For non-subvolumes allow exchange only within one subvolume, in the ++ * same inode namespace. Two subvolumes (represented as directory) can ++ * be exchanged as they're a logical link and have a fixed inode number. ++ */ ++ if (root != dest && ++ (old_ino != BTRFS_FIRST_FREE_OBJECTID || ++ new_ino != BTRFS_FIRST_FREE_OBJECTID)) + return -EXDEV; + + /* close the race window with snapshot create/destroy ioctl */ +-- +2.30.2 + diff --git a/queue-5.4/fs-warn-about-impending-deprecation-of-mandatory-loc.patch b/queue-5.4/fs-warn-about-impending-deprecation-of-mandatory-loc.patch new file mode 100644 index 00000000000..b28475948fa --- /dev/null +++ b/queue-5.4/fs-warn-about-impending-deprecation-of-mandatory-loc.patch @@ -0,0 +1,41 @@ +From 07470cb55a781b86b85e3aac13959fe6d2f4c30a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 20 Aug 2021 09:29:50 -0400 +Subject: fs: warn about impending deprecation of mandatory locks + +From: Jeff Layton + +[ Upstream commit fdd92b64d15bc4aec973caa25899afd782402e68 ] + +We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros +have disabled it. Warn the stragglers that still use "-o mand" that +we'll be dropping support for that mount option. + +Cc: stable@vger.kernel.org +Signed-off-by: Jeff Layton +Signed-off-by: Sasha Levin +--- + fs/namespace.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/fs/namespace.c b/fs/namespace.c +index a092611d89e7..5782cd55dfdb 100644 +--- a/fs/namespace.c ++++ b/fs/namespace.c +@@ -1647,8 +1647,12 @@ static inline bool may_mount(void) + } + + #ifdef CONFIG_MANDATORY_FILE_LOCKING +-static inline bool may_mandlock(void) ++static bool may_mandlock(void) + { ++ pr_warn_once("======================================================\n" ++ "WARNING: the mand mount option is being deprecated and\n" ++ " will be removed in v5.15!\n" ++ "======================================================\n"); + return capable(CAP_SYS_ADMIN); + } + #else +-- +2.30.2 + diff --git a/queue-5.4/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch b/queue-5.4/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch new file mode 100644 index 00000000000..21c5d4257b0 --- /dev/null +++ b/queue-5.4/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch @@ -0,0 +1,140 @@ +From 1d811da298bca5b92902f12672b0060b27327667 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Aug 2021 18:03:18 +0800 +Subject: ipack: tpci200: fix many double free issues in tpci200_pci_probe + +From: Dongliang Mu + +[ Upstream commit 57a1681095f912239c7fb4d66683ab0425973838 ] + +The function tpci200_register called by tpci200_install and +tpci200_unregister called by tpci200_uninstall are in pair. However, +tpci200_unregister has some cleanup operations not in the +tpci200_register. So the error handling code of tpci200_pci_probe has +many different double free issues. + +Fix this problem by moving those cleanup operations out of +tpci200_unregister, into tpci200_pci_remove and reverting +the previous commit 9272e5d0028d ("ipack/carriers/tpci200: +Fix a double free in tpci200_pci_probe"). + +Fixes: 9272e5d0028d ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe") +Cc: stable@vger.kernel.org +Reported-by: Dongliang Mu +Signed-off-by: Dongliang Mu +Link: https://lore.kernel.org/r/20210810100323.3938492-1-mudongliangabcd@gmail.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/ipack/carriers/tpci200.c | 36 ++++++++++++++++---------------- + 1 file changed, 18 insertions(+), 18 deletions(-) + +diff --git a/drivers/ipack/carriers/tpci200.c b/drivers/ipack/carriers/tpci200.c +index b05d6125c787..80cd0150f592 100644 +--- a/drivers/ipack/carriers/tpci200.c ++++ b/drivers/ipack/carriers/tpci200.c +@@ -91,16 +91,13 @@ static void tpci200_unregister(struct tpci200_board *tpci200) + free_irq(tpci200->info->pdev->irq, (void *) tpci200); + + pci_iounmap(tpci200->info->pdev, tpci200->info->interface_regs); +- pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs); + + pci_release_region(tpci200->info->pdev, TPCI200_IP_INTERFACE_BAR); + pci_release_region(tpci200->info->pdev, TPCI200_IO_ID_INT_SPACES_BAR); + pci_release_region(tpci200->info->pdev, TPCI200_MEM16_SPACE_BAR); + pci_release_region(tpci200->info->pdev, TPCI200_MEM8_SPACE_BAR); +- pci_release_region(tpci200->info->pdev, TPCI200_CFG_MEM_BAR); + + pci_disable_device(tpci200->info->pdev); +- pci_dev_put(tpci200->info->pdev); + } + + static void tpci200_enable_irq(struct tpci200_board *tpci200, +@@ -529,7 +526,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev, + tpci200->info = kzalloc(sizeof(struct tpci200_infos), GFP_KERNEL); + if (!tpci200->info) { + ret = -ENOMEM; +- goto out_err_info; ++ goto err_tpci200; + } + + pci_dev_get(pdev); +@@ -540,7 +537,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev, + if (ret) { + dev_err(&pdev->dev, "Failed to allocate PCI Configuration Memory"); + ret = -EBUSY; +- goto out_err_pci_request; ++ goto err_tpci200_info; + } + tpci200->info->cfg_regs = ioremap_nocache( + pci_resource_start(pdev, TPCI200_CFG_MEM_BAR), +@@ -548,7 +545,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev, + if (!tpci200->info->cfg_regs) { + dev_err(&pdev->dev, "Failed to map PCI Configuration Memory"); + ret = -EFAULT; +- goto out_err_ioremap; ++ goto err_request_region; + } + + /* Disable byte swapping for 16 bit IP module access. This will ensure +@@ -571,7 +568,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev, + if (ret) { + dev_err(&pdev->dev, "error during tpci200 install\n"); + ret = -ENODEV; +- goto out_err_install; ++ goto err_cfg_regs; + } + + /* Register the carrier in the industry pack bus driver */ +@@ -583,7 +580,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev, + dev_err(&pdev->dev, + "error registering the carrier on ipack driver\n"); + ret = -EFAULT; +- goto out_err_bus_register; ++ goto err_tpci200_install; + } + + /* save the bus number given by ipack to logging purpose */ +@@ -594,19 +591,16 @@ static int tpci200_pci_probe(struct pci_dev *pdev, + tpci200_create_device(tpci200, i); + return 0; + +-out_err_bus_register: ++err_tpci200_install: + tpci200_uninstall(tpci200); +- /* tpci200->info->cfg_regs is unmapped in tpci200_uninstall */ +- tpci200->info->cfg_regs = NULL; +-out_err_install: +- if (tpci200->info->cfg_regs) +- iounmap(tpci200->info->cfg_regs); +-out_err_ioremap: ++err_cfg_regs: ++ pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs); ++err_request_region: + pci_release_region(pdev, TPCI200_CFG_MEM_BAR); +-out_err_pci_request: +- pci_dev_put(pdev); ++err_tpci200_info: + kfree(tpci200->info); +-out_err_info: ++ pci_dev_put(pdev); ++err_tpci200: + kfree(tpci200); + return ret; + } +@@ -616,6 +610,12 @@ static void __tpci200_pci_remove(struct tpci200_board *tpci200) + ipack_bus_unregister(tpci200->info->ipack_bus); + tpci200_uninstall(tpci200); + ++ pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs); ++ ++ pci_release_region(tpci200->info->pdev, TPCI200_CFG_MEM_BAR); ++ ++ pci_dev_put(tpci200->info->pdev); ++ + kfree(tpci200->info); + kfree(tpci200); + } +-- +2.30.2 + diff --git a/queue-5.4/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch b/queue-5.4/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch new file mode 100644 index 00000000000..ee4b8eff232 --- /dev/null +++ b/queue-5.4/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch @@ -0,0 +1,107 @@ +From fbdf1cccb251dc03ba404b0a05f87f33ce5db7e3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Aug 2021 18:03:19 +0800 +Subject: ipack: tpci200: fix memory leak in the tpci200_register + +From: Dongliang Mu + +[ Upstream commit 50f05bd114a46a74726e432bf81079d3f13a55b7 ] + +The error handling code in tpci200_register does not free interface_regs +allocated by ioremap and the current version of error handling code is +problematic. + +Fix this by refactoring the error handling code and free interface_regs +when necessary. + +Fixes: 43986798fd50 ("ipack: add error handling for ioremap_nocache") +Cc: stable@vger.kernel.org +Reported-by: Dongliang Mu +Signed-off-by: Dongliang Mu +Link: https://lore.kernel.org/r/20210810100323.3938492-2-mudongliangabcd@gmail.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/ipack/carriers/tpci200.c | 24 ++++++++++++++---------- + 1 file changed, 14 insertions(+), 10 deletions(-) + +diff --git a/drivers/ipack/carriers/tpci200.c b/drivers/ipack/carriers/tpci200.c +index 80cd0150f592..46665b1cef85 100644 +--- a/drivers/ipack/carriers/tpci200.c ++++ b/drivers/ipack/carriers/tpci200.c +@@ -256,7 +256,7 @@ static int tpci200_register(struct tpci200_board *tpci200) + "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 2 !", + tpci200->info->pdev->bus->number, + tpci200->info->pdev->devfn); +- goto out_disable_pci; ++ goto err_disable_device; + } + + /* Request IO ID INT space (Bar 3) */ +@@ -268,7 +268,7 @@ static int tpci200_register(struct tpci200_board *tpci200) + "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 3 !", + tpci200->info->pdev->bus->number, + tpci200->info->pdev->devfn); +- goto out_release_ip_space; ++ goto err_ip_interface_bar; + } + + /* Request MEM8 space (Bar 5) */ +@@ -279,7 +279,7 @@ static int tpci200_register(struct tpci200_board *tpci200) + "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 5!", + tpci200->info->pdev->bus->number, + tpci200->info->pdev->devfn); +- goto out_release_ioid_int_space; ++ goto err_io_id_int_spaces_bar; + } + + /* Request MEM16 space (Bar 4) */ +@@ -290,7 +290,7 @@ static int tpci200_register(struct tpci200_board *tpci200) + "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 4!", + tpci200->info->pdev->bus->number, + tpci200->info->pdev->devfn); +- goto out_release_mem8_space; ++ goto err_mem8_space_bar; + } + + /* Map internal tpci200 driver user space */ +@@ -304,7 +304,7 @@ static int tpci200_register(struct tpci200_board *tpci200) + tpci200->info->pdev->bus->number, + tpci200->info->pdev->devfn); + res = -ENOMEM; +- goto out_release_mem8_space; ++ goto err_mem16_space_bar; + } + + /* Initialize lock that protects interface_regs */ +@@ -343,18 +343,22 @@ static int tpci200_register(struct tpci200_board *tpci200) + "(bn 0x%X, sn 0x%X) unable to register IRQ !", + tpci200->info->pdev->bus->number, + tpci200->info->pdev->devfn); +- goto out_release_ioid_int_space; ++ goto err_interface_regs; + } + + return 0; + +-out_release_mem8_space: ++err_interface_regs: ++ pci_iounmap(tpci200->info->pdev, tpci200->info->interface_regs); ++err_mem16_space_bar: ++ pci_release_region(tpci200->info->pdev, TPCI200_MEM16_SPACE_BAR); ++err_mem8_space_bar: + pci_release_region(tpci200->info->pdev, TPCI200_MEM8_SPACE_BAR); +-out_release_ioid_int_space: ++err_io_id_int_spaces_bar: + pci_release_region(tpci200->info->pdev, TPCI200_IO_ID_INT_SPACES_BAR); +-out_release_ip_space: ++err_ip_interface_bar: + pci_release_region(tpci200->info->pdev, TPCI200_IP_INTERFACE_BAR); +-out_disable_pci: ++err_disable_device: + pci_disable_device(tpci200->info->pdev); + return res; + } +-- +2.30.2 + diff --git a/queue-5.4/mm-memcg-avoid-stale-protection-values-when-cgroup-i.patch b/queue-5.4/mm-memcg-avoid-stale-protection-values-when-cgroup-i.patch new file mode 100644 index 00000000000..12299ca25a4 --- /dev/null +++ b/queue-5.4/mm-memcg-avoid-stale-protection-values-when-cgroup-i.patch @@ -0,0 +1,206 @@ +From d988f6b259f6f6b32e7c6e6e06686004de8f172c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 6 Aug 2020 23:22:01 -0700 +Subject: mm, memcg: avoid stale protection values when cgroup is above + protection + +From: Yafang Shao + +[ Upstream commit 22f7496f0b901249f23c5251eb8a10aae126b909 ] + +Patch series "mm, memcg: memory.{low,min} reclaim fix & cleanup", v4. + +This series contains a fix for a edge case in my earlier protection +calculation patches, and a patch to make the area overall a little more +robust to hopefully help avoid this in future. + +This patch (of 2): + +A cgroup can have both memory protection and a memory limit to isolate it +from its siblings in both directions - for example, to prevent it from +being shrunk below 2G under high pressure from outside, but also from +growing beyond 4G under low pressure. + +Commit 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") +implemented proportional scan pressure so that multiple siblings in excess +of their protection settings don't get reclaimed equally but instead in +accordance to their unprotected portion. + +During limit reclaim, this proportionality shouldn't apply of course: +there is no competition, all pressure is from within the cgroup and should +be applied as such. Reclaim should operate at full efficiency. + +However, mem_cgroup_protected() never expected anybody to look at the +effective protection values when it indicated that the cgroup is above its +protection. As a result, a query during limit reclaim may return stale +protection values that were calculated by a previous reclaim cycle in +which the cgroup did have siblings. + +When this happens, reclaim is unnecessarily hesitant and potentially slow +to meet the desired limit. In theory this could lead to premature OOM +kills, although it's not obvious this has occurred in practice. + +Workaround the problem by special casing reclaim roots in +mem_cgroup_protection. These memcgs are never participating in the +reclaim protection because the reclaim is internal. + +We have to ignore effective protection values for reclaim roots because +mem_cgroup_protected might be called from racing reclaim contexts with +different roots. Calculation is relying on root -> leaf tree traversal +therefore top-down reclaim protection invariants should hold. The only +exception is the reclaim root which should have effective protection set +to 0 but that would be problematic for the following setup: + + Let's have global and A's reclaim in parallel: + | + A (low=2G, usage = 3G, max = 3G, children_low_usage = 1.5G) + |\ + | C (low = 1G, usage = 2.5G) + B (low = 1G, usage = 0.5G) + + for A reclaim we have + B.elow = B.low + C.elow = C.low + + For the global reclaim + A.elow = A.low + B.elow = min(B.usage, B.low) because children_low_usage <= A.elow + C.elow = min(C.usage, C.low) + + With the effective values resetting we have A reclaim + A.elow = 0 + B.elow = B.low + C.elow = C.low + + and global reclaim could see the above and then + B.elow = C.elow = 0 because children_low_usage > A.elow + +Which means that protected memcgs would get reclaimed. + +In future we would like to make mem_cgroup_protected more robust against +racing reclaim contexts but that is likely more complex solution than this +simple workaround. + +[hannes@cmpxchg.org - large part of the changelog] +[mhocko@suse.com - workaround explanation] +[chris@chrisdown.name - retitle] + +Fixes: 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") +Signed-off-by: Yafang Shao +Signed-off-by: Chris Down +Signed-off-by: Andrew Morton +Acked-by: Michal Hocko +Acked-by: Johannes Weiner +Acked-by: Chris Down +Acked-by: Roman Gushchin +Link: http://lkml.kernel.org/r/cover.1594638158.git.chris@chrisdown.name +Link: http://lkml.kernel.org/r/044fb8ecffd001c7905d27c0c2ad998069fdc396.1594638158.git.chris@chrisdown.name +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + include/linux/memcontrol.h | 42 ++++++++++++++++++++++++++++++++++++-- + mm/memcontrol.c | 8 ++++++++ + mm/vmscan.c | 3 ++- + 3 files changed, 50 insertions(+), 3 deletions(-) + +diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h +index fb5b2a41bd45..059f55841cc8 100644 +--- a/include/linux/memcontrol.h ++++ b/include/linux/memcontrol.h +@@ -356,12 +356,49 @@ static inline bool mem_cgroup_disabled(void) + return !cgroup_subsys_enabled(memory_cgrp_subsys); + } + +-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *memcg, ++static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root, ++ struct mem_cgroup *memcg, + bool in_low_reclaim) + { + if (mem_cgroup_disabled()) + return 0; + ++ /* ++ * There is no reclaim protection applied to a targeted reclaim. ++ * We are special casing this specific case here because ++ * mem_cgroup_protected calculation is not robust enough to keep ++ * the protection invariant for calculated effective values for ++ * parallel reclaimers with different reclaim target. This is ++ * especially a problem for tail memcgs (as they have pages on LRU) ++ * which would want to have effective values 0 for targeted reclaim ++ * but a different value for external reclaim. ++ * ++ * Example ++ * Let's have global and A's reclaim in parallel: ++ * | ++ * A (low=2G, usage = 3G, max = 3G, children_low_usage = 1.5G) ++ * |\ ++ * | C (low = 1G, usage = 2.5G) ++ * B (low = 1G, usage = 0.5G) ++ * ++ * For the global reclaim ++ * A.elow = A.low ++ * B.elow = min(B.usage, B.low) because children_low_usage <= A.elow ++ * C.elow = min(C.usage, C.low) ++ * ++ * With the effective values resetting we have A reclaim ++ * A.elow = 0 ++ * B.elow = B.low ++ * C.elow = C.low ++ * ++ * If the global reclaim races with A's reclaim then ++ * B.elow = C.elow = 0 because children_low_usage > A.elow) ++ * is possible and reclaiming B would be violating the protection. ++ * ++ */ ++ if (root == memcg) ++ return 0; ++ + if (in_low_reclaim) + return READ_ONCE(memcg->memory.emin); + +@@ -847,7 +884,8 @@ static inline void memcg_memory_event_mm(struct mm_struct *mm, + { + } + +-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *memcg, ++static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root, ++ struct mem_cgroup *memcg, + bool in_low_reclaim) + { + return 0; +diff --git a/mm/memcontrol.c b/mm/memcontrol.c +index 2701497edda5..6d7fe3589e4a 100644 +--- a/mm/memcontrol.c ++++ b/mm/memcontrol.c +@@ -6446,6 +6446,14 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root, + + if (!root) + root = root_mem_cgroup; ++ ++ /* ++ * Effective values of the reclaim targets are ignored so they ++ * can be stale. Have a look at mem_cgroup_protection for more ++ * details. ++ * TODO: calculation should be more robust so that we do not need ++ * that special casing. ++ */ + if (memcg == root) + return MEMCG_PROT_NONE; + +diff --git a/mm/vmscan.c b/mm/vmscan.c +index 10feb872d9a4..dc44da27673d 100644 +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -2462,7 +2462,8 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, + unsigned long protection; + + lruvec_size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx); +- protection = mem_cgroup_protection(memcg, ++ protection = mem_cgroup_protection(sc->target_mem_cgroup, ++ memcg, + sc->memcg_low_reclaim); + + if (protection) { +-- +2.30.2 + diff --git a/queue-5.4/mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch b/queue-5.4/mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch new file mode 100644 index 00000000000..0c007b72d02 --- /dev/null +++ b/queue-5.4/mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch @@ -0,0 +1,164 @@ +From 5b460856aae2dc4707c8e1f2264c75535ae98942 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Aug 2021 19:04:21 -0700 +Subject: mm: memcontrol: fix occasional OOMs due to proportional memory.low + reclaim + +From: Johannes Weiner + +[ Upstream commit f56ce412a59d7d938b81de8878faef128812482c ] + +We've noticed occasional OOM killing when memory.low settings are in +effect for cgroups. This is unexpected and undesirable as memory.low is +supposed to express non-OOMing memory priorities between cgroups. + +The reason for this is proportional memory.low reclaim. When cgroups +are below their memory.low threshold, reclaim passes them over in the +first round, and then retries if it couldn't find pages anywhere else. +But when cgroups are slightly above their memory.low setting, page scan +force is scaled down and diminished in proportion to the overage, to the +point where it can cause reclaim to fail as well - only in that case we +currently don't retry, and instead trigger OOM. + +To fix this, hook proportional reclaim into the same retry logic we have +in place for when cgroups are skipped entirely. This way if reclaim +fails and some cgroups were scanned with diminished pressure, we'll try +another full-force cycle before giving up and OOMing. + +[akpm@linux-foundation.org: coding-style fixes] + +Link: https://lkml.kernel.org/r/20210817180506.220056-1-hannes@cmpxchg.org +Fixes: 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") +Signed-off-by: Johannes Weiner +Reported-by: Leon Yang +Reviewed-by: Rik van Riel +Reviewed-by: Shakeel Butt +Acked-by: Roman Gushchin +Acked-by: Chris Down +Acked-by: Michal Hocko +Cc: [5.4+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + include/linux/memcontrol.h | 29 +++++++++++++++-------------- + mm/vmscan.c | 27 +++++++++++++++++++-------- + 2 files changed, 34 insertions(+), 22 deletions(-) + +diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h +index 059f55841cc8..b6d0b68f5503 100644 +--- a/include/linux/memcontrol.h ++++ b/include/linux/memcontrol.h +@@ -356,12 +356,15 @@ static inline bool mem_cgroup_disabled(void) + return !cgroup_subsys_enabled(memory_cgrp_subsys); + } + +-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root, +- struct mem_cgroup *memcg, +- bool in_low_reclaim) ++static inline void mem_cgroup_protection(struct mem_cgroup *root, ++ struct mem_cgroup *memcg, ++ unsigned long *min, ++ unsigned long *low) + { ++ *min = *low = 0; ++ + if (mem_cgroup_disabled()) +- return 0; ++ return; + + /* + * There is no reclaim protection applied to a targeted reclaim. +@@ -397,13 +400,10 @@ static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root, + * + */ + if (root == memcg) +- return 0; +- +- if (in_low_reclaim) +- return READ_ONCE(memcg->memory.emin); ++ return; + +- return max(READ_ONCE(memcg->memory.emin), +- READ_ONCE(memcg->memory.elow)); ++ *min = READ_ONCE(memcg->memory.emin); ++ *low = READ_ONCE(memcg->memory.elow); + } + + enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root, +@@ -884,11 +884,12 @@ static inline void memcg_memory_event_mm(struct mm_struct *mm, + { + } + +-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root, +- struct mem_cgroup *memcg, +- bool in_low_reclaim) ++static inline void mem_cgroup_protection(struct mem_cgroup *root, ++ struct mem_cgroup *memcg, ++ unsigned long *min, ++ unsigned long *low) + { +- return 0; ++ *min = *low = 0; + } + + static inline enum mem_cgroup_protection mem_cgroup_protected( +diff --git a/mm/vmscan.c b/mm/vmscan.c +index dc44da27673d..fad9be4703ec 100644 +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -89,9 +89,12 @@ struct scan_control { + unsigned int may_swap:1; + + /* +- * Cgroups are not reclaimed below their configured memory.low, +- * unless we threaten to OOM. If any cgroups are skipped due to +- * memory.low and nothing was reclaimed, go back for memory.low. ++ * Cgroup memory below memory.low is protected as long as we ++ * don't threaten to OOM. If any cgroup is reclaimed at ++ * reduced force or passed over entirely due to its memory.low ++ * setting (memcg_low_skipped), and nothing is reclaimed as a ++ * result, then go back for one more cycle that reclaims the protected ++ * memory (memcg_low_reclaim) to avert OOM. + */ + unsigned int memcg_low_reclaim:1; + unsigned int memcg_low_skipped:1; +@@ -2458,15 +2461,14 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, + for_each_evictable_lru(lru) { + int file = is_file_lru(lru); + unsigned long lruvec_size; ++ unsigned long low, min; + unsigned long scan; +- unsigned long protection; + + lruvec_size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx); +- protection = mem_cgroup_protection(sc->target_mem_cgroup, +- memcg, +- sc->memcg_low_reclaim); ++ mem_cgroup_protection(sc->target_mem_cgroup, memcg, ++ &min, &low); + +- if (protection) { ++ if (min || low) { + /* + * Scale a cgroup's reclaim pressure by proportioning + * its current usage to its memory.low or memory.min +@@ -2497,6 +2499,15 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, + * hard protection. + */ + unsigned long cgroup_size = mem_cgroup_size(memcg); ++ unsigned long protection; ++ ++ /* memory.low scaling, make sure we retry before OOM */ ++ if (!sc->memcg_low_reclaim && low > min) { ++ protection = low; ++ sc->memcg_low_skipped = 1; ++ } else { ++ protection = min; ++ } + + /* Avoid TOCTOU with earlier protection check */ + cgroup_size = max(cgroup_size, protection); +-- +2.30.2 + diff --git a/queue-5.4/mmc-dw_mmc-fix-hang-on-data-crc-error.patch b/queue-5.4/mmc-dw_mmc-fix-hang-on-data-crc-error.patch new file mode 100644 index 00000000000..ccf3e4e5eba --- /dev/null +++ b/queue-5.4/mmc-dw_mmc-fix-hang-on-data-crc-error.patch @@ -0,0 +1,73 @@ +From 3aa6331ec33676186ca14ad731fde810253b9e0f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 30 Jun 2021 12:22:32 +0200 +Subject: mmc: dw_mmc: Fix hang on data CRC error + +From: Vincent Whitchurch + +[ Upstream commit 25f8203b4be1937c4939bb98623e67dcfd7da4d1 ] + +When a Data CRC interrupt is received, the driver disables the DMA, then +sends the stop/abort command and then waits for Data Transfer Over. + +However, sometimes, when a data CRC error is received in the middle of a +multi-block write transfer, the Data Transfer Over interrupt is never +received, and the driver hangs and never completes the request. + +The driver sets the BMOD.SWR bit (SDMMC_IDMAC_SWRESET) when stopping the +DMA, but according to the manual CMD.STOP_ABORT_CMD should be programmed +"before assertion of SWR". Do these operations in the recommended +order. With this change the Data Transfer Over is always received +correctly in my tests. + +Signed-off-by: Vincent Whitchurch +Reviewed-by: Jaehoon Chung +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/dw_mmc.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c +index 79c55c7b4afd..6ace82028667 100644 +--- a/drivers/mmc/host/dw_mmc.c ++++ b/drivers/mmc/host/dw_mmc.c +@@ -2017,8 +2017,8 @@ static void dw_mci_tasklet_func(unsigned long priv) + continue; + } + +- dw_mci_stop_dma(host); + send_stop_abort(host, data); ++ dw_mci_stop_dma(host); + state = STATE_SENDING_STOP; + break; + } +@@ -2042,10 +2042,10 @@ static void dw_mci_tasklet_func(unsigned long priv) + */ + if (test_and_clear_bit(EVENT_DATA_ERROR, + &host->pending_events)) { +- dw_mci_stop_dma(host); + if (!(host->data_status & (SDMMC_INT_DRTO | + SDMMC_INT_EBE))) + send_stop_abort(host, data); ++ dw_mci_stop_dma(host); + state = STATE_DATA_ERROR; + break; + } +@@ -2078,10 +2078,10 @@ static void dw_mci_tasklet_func(unsigned long priv) + */ + if (test_and_clear_bit(EVENT_DATA_ERROR, + &host->pending_events)) { +- dw_mci_stop_dma(host); + if (!(host->data_status & (SDMMC_INT_DRTO | + SDMMC_INT_EBE))) + send_stop_abort(host, data); ++ dw_mci_stop_dma(host); + state = STATE_DATA_ERROR; + break; + } +-- +2.30.2 + diff --git a/queue-5.4/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch b/queue-5.4/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch new file mode 100644 index 00000000000..817772323d5 --- /dev/null +++ b/queue-5.4/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch @@ -0,0 +1,45 @@ +From 7389f03a99e8000a699e14ea5119c699a1ade98f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Jul 2021 22:58:58 -0400 +Subject: PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI + +From: Marcin Bachry + +[ Upstream commit e0bff43220925b7e527f9d3bc9f5c624177c959e ] + +The Renoir XHCI controller apparently doesn't resume reliably with the +standard D3hot-to-D0 delay. Increase it to 20ms. + +[Alex: I talked to the AMD USB hardware team and the AMD Windows team and +they are not aware of any HW errata or specific issues. The HW works fine +in Windows. I was told Windows uses a rather generous default delay of +100ms for PCI state transitions.] + +Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.com +Signed-off-by: Marcin Bachry +Signed-off-by: Alex Deucher +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org +Cc: Mario Limonciello +Cc: Prike Liang +Cc: Shyam Sundar S K +Signed-off-by: Sasha Levin +--- + drivers/pci/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c +index 6c1b936a94fa..0241f0dcc093 100644 +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -1905,6 +1905,7 @@ static void quirk_ryzen_xhci_d3hot(struct pci_dev *dev) + } + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15e0, quirk_ryzen_xhci_d3hot); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15e1, quirk_ryzen_xhci_d3hot); ++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1639, quirk_ryzen_xhci_d3hot); + + #ifdef CONFIG_X86_IO_APIC + static int dmi_disable_ioapicreroute(const struct dmi_system_id *d) +-- +2.30.2 + diff --git a/queue-5.4/series b/queue-5.4/series index e0bd9dcfa07..21ccf8cc58d 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -43,3 +43,17 @@ ovs-clear-skb-tstamp-in-forwarding-path.patch i40e-fix-atr-queue-selection.patch iavf-fix-ping-is-lost-after-untrusted-vf-had-tried-t.patch ovl-add-splice-file-read-write-helper.patch +mmc-dw_mmc-fix-hang-on-data-crc-error.patch +alsa-hda-fix-the-capture-switch-value-change-notific.patch +tracing-histogram-fix-null-pointer-dereference-on-st.patch +slimbus-messaging-start-transaction-ids-from-1-inste.patch +slimbus-messaging-check-for-valid-transaction-id.patch +slimbus-ngd-reset-dma-setup-during-runtime-pm.patch +ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch +ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch +btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch +pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch +asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch +mm-memcg-avoid-stale-protection-values-when-cgroup-i.patch +mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch +fs-warn-about-impending-deprecation-of-mandatory-loc.patch diff --git a/queue-5.4/slimbus-messaging-check-for-valid-transaction-id.patch b/queue-5.4/slimbus-messaging-check-for-valid-transaction-id.patch new file mode 100644 index 00000000000..6ede37576f6 --- /dev/null +++ b/queue-5.4/slimbus-messaging-check-for-valid-transaction-id.patch @@ -0,0 +1,53 @@ +From 0eda62ad1e83457e1f5274c7bee9e5cda080943d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Aug 2021 09:24:26 +0100 +Subject: slimbus: messaging: check for valid transaction id + +From: Srinivas Kandagatla + +[ Upstream commit a263c1ff6abe0e66712f40d595bbddc7a35907f8 ] + +In some usecases transaction ids are dynamically allocated inside +the controller driver after sending the messages which have generic +acknowledge responses. So check for this before refcounting pm_runtime. + +Without this we would end up imbalancing runtime pm count by +doing pm_runtime_put() in both slim_do_transfer() and slim_msg_response() +for a single pm_runtime_get() in slim_do_transfer() + +Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()") +Cc: +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20210809082428.11236-3-srinivas.kandagatla@linaro.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/slimbus/messaging.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c +index 3b77713f1e3f..ddf0371ad52b 100644 +--- a/drivers/slimbus/messaging.c ++++ b/drivers/slimbus/messaging.c +@@ -131,7 +131,8 @@ int slim_do_transfer(struct slim_controller *ctrl, struct slim_msg_txn *txn) + goto slim_xfer_err; + } + } +- ++ /* Initialize tid to invalid value */ ++ txn->tid = 0; + need_tid = slim_tid_txn(txn->mt, txn->mc); + + if (need_tid) { +@@ -163,7 +164,7 @@ int slim_do_transfer(struct slim_controller *ctrl, struct slim_msg_txn *txn) + txn->mt, txn->mc, txn->la, ret); + + slim_xfer_err: +- if (!clk_pause_msg && (!need_tid || ret == -ETIMEDOUT)) { ++ if (!clk_pause_msg && (txn->tid == 0 || ret == -ETIMEDOUT)) { + /* + * remove runtime-pm vote if this was TX only, or + * if there was error during this transaction +-- +2.30.2 + diff --git a/queue-5.4/slimbus-messaging-start-transaction-ids-from-1-inste.patch b/queue-5.4/slimbus-messaging-start-transaction-ids-from-1-inste.patch new file mode 100644 index 00000000000..bc413b60cec --- /dev/null +++ b/queue-5.4/slimbus-messaging-start-transaction-ids-from-1-inste.patch @@ -0,0 +1,42 @@ +From 6782778bd76c04b521b67ac83dd7b42656973afd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Aug 2021 09:24:25 +0100 +Subject: slimbus: messaging: start transaction ids from 1 instead of zero + +From: Srinivas Kandagatla + +[ Upstream commit 9659281ce78de0f15a4aa124da8f7450b1399c09 ] + +As tid is unsigned its hard to figure out if the tid is valid or +invalid. So Start the transaction ids from 1 instead of zero +so that we could differentiate between a valid tid and invalid tids + +This is useful in cases where controller would add a tid for controller +specific transfers. + +Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()") +Cc: +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20210809082428.11236-2-srinivas.kandagatla@linaro.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/slimbus/messaging.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c +index d5879142dbef..3b77713f1e3f 100644 +--- a/drivers/slimbus/messaging.c ++++ b/drivers/slimbus/messaging.c +@@ -66,7 +66,7 @@ int slim_alloc_txn_tid(struct slim_controller *ctrl, struct slim_msg_txn *txn) + int ret = 0; + + spin_lock_irqsave(&ctrl->txn_lock, flags); +- ret = idr_alloc_cyclic(&ctrl->tid_idr, txn, 0, ++ ret = idr_alloc_cyclic(&ctrl->tid_idr, txn, 1, + SLIM_MAX_TIDS, GFP_ATOMIC); + if (ret < 0) { + spin_unlock_irqrestore(&ctrl->txn_lock, flags); +-- +2.30.2 + diff --git a/queue-5.4/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch b/queue-5.4/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch new file mode 100644 index 00000000000..340fd76a19e --- /dev/null +++ b/queue-5.4/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch @@ -0,0 +1,59 @@ +From c1388104b0c03aeedb6d7618434661b8aeb2397c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Aug 2021 09:24:28 +0100 +Subject: slimbus: ngd: reset dma setup during runtime pm + +From: Srinivas Kandagatla + +[ Upstream commit d77772538f00b7265deace6e77e555ee18365ad0 ] + +During suspend/resume NGD remote instance is power cycled along +with remotely controlled bam dma engine. +So Reset the dma configuration during this suspend resume path +so that we are not dealing with any stale dma setup. + +Without this transactions timeout after first suspend resume path. + +Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") +Cc: +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20210809082428.11236-5-srinivas.kandagatla@linaro.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/slimbus/qcom-ngd-ctrl.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c +index b60541c3f72d..09ecd1fb24ae 100644 +--- a/drivers/slimbus/qcom-ngd-ctrl.c ++++ b/drivers/slimbus/qcom-ngd-ctrl.c +@@ -1061,7 +1061,8 @@ static void qcom_slim_ngd_setup(struct qcom_slim_ngd_ctrl *ctrl) + { + u32 cfg = readl_relaxed(ctrl->ngd->base); + +- if (ctrl->state == QCOM_SLIM_NGD_CTRL_DOWN) ++ if (ctrl->state == QCOM_SLIM_NGD_CTRL_DOWN || ++ ctrl->state == QCOM_SLIM_NGD_CTRL_ASLEEP) + qcom_slim_ngd_init_dma(ctrl); + + /* By default enable message queues */ +@@ -1112,6 +1113,7 @@ static int qcom_slim_ngd_power_up(struct qcom_slim_ngd_ctrl *ctrl) + dev_info(ctrl->dev, "Subsys restart: ADSP active framer\n"); + return 0; + } ++ qcom_slim_ngd_setup(ctrl); + return 0; + } + +@@ -1500,6 +1502,7 @@ static int __maybe_unused qcom_slim_ngd_runtime_suspend(struct device *dev) + struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev); + int ret = 0; + ++ qcom_slim_ngd_exit_dma(ctrl); + if (!ctrl->qmi.handle) + return 0; + +-- +2.30.2 + diff --git a/queue-5.4/tracing-histogram-fix-null-pointer-dereference-on-st.patch b/queue-5.4/tracing-histogram-fix-null-pointer-dereference-on-st.patch new file mode 100644 index 00000000000..e40ff1335db --- /dev/null +++ b/queue-5.4/tracing-histogram-fix-null-pointer-dereference-on-st.patch @@ -0,0 +1,92 @@ +From 6acf6d440e544a9a71a23538d6536142dd8cb23e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 8 Aug 2021 00:30:11 -0400 +Subject: tracing / histogram: Fix NULL pointer dereference on strcmp() on NULL + event name + +From: Steven Rostedt (VMware) + +[ Upstream commit 5acce0bff2a0420ce87d4591daeb867f47d552c2 ] + +The following commands: + + # echo 'read_max u64 size;' > synthetic_events + # echo 'hist:keys=common_pid:count=count:onmax($count).trace(read_max,count)' > events/syscalls/sys_enter_read/trigger + +Causes: + + BUG: kernel NULL pointer dereference, address: 0000000000000000 + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 0 P4D 0 + Oops: 0000 [#1] PREEMPT SMP + CPU: 4 PID: 1763 Comm: bash Not tainted 5.14.0-rc2-test+ #155 + Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 +v03.03 07/14/2016 + RIP: 0010:strcmp+0xc/0x20 + Code: 75 f7 31 c0 0f b6 0c 06 88 0c 02 48 83 c0 01 84 c9 75 f1 4c 89 c0 +c3 0f 1f 80 00 00 00 00 31 c0 eb 08 48 83 c0 01 84 d2 74 0f <0f> b6 14 07 +3a 14 06 74 ef 19 c0 83 c8 01 c3 31 c0 c3 66 90 48 89 + RSP: 0018:ffffb5fdc0963ca8 EFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffffffffb3a4e040 RCX: 0000000000000000 + RDX: 0000000000000000 RSI: ffff9714c0d0b640 RDI: 0000000000000000 + RBP: 0000000000000000 R08: 00000022986b7cde R09: ffffffffb3a4dff8 + R10: 0000000000000000 R11: 0000000000000000 R12: ffff9714c50603c8 + R13: 0000000000000000 R14: ffff97143fdf9e48 R15: ffff9714c01a2210 + FS: 00007f1fa6785740(0000) GS:ffff9714da400000(0000) +knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000000000000000 CR3: 000000002d863004 CR4: 00000000001706e0 + Call Trace: + __find_event_file+0x4e/0x80 + action_create+0x6b7/0xeb0 + ? kstrdup+0x44/0x60 + event_hist_trigger_func+0x1a07/0x2130 + trigger_process_regex+0xbd/0x110 + event_trigger_write+0x71/0xd0 + vfs_write+0xe9/0x310 + ksys_write+0x68/0xe0 + do_syscall_64+0x3b/0x90 + entry_SYSCALL_64_after_hwframe+0x44/0xae + RIP: 0033:0x7f1fa6879e87 + +The problem was the "trace(read_max,count)" where the "count" should be +"$count" as "onmax()" only handles variables (although it really should be +able to figure out that "count" is a field of sys_enter_read). But there's +a path that does not find the variable and ends up passing a NULL for the +event, which ends up getting passed to "strcmp()". + +Add a check for NULL to return and error on the command with: + + # cat error_log + hist:syscalls:sys_enter_read: error: Couldn't create or find variable + Command: hist:keys=common_pid:count=count:onmax($count).trace(read_max,count) + ^ +Link: https://lkml.kernel.org/r/20210808003011.4037f8d0@oasis.local.home + +Cc: Masami Hiramatsu +Cc: stable@vger.kernel.org +Fixes: 50450603ec9cb tracing: Add 'onmax' hist trigger action support +Reviewed-by: Tom Zanussi +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Sasha Levin +--- + kernel/trace/trace_events_hist.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c +index e40712abe089..f63766366e23 100644 +--- a/kernel/trace/trace_events_hist.c ++++ b/kernel/trace/trace_events_hist.c +@@ -4291,6 +4291,8 @@ trace_action_create_field_var(struct hist_trigger_data *hist_data, + event = data->match_data.event; + } + ++ if (!event) ++ goto free; + /* + * At this point, we're looking at a field on another + * event. Because we can't modify a hist trigger on +-- +2.30.2 +