--- /dev/null
+From f5573d2ecf7af422da38dbe35365f34167e4508f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Aug 2021 18:14:41 +0200
+Subject: ALSA: hda - fix the 'Capture Switch' value change notifications
+
+From: Jaroslav Kysela <perex@perex.cz>
+
+[ 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: <stable@kernel.org>
+Signed-off-by: Jaroslav Kysela <perex@perex.cz>
+Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 15051ceb37950bd1076f3011c3833e9cee4a18c4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Aug 2021 17:29:45 +0200
+Subject: ASoC: intel: atom: Fix breakage for PCM buffer address setup
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ 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 <hdegoede@redhat.com>
+Cc: <stable@vger.kernel.org>
+Acked-by: Mark Brown <broonie@kernel.org>
+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 <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From e772adf76b5370e52c46a0d39860d6bf1f1f162e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <neilb@suse.de>
+
+[ 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): [<ffffffffbd1104f5>] console_trylock_spinning+0x185/0x1a0
+ [1194842.672477] hardirqs last disabled at (1740): [<ffffffffbd1104cc>] console_trylock_spinning+0x15c/0x1a0
+ [1194842.672482] softirqs last enabled at (1666): [<ffffffffbdc002e1>] __do_softirq+0x2e1/0x50a
+ [1194842.672491] softirqs last disabled at (1651): [<ffffffffbd08aab7>] __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 <nborisov@suse.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 9142046b5f08add7400a0bdd5a7912e144bf9c8d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Aug 2021 09:29:50 -0400
+Subject: fs: warn about impending deprecation of mandatory locks
+
+From: Jeff Layton <jlayton@kernel.org>
+
+[ 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 <jlayton@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From a834fde1fd61576ccaccff665d3906e63b9ba32a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Aug 2021 18:03:18 +0800
+Subject: ipack: tpci200: fix many double free issues in tpci200_pci_probe
+
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+
+[ 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 <mudongliangabcd@gmail.com>
+Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Link: https://lore.kernel.org/r/20210810100323.3938492-1-mudongliangabcd@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From b3c86407fa15737ff2938408fd2ec29823f8ceb9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Aug 2021 18:03:19 +0800
+Subject: ipack: tpci200: fix memory leak in the tpci200_register
+
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+
+[ 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 <mudongliangabcd@gmail.com>
+Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Link: https://lore.kernel.org/r/20210810100323.3938492-2-mudongliangabcd@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 60802be7059cb50b20033a525486f057eab83504 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <jlayton@kernel.org>
+
+[ 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 <jack@suse.cz>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 681b073b190ba90fb69d6548249fab07ee06e889 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 30 Jun 2021 12:22:32 +0200
+Subject: mmc: dw_mmc: Fix hang on data CRC error
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ 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 <vincent.whitchurch@axis.com>
+Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From c4644ab77b19e83ee8172f6933cb6a2ef2f93924 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 21 Jul 2021 22:58:58 -0400
+Subject: PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI
+
+From: Marcin Bachry <hegel666@gmail.com>
+
+[ 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 <hegel666@gmail.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Prike Liang <prike.liang@amd.com>
+Cc: Shyam Sundar S K <shyam-sundar.s-k@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From 5d313abcc78565ac724d2392cf143e76a77e964f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Aug 2021 09:24:26 +0100
+Subject: slimbus: messaging: check for valid transaction id
+
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+[ 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: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Link: https://lore.kernel.org/r/20210809082428.11236-3-srinivas.kandagatla@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 802340a7b731846d4335fdcc961a88a820c3c001 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Aug 2021 09:24:25 +0100
+Subject: slimbus: messaging: start transaction ids from 1 instead of zero
+
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+[ 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: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Link: https://lore.kernel.org/r/20210809082428.11236-2-srinivas.kandagatla@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From cb6a23820b8556a20dbbf79daaceae4045cbf9f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Aug 2021 09:24:28 +0100
+Subject: slimbus: ngd: reset dma setup during runtime pm
+
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+[ 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: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Link: https://lore.kernel.org/r/20210809082428.11236-5-srinivas.kandagatla@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 4c9b9f335b151fa5f5f1502b4ff18682586a811d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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) <rostedt@goodmis.org>
+
+[ 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 <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 50450603ec9cb tracing: Add 'onmax' hist trigger action support
+Reviewed-by: Tom Zanussi <zanussi@kernel.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
