--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: "Shih-Yuan Lee (FourDollars)" <sylee@canonical.com>
+Date: Mon, 14 Aug 2017 18:00:47 +0800
+Subject: ALSA: hda/realtek - Fix pincfg for Dell XPS 13 9370
+
+From: "Shih-Yuan Lee (FourDollars)" <sylee@canonical.com>
+
+commit 8df4b0031067758d8b0a3bfde7d35e980d0376d5 upstream
+
+The initial pin configs for Dell headset mode of ALC3271 has changed.
+
+/sys/class/sound/hwC0D0/init_pin_configs: (BIOS 0.1.4)
+0x12 0xb7a60130
+0x13 0xb8a61140
+0x14 0x40000000
+0x16 0x411111f0
+0x17 0x90170110
+0x18 0x411111f0
+0x19 0x411111f0
+0x1a 0x411111f0
+0x1b 0x411111f0
+0x1d 0x4087992d
+0x1e 0x411111f0
+0x21 0x04211020
+
+has changed to ...
+
+/sys/class/sound/hwC0D0/init_pin_configs: (BIOS 0.2.0)
+0x12 0xb7a60130
+0x13 0x40000000
+0x14 0x411111f0
+0x16 0x411111f0
+0x17 0x90170110
+0x18 0x411111f0
+0x19 0x411111f0
+0x1a 0x411111f0
+0x1b 0x411111f0
+0x1d 0x4067992d
+0x1e 0x411111f0
+0x21 0x04211020
+
+Fixes: b4576de87243 ("ALSA: hda/realtek - Fix typo of pincfg for Dell quirk")
+Signed-off-by: Shih-Yuan Lee (FourDollars) <sylee@canonical.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -6212,7 +6212,6 @@ static const struct snd_hda_pin_quirk al
+ SND_HDA_PIN_QUIRK(0x10ec0299, 0x1028, "Dell", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
+ ALC225_STANDARD_PINS,
+ {0x12, 0xb7a60130},
+- {0x13, 0xb8a61140},
+ {0x17, 0x90170110}),
+ {}
+ };
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 19 May 2020 14:59:45 +0200
+Subject: mtd: rawnand: diskonchip: Fix the probe error path
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit c5be12e45940f1aa1b5dfa04db5d15ad24f7c896 upstream
+
+Not sure nand_cleanup() is the right function to call here but in any
+case it is not nand_release(). Indeed, even a comment says that
+calling nand_release() is a bit of a hack as there is no MTD device to
+unregister. So switch to nand_cleanup() for now and drop this
+comment.
+
+There is no Fixes tag applying here as the use of nand_release()
+in this driver predates by far the introduction of nand_cleanup() in
+commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+which makes this change possible. However, pointing this commit as the
+culprit for backporting purposes makes sense even if it did not intruce
+any bug.
+
+Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-13-miquel.raynal@bootlin.com
+[sudip: manual backport to old file]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/diskonchip.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/mtd/nand/diskonchip.c
++++ b/drivers/mtd/nand/diskonchip.c
+@@ -1608,13 +1608,10 @@ static int __init doc_probe(unsigned lon
+ numchips = doc2001_init(mtd);
+
+ if ((ret = nand_scan(mtd, numchips)) || (ret = doc->late_init(mtd))) {
+- /* DBB note: i believe nand_release is necessary here, as
++ /* DBB note: i believe nand_cleanup is necessary here, as
+ buffers may have been allocated in nand_base. Check with
+ Thomas. FIX ME! */
+- /* nand_release will call mtd_device_unregister, but we
+- haven't yet added it. This is handled without incident by
+- mtd_device_unregister, as far as I can tell. */
+- nand_release(mtd);
++ nand_cleanup(nand);
+ kfree(mtd);
+ goto fail;
+ }
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 19 May 2020 15:00:06 +0200
+Subject: mtd: rawnand: orion: Fix the probe error path
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit be238fbf78e4c7c586dac235ab967d3e565a4d1a upstream
+
+nand_release() is supposed be called after MTD device registration.
+Here, only nand_scan() happened, so use nand_cleanup() instead.
+
+There is no real Fixes tag applying here as the use of nand_release()
+in this driver predates by far the introduction of nand_cleanup() in
+commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+which makes this change possible. However, pointing this commit as the
+culprit for backporting purposes makes sense even if this commit is not
+introducing any bug.
+
+Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-34-miquel.raynal@bootlin.com
+[sudip: manual backport to old file]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/orion_nand.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/orion_nand.c
++++ b/drivers/mtd/nand/orion_nand.c
+@@ -165,7 +165,7 @@ static int __init orion_nand_probe(struc
+ ret = mtd_device_parse_register(mtd, NULL, &ppdata,
+ board->parts, board->nr_parts);
+ if (ret) {
+- nand_release(mtd);
++ nand_cleanup(nc);
+ goto no_dev;
+ }
+
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 19 May 2020 15:00:13 +0200
+Subject: mtd: rawnand: pasemi: Fix the probe error path
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit f51466901c07e6930435d30b02a21f0841174f61 upstream
+
+nand_cleanup() is supposed to be called on error after a successful
+call to nand_scan() to free all NAND resources.
+
+There is no real Fixes tag applying here as the use of nand_release()
+in this driver predates by far the introduction of nand_cleanup() in
+commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+which makes this change possible, hence pointing it as the commit to
+fix for backporting purposes, even if this commit is not introducing
+any bug.
+
+Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-41-miquel.raynal@bootlin.com
+[sudip: manual backport to old file]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/pasemi_nand.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/pasemi_nand.c
++++ b/drivers/mtd/nand/pasemi_nand.c
+@@ -167,7 +167,7 @@ static int pasemi_nand_probe(struct plat
+ if (mtd_device_register(pasemi_nand_mtd, NULL, 0)) {
+ printk(KERN_ERR "pasemi_nand: Unable to register MTD device\n");
+ err = -ENODEV;
+- goto out_lpc;
++ goto out_cleanup_nand;
+ }
+
+ printk(KERN_INFO "PA Semi NAND flash at %08llx, control at I/O %x\n",
+@@ -175,6 +175,8 @@ static int pasemi_nand_probe(struct plat
+
+ return 0;
+
++ out_cleanup_nand:
++ nand_cleanup(chip);
+ out_lpc:
+ release_region(lpcctl, 4);
+ out_ior:
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 19 May 2020 15:00:15 +0200
+Subject: mtd: rawnand: plat_nand: Fix the probe error path
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 5284024b4dac5e94f7f374ca905c7580dbc455e9 upstream
+
+nand_release() is supposed be called after MTD device registration.
+Here, only nand_scan() happened, so use nand_cleanup() instead.
+
+There is no real Fixes tag applying here as the use of nand_release()
+in this driver predates by far the introduction of nand_cleanup() in
+commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+which makes this change possible, hence pointing it as the commit to
+fix for backporting purposes, even if this commit is not introducing
+any bug.
+
+Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-43-miquel.raynal@bootlin.com
+[sudip: manual backport to old file]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/plat_nand.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/plat_nand.c
++++ b/drivers/mtd/nand/plat_nand.c
+@@ -102,7 +102,7 @@ static int plat_nand_probe(struct platfo
+ if (!err)
+ return err;
+
+- nand_release(&data->mtd);
++ nand_cleanup(&data->chip);
+ out:
+ if (pdata->ctrl.remove)
+ pdata->ctrl.remove(pdev);
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 19 May 2020 15:00:21 +0200
+Subject: mtd: rawnand: sharpsl: Fix the probe error path
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 0f44b3275b3798ccb97a2f51ac85871c30d6fbbc upstream
+
+nand_release() is supposed be called after MTD device registration.
+Here, only nand_scan() happened, so use nand_cleanup() instead.
+
+There is no Fixes tag applying here as the use of nand_release()
+in this driver predates by far the introduction of nand_cleanup() in
+commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+which makes this change possible. However, pointing this commit as the
+culprit for backporting purposes makes sense.
+
+Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-49-miquel.raynal@bootlin.com
+[sudip: manual backport to old file]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/sharpsl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/sharpsl.c
++++ b/drivers/mtd/nand/sharpsl.c
+@@ -189,7 +189,7 @@ static int sharpsl_nand_probe(struct pla
+ return 0;
+
+ err_add:
+- nand_release(&sharpsl->mtd);
++ nand_cleanup(this);
+
+ err_scan:
+ iounmap(sharpsl->io);
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 19 May 2020 15:00:23 +0200
+Subject: mtd: rawnand: socrates: Fix the probe error path
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 9c6c2e5cc77119ce0dacb4f9feedb73ce0354421 upstream
+
+nand_release() is supposed be called after MTD device registration.
+Here, only nand_scan() happened, so use nand_cleanup() instead.
+
+There is no real Fixes tag applying here as the use of nand_release()
+in this driver predates by far the introduction of nand_cleanup() in
+commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+which makes this change possible. However, pointing this commit as the
+culprit for backporting purposes makes sense even if this commit is not
+introducing any bug.
+
+Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-51-miquel.raynal@bootlin.com
+[sudip: manual backport to old file]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/socrates_nand.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/socrates_nand.c
++++ b/drivers/mtd/nand/socrates_nand.c
+@@ -204,7 +204,7 @@ static int socrates_nand_probe(struct pl
+ if (!res)
+ return res;
+
+- nand_release(mtd);
++ nand_cleanup(nand_chip);
+
+ out:
+ iounmap(host->io_base);
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 19 May 2020 15:00:29 +0200
+Subject: mtd: rawnand: tmio: Fix the probe error path
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 75e9a330a9bd48f97a55a08000236084fe3dae56 upstream
+
+nand_release() is supposed be called after MTD device registration.
+Here, only nand_scan() happened, so use nand_cleanup() instead.
+
+There is no real Fixes tag applying here as the use of nand_release()
+in this driver predates by far the introduction of nand_cleanup() in
+commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+which makes this change possible. However, pointing this commit as the
+culprit for backporting purposes makes sense even if this commit is not
+introducing any bug.
+
+Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-57-miquel.raynal@bootlin.com
+[sudip: manual backport to old file]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/tmio_nand.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/tmio_nand.c
++++ b/drivers/mtd/nand/tmio_nand.c
+@@ -445,7 +445,7 @@ static int tmio_probe(struct platform_de
+ if (!retval)
+ return retval;
+
+- nand_release(mtd);
++ nand_cleanup(nand_chip);
+
+ err_irq:
+ tmio_hw_stop(dev, tmio);
cifs-revalidate-mapping-when-we-open-files-for-smb1-.patch
cifs-silently-ignore-unknown-oplock-break-handle.patch
bpf-x86-validate-computation-of-branch-displacements-for-x86-64.patch
+alsa-hda-realtek-fix-pincfg-for-dell-xps-13-9370.patch
+mtd-rawnand-tmio-fix-the-probe-error-path.patch
+mtd-rawnand-socrates-fix-the-probe-error-path.patch
+mtd-rawnand-sharpsl-fix-the-probe-error-path.patch
+mtd-rawnand-plat_nand-fix-the-probe-error-path.patch
+mtd-rawnand-pasemi-fix-the-probe-error-path.patch
+mtd-rawnand-orion-fix-the-probe-error-path.patch
+mtd-rawnand-diskonchip-fix-the-probe-error-path.patch
+tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch
--- /dev/null
+From foo@baz Fri Apr 9 11:45:07 AM CEST 2021
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Wed, 6 May 2020 10:36:18 -0400
+Subject: tracing: Add a vmalloc_sync_mappings() for safe measure
+
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+
+commit 11f5efc3ab66284f7aaacc926e9351d658e2577b upstream
+
+x86_64 lazily maps in the vmalloc pages, and the way this works with per_cpu
+areas can be complex, to say the least. Mappings may happen at boot up, and
+if nothing synchronizes the page tables, those page mappings may not be
+synced till they are used. This causes issues for anything that might touch
+one of those mappings in the path of the page fault handler. When one of
+those unmapped mappings is touched in the page fault handler, it will cause
+another page fault, which in turn will cause a page fault, and leave us in
+a loop of page faults.
+
+Commit 763802b53a42 ("x86/mm: split vmalloc_sync_all()") split
+vmalloc_sync_all() into vmalloc_sync_unmappings() and
+vmalloc_sync_mappings(), as on system exit, it did not need to do a full
+sync on x86_64 (although it still needed to be done on x86_32). By chance,
+the vmalloc_sync_all() would synchronize the page mappings done at boot up
+and prevent the per cpu area from being a problem for tracing in the page
+fault handler. But when that synchronization in the exit of a task became a
+nop, it caused the problem to appear.
+
+Link: https://lore.kernel.org/r/20200429054857.66e8e333@oasis.local.home
+
+Cc: stable@vger.kernel.org
+Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code")
+Reported-by: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
+Suggested-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+[sudip: add header]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -26,6 +26,7 @@
+ #include <linux/linkage.h>
+ #include <linux/uaccess.h>
+ #include <linux/kprobes.h>
++#include <linux/vmalloc.h>
+ #include <linux/ftrace.h>
+ #include <linux/module.h>
+ #include <linux/percpu.h>
+@@ -6626,6 +6627,19 @@ static int allocate_trace_buffers(struct
+ */
+ allocate_snapshot = false;
+ #endif
++
++ /*
++ * Because of some magic with the way alloc_percpu() works on
++ * x86_64, we need to synchronize the pgd of all the tables,
++ * otherwise the trace events that happen in x86_64 page fault
++ * handlers can't cope with accessing the chance that a
++ * alloc_percpu()'d memory might be touched in the page fault trace
++ * event. Oh, and we need to audit all other alloc_percpu() and vmalloc()
++ * calls in tracing, because something might get triggered within a
++ * page fault trace event!
++ */
++ vmalloc_sync_mappings();
++
+ return 0;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
