From: Sasha Levin Date: Tue, 24 Aug 2021 02:59:52 +0000 (-0400) Subject: Fixes for 4.19 X-Git-Tag: v5.13.13~12 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1a4608e1c7d8c7824613997c2e2ac7fe5ff85870;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/alsa-hda-fix-the-capture-switch-value-change-notific.patch b/queue-4.19/alsa-hda-fix-the-capture-switch-value-change-notific.patch new file mode 100644 index 00000000000..ce732d02a19 --- /dev/null +++ b/queue-4.19/alsa-hda-fix-the-capture-switch-value-change-notific.patch @@ -0,0 +1,57 @@ +From f5573d2ecf7af422da38dbe35365f34167e4508f 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 6099a9f1cb3d..ff263ad19230 100644 +--- a/sound/pci/hda/hda_generic.c ++++ b/sound/pci/hda/hda_generic.c +@@ -3470,7 +3470,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; +@@ -3480,9 +3480,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-4.19/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch b/queue-4.19/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch new file mode 100644 index 00000000000..2fa26f3e3f2 --- /dev/null +++ b/queue-4.19/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch @@ -0,0 +1,48 @@ +From 15051ceb37950bd1076f3011c3833e9cee4a18c4 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 501ac836777a..682ee41ec75c 100644 +--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c ++++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c +@@ -135,7 +135,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-4.19/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch b/queue-4.19/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch new file mode 100644 index 00000000000..4380868dfe3 --- /dev/null +++ b/queue-4.19/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch @@ -0,0 +1,124 @@ +From e772adf76b5370e52c46a0d39860d6bf1f1f162e 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 d29f4cf125d2..6f02a3f77fa8 100644 +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -9556,8 +9556,14 @@ static int btrfs_rename_exchange(struct inode *old_dir, + bool sync_log_dest = false; + bool commit_transaction = 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; + + btrfs_init_log_ctx(&ctx_root, old_inode); +-- +2.30.2 + diff --git a/queue-4.19/fs-warn-about-impending-deprecation-of-mandatory-loc.patch b/queue-4.19/fs-warn-about-impending-deprecation-of-mandatory-loc.patch new file mode 100644 index 00000000000..720a7e52303 --- /dev/null +++ b/queue-4.19/fs-warn-about-impending-deprecation-of-mandatory-loc.patch @@ -0,0 +1,41 @@ +From 9142046b5f08add7400a0bdd5a7912e144bf9c8d 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 8d2bf350e7c6..2f3c6a0350a8 100644 +--- a/fs/namespace.c ++++ b/fs/namespace.c +@@ -1611,8 +1611,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-4.19/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch b/queue-4.19/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch new file mode 100644 index 00000000000..a7fd2002edd --- /dev/null +++ b/queue-4.19/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch @@ -0,0 +1,140 @@ +From a834fde1fd61576ccaccff665d3906e63b9ba32a 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 7895320e50c1..2172d1efa71e 100644 +--- a/drivers/ipack/carriers/tpci200.c ++++ b/drivers/ipack/carriers/tpci200.c +@@ -94,16 +94,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, +@@ -532,7 +529,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); +@@ -543,7 +540,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), +@@ -551,7 +548,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 +@@ -574,7 +571,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 */ +@@ -586,7 +583,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 */ +@@ -597,19 +594,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; + } +@@ -619,6 +613,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-4.19/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch b/queue-4.19/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch new file mode 100644 index 00000000000..e944e8dcb57 --- /dev/null +++ b/queue-4.19/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch @@ -0,0 +1,107 @@ +From b3c86407fa15737ff2938408fd2ec29823f8ceb9 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 2172d1efa71e..4c8da6af2516 100644 +--- a/drivers/ipack/carriers/tpci200.c ++++ b/drivers/ipack/carriers/tpci200.c +@@ -259,7 +259,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) */ +@@ -271,7 +271,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) */ +@@ -282,7 +282,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) */ +@@ -293,7 +293,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 */ +@@ -307,7 +307,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 */ +@@ -346,18 +346,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-4.19/locks-print-a-warning-when-mount-fails-due-to-lack-o.patch b/queue-4.19/locks-print-a-warning-when-mount-fails-due-to-lack-o.patch new file mode 100644 index 00000000000..1151d9d1693 --- /dev/null +++ b/queue-4.19/locks-print-a-warning-when-mount-fails-due-to-lack-o.patch @@ -0,0 +1,78 @@ +From 60802be7059cb50b20033a525486f057eab83504 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 15 Aug 2019 15:21:17 -0400 +Subject: locks: print a warning when mount fails due to lack of "mand" support + +From: Jeff Layton + +[ Upstream commit df2474a22c42ce419b67067c52d71da06c385501 ] + +Since 9e8925b67a ("locks: Allow disabling mandatory locking at compile +time"), attempts to mount filesystems with "-o mand" will fail. +Unfortunately, there is no other indiciation of the reason for the +failure. + +Change how the function is defined for better readability. When +CONFIG_MANDATORY_FILE_LOCKING is disabled, printk a warning when +someone attempts to mount with -o mand. + +Also, add a blurb to the mandatory-locking.txt file to explain about +the "mand" option, and the behavior one should expect when it is +disabled. + +Reported-by: Jan Kara +Reviewed-by: Jan Kara +Signed-off-by: Jeff Layton +Signed-off-by: Sasha Levin +--- + Documentation/filesystems/mandatory-locking.txt | 10 ++++++++++ + fs/namespace.c | 11 ++++++++--- + 2 files changed, 18 insertions(+), 3 deletions(-) + +diff --git a/Documentation/filesystems/mandatory-locking.txt b/Documentation/filesystems/mandatory-locking.txt +index 0979d1d2ca8b..a251ca33164a 100644 +--- a/Documentation/filesystems/mandatory-locking.txt ++++ b/Documentation/filesystems/mandatory-locking.txt +@@ -169,3 +169,13 @@ havoc if they lock crucial files. The way around it is to change the file + permissions (remove the setgid bit) before trying to read or write to it. + Of course, that might be a bit tricky if the system is hung :-( + ++7. The "mand" mount option ++-------------------------- ++Mandatory locking is disabled on all filesystems by default, and must be ++administratively enabled by mounting with "-o mand". That mount option ++is only allowed if the mounting task has the CAP_SYS_ADMIN capability. ++ ++Since kernel v4.5, it is possible to disable mandatory locking ++altogether by setting CONFIG_MANDATORY_FILE_LOCKING to "n". A kernel ++with this disabled will reject attempts to mount filesystems with the ++"mand" mount option with the error status EPERM. +diff --git a/fs/namespace.c b/fs/namespace.c +index edd397fa2991..8d2bf350e7c6 100644 +--- a/fs/namespace.c ++++ b/fs/namespace.c +@@ -1610,13 +1610,18 @@ static inline bool may_mount(void) + return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN); + } + ++#ifdef CONFIG_MANDATORY_FILE_LOCKING + static inline bool may_mandlock(void) + { +-#ifndef CONFIG_MANDATORY_FILE_LOCKING +- return false; +-#endif + return capable(CAP_SYS_ADMIN); + } ++#else ++static inline bool may_mandlock(void) ++{ ++ pr_warn("VFS: \"mand\" mount option not supported"); ++ return false; ++} ++#endif + + /* + * Now umount can handle mount points as well as block devices. +-- +2.30.2 + diff --git a/queue-4.19/mmc-dw_mmc-fix-hang-on-data-crc-error.patch b/queue-4.19/mmc-dw_mmc-fix-hang-on-data-crc-error.patch new file mode 100644 index 00000000000..bacad05b796 --- /dev/null +++ b/queue-4.19/mmc-dw_mmc-fix-hang-on-data-crc-error.patch @@ -0,0 +1,73 @@ +From 681b073b190ba90fb69d6548249fab07ee06e889 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 22c454c7aaca..8e09586f880f 100644 +--- a/drivers/mmc/host/dw_mmc.c ++++ b/drivers/mmc/host/dw_mmc.c +@@ -2043,8 +2043,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; + } +@@ -2068,10 +2068,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; + } +@@ -2104,10 +2104,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-4.19/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch b/queue-4.19/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch new file mode 100644 index 00000000000..2c81fcb79d2 --- /dev/null +++ b/queue-4.19/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch @@ -0,0 +1,45 @@ +From c4644ab77b19e83ee8172f6933cb6a2ef2f93924 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 f287a9f919da..7e873b6b7d55 100644 +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -1882,6 +1882,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-4.19/series b/queue-4.19/series index 33e2c9ab6b3..103932a5303 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -67,3 +67,16 @@ ptp_pch-restore-dependency-on-pci.patch net-qlcnic-add-missed-unlock-in-qlcnic_83xx_flash_re.patch net-mdio-mux-don-t-ignore-memory-allocation-errors.patch net-mdio-mux-handle-eprobe_defer-correctly.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 +locks-print-a-warning-when-mount-fails-due-to-lack-o.patch +fs-warn-about-impending-deprecation-of-mandatory-loc.patch diff --git a/queue-4.19/slimbus-messaging-check-for-valid-transaction-id.patch b/queue-4.19/slimbus-messaging-check-for-valid-transaction-id.patch new file mode 100644 index 00000000000..ca1e71296de --- /dev/null +++ b/queue-4.19/slimbus-messaging-check-for-valid-transaction-id.patch @@ -0,0 +1,53 @@ +From 5d313abcc78565ac724d2392cf143e76a77e964f 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-4.19/slimbus-messaging-start-transaction-ids-from-1-inste.patch b/queue-4.19/slimbus-messaging-start-transaction-ids-from-1-inste.patch new file mode 100644 index 00000000000..1c6335ebf0d --- /dev/null +++ b/queue-4.19/slimbus-messaging-start-transaction-ids-from-1-inste.patch @@ -0,0 +1,42 @@ +From 802340a7b731846d4335fdcc961a88a820c3c001 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-4.19/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch b/queue-4.19/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch new file mode 100644 index 00000000000..1c2665e9084 --- /dev/null +++ b/queue-4.19/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch @@ -0,0 +1,59 @@ +From cb6a23820b8556a20dbbf79daaceae4045cbf9f1 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 44021620d101..1a5311fb45a5 100644 +--- a/drivers/slimbus/qcom-ngd-ctrl.c ++++ b/drivers/slimbus/qcom-ngd-ctrl.c +@@ -1060,7 +1060,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 */ +@@ -1111,6 +1112,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; + } + +@@ -1496,6 +1498,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-4.19/tracing-histogram-fix-null-pointer-dereference-on-st.patch b/queue-4.19/tracing-histogram-fix-null-pointer-dereference-on-st.patch new file mode 100644 index 00000000000..27070be6a46 --- /dev/null +++ b/queue-4.19/tracing-histogram-fix-null-pointer-dereference-on-st.patch @@ -0,0 +1,92 @@ +From 4c9b9f335b151fa5f5f1502b4ff18682586a811d 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 bbde8d3d6c8a..44d1340634f6 100644 +--- a/kernel/trace/trace_events_hist.c ++++ b/kernel/trace/trace_events_hist.c +@@ -3786,6 +3786,8 @@ onmatch_create_field_var(struct hist_trigger_data *hist_data, + event = data->onmatch.match_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 +