--- /dev/null
+From 945234064f76457aa40f208a4e1bed3f4c61408c Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Wed, 19 Dec 2018 20:00:42 +0900
+Subject: ALSA: bebob: fix model-id of unit for Apogee Ensemble
+
+[ Upstream commit 644b2e97405b0b74845e1d3c2b4fe4c34858062b ]
+
+This commit fixes hard-coded model-id for an unit of Apogee Ensemble with
+a correct value. This unit uses DM1500 ASIC produced ArchWave AG (formerly
+known as BridgeCo AG).
+
+I note that this model supports three modes in the number of data channels
+in tx/rx streams; 8 ch pairs, 10 ch pairs, 18 ch pairs. The mode is
+switched by Vendor-dependent AV/C command, like:
+
+$ cd linux-firewire-utils
+$ ./firewire-request /dev/fw1 fcp 0x00ff000003dbeb0600000000 (8ch pairs)
+$ ./firewire-request /dev/fw1 fcp 0x00ff000003dbeb0601000000 (10ch pairs)
+$ ./firewire-request /dev/fw1 fcp 0x00ff000003dbeb0602000000 (18ch pairs)
+
+When switching between different mode, the unit disappears from IEEE 1394
+bus, then appears on the bus with different combination of stream formats.
+In a mode of 18 ch pairs, available sampling rate is up to 96.0 kHz, else
+up to 192.0 kHz.
+
+$ ./hinawa-config-rom-printer /dev/fw1
+{ 'bus-info': { 'adj': False,
+ 'bmc': True,
+ 'chip_ID': 21474898341,
+ 'cmc': True,
+ 'cyc_clk_acc': 100,
+ 'generation': 2,
+ 'imc': True,
+ 'isc': True,
+ 'link_spd': 2,
+ 'max_ROM': 1,
+ 'max_rec': 512,
+ 'name': '1394',
+ 'node_vendor_ID': 987,
+ 'pmc': False},
+ 'root-directory': [ ['HARDWARE_VERSION', 19],
+ [ 'NODE_CAPABILITIES',
+ { 'addressing': {'64': True, 'fix': True, 'prv': False},
+ 'misc': {'int': False, 'ms': False, 'spt': True},
+ 'state': { 'atn': False,
+ 'ded': False,
+ 'drq': True,
+ 'elo': False,
+ 'init': False,
+ 'lst': True,
+ 'off': False},
+ 'testing': {'bas': False, 'ext': False}}],
+ ['VENDOR', 987],
+ ['DESCRIPTOR', 'Apogee Electronics'],
+ ['MODEL', 126702],
+ ['DESCRIPTOR', 'Ensemble'],
+ ['VERSION', 5297],
+ [ 'UNIT',
+ [ ['SPECIFIER_ID', 41005],
+ ['VERSION', 65537],
+ ['MODEL', 126702],
+ ['DESCRIPTOR', 'Ensemble']]],
+ [ 'DEPENDENT_INFO',
+ [ ['SPECIFIER_ID', 2037],
+ ['VERSION', 1],
+ [(58, 'IMMEDIATE'), 16777159],
+ [(59, 'IMMEDIATE'), 1048576],
+ [(60, 'IMMEDIATE'), 16777159],
+ [(61, 'IMMEDIATE'), 6291456]]]]}
+
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/firewire/bebob/bebob.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c
+index fc19c99654aa..e4312afe2ce5 100644
+--- a/sound/firewire/bebob/bebob.c
++++ b/sound/firewire/bebob/bebob.c
+@@ -356,7 +356,7 @@ static const struct ieee1394_device_id bebob_id_table[] = {
+ /* Apogee Electronics, DA/AD/DD-16X (X-FireWire card) */
+ SND_BEBOB_DEV_ENTRY(VEN_APOGEE, 0x00010048, &spec_normal),
+ /* Apogee Electronics, Ensemble */
+- SND_BEBOB_DEV_ENTRY(VEN_APOGEE, 0x00001eee, &spec_normal),
++ SND_BEBOB_DEV_ENTRY(VEN_APOGEE, 0x01eeee, &spec_normal),
+ /* ESI, Quatafire610 */
+ SND_BEBOB_DEV_ENTRY(VEN_ESI, 0x00010064, &spec_normal),
+ /* AcousticReality, eARMasterOne */
+--
+2.19.1
+
--- /dev/null
+From 722323376df5fae098dd33210a1b1e581c4d8dbd Mon Sep 17 00:00:00 2001
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Thu, 15 Nov 2018 15:30:26 +0100
+Subject: clk: imx6q: reset exclusive gates on init
+
+[ Upstream commit f7542d817733f461258fd3a47d77da35b2d9fc81 ]
+
+The exclusive gates may be set up in the wrong way by software running
+before the clock driver comes up. In that case the exclusive setup is
+locked in its initial state, as the complementary function can't be
+activated without disabling the initial setup first.
+
+To avoid this lock situation, reset the exclusive gates to the off
+state and allow the kernel to provide the proper setup.
+
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Reviewed-by: Dong Aisheng <Aisheng.dong@nxp.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mach-imx/clk-imx6q.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
+index 5474a76803f0..936ed9bae595 100644
+--- a/arch/arm/mach-imx/clk-imx6q.c
++++ b/arch/arm/mach-imx/clk-imx6q.c
+@@ -222,8 +222,12 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
+ * lvds1_gate and lvds2_gate are pseudo-gates. Both can be
+ * independently configured as clock inputs or outputs. We treat
+ * the "output_enable" bit as a gate, even though it's really just
+- * enabling clock output.
++ * enabling clock output. Initially the gate bits are cleared, as
++ * otherwise the exclusive configuration gets locked in the setup done
++ * by software running before the clock driver, with no way to change
++ * it.
+ */
++ writel(readl(base + 0x160) & ~0x3c00, base + 0x160);
+ clk[IMX6QDL_CLK_LVDS1_GATE] = imx_clk_gate_exclusive("lvds1_gate", "lvds1_sel", base + 0x160, 10, BIT(12));
+ clk[IMX6QDL_CLK_LVDS2_GATE] = imx_clk_gate_exclusive("lvds2_gate", "lvds2_sel", base + 0x160, 11, BIT(13));
+
+--
+2.19.1
+
--- /dev/null
+From cff72847b45975c4e57040d23aae3cf222554705 Mon Sep 17 00:00:00 2001
+From: Nikos Tsironis <ntsironis@arrikto.com>
+Date: Wed, 31 Oct 2018 17:53:09 -0400
+Subject: dm kcopyd: Fix bug causing workqueue stalls
+
+[ Upstream commit d7e6b8dfc7bcb3f4f3a18313581f67486a725b52 ]
+
+When using kcopyd to run callbacks through dm_kcopyd_do_callback() or
+submitting copy jobs with a source size of 0, the jobs are pushed
+directly to the complete_jobs list, which could be under processing by
+the kcopyd thread. As a result, the kcopyd thread can continue running
+completed jobs indefinitely, without releasing the CPU, as long as
+someone keeps submitting new completed jobs through the aforementioned
+paths. Processing of work items, queued for execution on the same CPU as
+the currently running kcopyd thread, is thus stalled for excessive
+amounts of time, hurting performance.
+
+Running the following test, from the device mapper test suite [1],
+
+ dmtest run --suite snapshot -n parallel_io_to_many_snaps_N
+
+, with 8 active snapshots, we get, in dmesg, messages like the
+following:
+
+[68899.948523] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 95s!
+[68899.949282] Showing busy workqueues and worker pools:
+[68899.949288] workqueue events: flags=0x0
+[68899.949295] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
+[68899.949306] pending: vmstat_shepherd, cache_reap
+[68899.949331] workqueue mm_percpu_wq: flags=0x8
+[68899.949337] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
+[68899.949345] pending: vmstat_update
+[68899.949387] workqueue dm_bufio_cache: flags=0x8
+[68899.949392] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
+[68899.949400] pending: work_fn [dm_bufio]
+[68899.949423] workqueue kcopyd: flags=0x8
+[68899.949429] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
+[68899.949437] pending: do_work [dm_mod]
+[68899.949452] workqueue kcopyd: flags=0x8
+[68899.949458] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
+[68899.949466] in-flight: 13:do_work [dm_mod]
+[68899.949474] pending: do_work [dm_mod]
+[68899.949487] workqueue kcopyd: flags=0x8
+[68899.949493] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
+[68899.949501] pending: do_work [dm_mod]
+[68899.949515] workqueue kcopyd: flags=0x8
+[68899.949521] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
+[68899.949529] pending: do_work [dm_mod]
+[68899.949541] workqueue kcopyd: flags=0x8
+[68899.949547] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256
+[68899.949555] pending: do_work [dm_mod]
+[68899.949568] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=95s workers=4 idle: 27130 27223 1084
+
+Fix this by splitting the complete_jobs list into two parts: A user
+facing part, named callback_jobs, and one used internally by kcopyd,
+retaining the name complete_jobs. dm_kcopyd_do_callback() and
+dispatch_job() now push their jobs to the callback_jobs list, which is
+spliced to the complete_jobs list once, every time the kcopyd thread
+wakes up. This prevents kcopyd from hogging the CPU indefinitely and
+causing workqueue stalls.
+
+Re-running the aforementioned test:
+
+ * Workqueue stalls are eliminated
+ * The maximum writing time among all targets is reduced from 09m37.10s
+ to 06m04.85s and the total run time of the test is reduced from
+ 10m43.591s to 7m19.199s
+
+[1] https://github.com/jthornber/device-mapper-test-suite
+
+Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
+Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/dm-kcopyd.c | 19 ++++++++++++++-----
+ 1 file changed, 14 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/md/dm-kcopyd.c b/drivers/md/dm-kcopyd.c
+index 77833b65e01e..9e626e5df2f6 100644
+--- a/drivers/md/dm-kcopyd.c
++++ b/drivers/md/dm-kcopyd.c
+@@ -55,15 +55,17 @@ struct dm_kcopyd_client {
+ struct dm_kcopyd_throttle *throttle;
+
+ /*
+- * We maintain three lists of jobs:
++ * We maintain four lists of jobs:
+ *
+ * i) jobs waiting for pages
+ * ii) jobs that have pages, and are waiting for the io to be issued.
+- * iii) jobs that have completed.
++ * iii) jobs that don't need to do any IO and just run a callback
++ * iv) jobs that have completed.
+ *
+- * All three of these are protected by job_lock.
++ * All four of these are protected by job_lock.
+ */
+ spinlock_t job_lock;
++ struct list_head callback_jobs;
+ struct list_head complete_jobs;
+ struct list_head io_jobs;
+ struct list_head pages_jobs;
+@@ -583,6 +585,7 @@ static void do_work(struct work_struct *work)
+ struct dm_kcopyd_client *kc = container_of(work,
+ struct dm_kcopyd_client, kcopyd_work);
+ struct blk_plug plug;
++ unsigned long flags;
+
+ /*
+ * The order that these are called is *very* important.
+@@ -591,6 +594,10 @@ static void do_work(struct work_struct *work)
+ * list. io jobs call wake when they complete and it all
+ * starts again.
+ */
++ spin_lock_irqsave(&kc->job_lock, flags);
++ list_splice_tail_init(&kc->callback_jobs, &kc->complete_jobs);
++ spin_unlock_irqrestore(&kc->job_lock, flags);
++
+ blk_start_plug(&plug);
+ process_jobs(&kc->complete_jobs, kc, run_complete_job);
+ process_jobs(&kc->pages_jobs, kc, run_pages_job);
+@@ -608,7 +615,7 @@ static void dispatch_job(struct kcopyd_job *job)
+ struct dm_kcopyd_client *kc = job->kc;
+ atomic_inc(&kc->nr_jobs);
+ if (unlikely(!job->source.count))
+- push(&kc->complete_jobs, job);
++ push(&kc->callback_jobs, job);
+ else if (job->pages == &zero_page_list)
+ push(&kc->io_jobs, job);
+ else
+@@ -795,7 +802,7 @@ void dm_kcopyd_do_callback(void *j, int read_err, unsigned long write_err)
+ job->read_err = read_err;
+ job->write_err = write_err;
+
+- push(&kc->complete_jobs, job);
++ push(&kc->callback_jobs, job);
+ wake(kc);
+ }
+ EXPORT_SYMBOL(dm_kcopyd_do_callback);
+@@ -825,6 +832,7 @@ struct dm_kcopyd_client *dm_kcopyd_client_create(struct dm_kcopyd_throttle *thro
+ return ERR_PTR(-ENOMEM);
+
+ spin_lock_init(&kc->job_lock);
++ INIT_LIST_HEAD(&kc->callback_jobs);
+ INIT_LIST_HEAD(&kc->complete_jobs);
+ INIT_LIST_HEAD(&kc->io_jobs);
+ INIT_LIST_HEAD(&kc->pages_jobs);
+@@ -874,6 +882,7 @@ void dm_kcopyd_client_destroy(struct dm_kcopyd_client *kc)
+ /* Wait for completion of all jobs submitted by this client. */
+ wait_event(kc->destroyq, !atomic_read(&kc->nr_jobs));
+
++ BUG_ON(!list_empty(&kc->callback_jobs));
+ BUG_ON(!list_empty(&kc->complete_jobs));
+ BUG_ON(!list_empty(&kc->io_jobs));
+ BUG_ON(!list_empty(&kc->pages_jobs));
+--
+2.19.1
+
--- /dev/null
+From e00926630d886be2e48b37ec8d52e2c1dd4cc947 Mon Sep 17 00:00:00 2001
+From: Nikos Tsironis <ntsironis@arrikto.com>
+Date: Wed, 31 Oct 2018 17:53:08 -0400
+Subject: dm snapshot: Fix excessive memory usage and workqueue stalls
+
+[ Upstream commit 721b1d98fb517ae99ab3b757021cf81db41e67be ]
+
+kcopyd has no upper limit to the number of jobs one can allocate and
+issue. Under certain workloads this can lead to excessive memory usage
+and workqueue stalls. For example, when creating multiple dm-snapshot
+targets with a 4K chunk size and then writing to the origin through the
+page cache. Syncing the page cache causes a large number of BIOs to be
+issued to the dm-snapshot origin target, which itself issues an even
+larger (because of the BIO splitting taking place) number of kcopyd
+jobs.
+
+Running the following test, from the device mapper test suite [1],
+
+ dmtest run --suite snapshot -n many_snapshots_of_same_volume_N
+
+, with 8 active snapshots, results in the kcopyd job slab cache growing
+to 10G. Depending on the available system RAM this can lead to the OOM
+killer killing user processes:
+
+[463.492878] kthreadd invoked oom-killer: gfp_mask=0x6040c0(GFP_KERNEL|__GFP_COMP),
+ nodemask=(null), order=1, oom_score_adj=0
+[463.492894] kthreadd cpuset=/ mems_allowed=0
+[463.492948] CPU: 7 PID: 2 Comm: kthreadd Not tainted 4.19.0-rc7 #3
+[463.492950] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
+[463.492952] Call Trace:
+[463.492964] dump_stack+0x7d/0xbb
+[463.492973] dump_header+0x6b/0x2fc
+[463.492987] ? lockdep_hardirqs_on+0xee/0x190
+[463.493012] oom_kill_process+0x302/0x370
+[463.493021] out_of_memory+0x113/0x560
+[463.493030] __alloc_pages_slowpath+0xf40/0x1020
+[463.493055] __alloc_pages_nodemask+0x348/0x3c0
+[463.493067] cache_grow_begin+0x81/0x8b0
+[463.493072] ? cache_grow_begin+0x874/0x8b0
+[463.493078] fallback_alloc+0x1e4/0x280
+[463.493092] kmem_cache_alloc_node+0xd6/0x370
+[463.493098] ? copy_process.part.31+0x1c5/0x20d0
+[463.493105] copy_process.part.31+0x1c5/0x20d0
+[463.493115] ? __lock_acquire+0x3cc/0x1550
+[463.493121] ? __switch_to_asm+0x34/0x70
+[463.493129] ? kthread_create_worker_on_cpu+0x70/0x70
+[463.493135] ? finish_task_switch+0x90/0x280
+[463.493165] _do_fork+0xe0/0x6d0
+[463.493191] ? kthreadd+0x19f/0x220
+[463.493233] kernel_thread+0x25/0x30
+[463.493235] kthreadd+0x1bf/0x220
+[463.493242] ? kthread_create_on_cpu+0x90/0x90
+[463.493248] ret_from_fork+0x3a/0x50
+[463.493279] Mem-Info:
+[463.493285] active_anon:20631 inactive_anon:4831 isolated_anon:0
+[463.493285] active_file:80216 inactive_file:80107 isolated_file:435
+[463.493285] unevictable:0 dirty:51266 writeback:109372 unstable:0
+[463.493285] slab_reclaimable:31191 slab_unreclaimable:3483521
+[463.493285] mapped:526 shmem:4903 pagetables:1759 bounce:0
+[463.493285] free:33623 free_pcp:2392 free_cma:0
+...
+[463.493489] Unreclaimable slab info:
+[463.493513] Name Used Total
+[463.493522] bio-6 1028KB 1028KB
+[463.493525] bio-5 1028KB 1028KB
+[463.493528] dm_snap_pending_exception 236783KB 243789KB
+[463.493531] dm_exception 41KB 42KB
+[463.493534] bio-4 1216KB 1216KB
+[463.493537] bio-3 439396KB 439396KB
+[463.493539] kcopyd_job 6973427KB 6973427KB
+...
+[463.494340] Out of memory: Kill process 1298 (ruby2.3) score 1 or sacrifice child
+[463.494673] Killed process 1298 (ruby2.3) total-vm:435740kB, anon-rss:20180kB, file-rss:4kB, shmem-rss:0kB
+[463.506437] oom_reaper: reaped process 1298 (ruby2.3), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
+
+Moreover, issuing a large number of kcopyd jobs results in kcopyd
+hogging the CPU, while processing them. As a result, processing of work
+items, queued for execution on the same CPU as the currently running
+kcopyd thread, is stalled for long periods of time, hurting performance.
+Running the aforementioned test we get, in dmesg, messages like the
+following:
+
+[67501.194592] BUG: workqueue lockup - pool cpus=4 node=0 flags=0x0 nice=0 stuck for 27s!
+[67501.195586] Showing busy workqueues and worker pools:
+[67501.195591] workqueue events: flags=0x0
+[67501.195597] pwq 8: cpus=4 node=0 flags=0x0 nice=0 active=1/256
+[67501.195611] pending: cache_reap
+[67501.195641] workqueue mm_percpu_wq: flags=0x8
+[67501.195645] pwq 8: cpus=4 node=0 flags=0x0 nice=0 active=1/256
+[67501.195656] pending: vmstat_update
+[67501.195682] workqueue kblockd: flags=0x18
+[67501.195687] pwq 5: cpus=2 node=0 flags=0x0 nice=-20 active=1/256
+[67501.195698] pending: blk_timeout_work
+[67501.195753] workqueue kcopyd: flags=0x8
+[67501.195757] pwq 8: cpus=4 node=0 flags=0x0 nice=0 active=1/256
+[67501.195768] pending: do_work [dm_mod]
+[67501.195802] workqueue kcopyd: flags=0x8
+[67501.195806] pwq 8: cpus=4 node=0 flags=0x0 nice=0 active=1/256
+[67501.195817] pending: do_work [dm_mod]
+[67501.195834] workqueue kcopyd: flags=0x8
+[67501.195838] pwq 8: cpus=4 node=0 flags=0x0 nice=0 active=1/256
+[67501.195848] pending: do_work [dm_mod]
+[67501.195881] workqueue kcopyd: flags=0x8
+[67501.195885] pwq 8: cpus=4 node=0 flags=0x0 nice=0 active=1/256
+[67501.195896] pending: do_work [dm_mod]
+[67501.195920] workqueue kcopyd: flags=0x8
+[67501.195924] pwq 8: cpus=4 node=0 flags=0x0 nice=0 active=2/256
+[67501.195935] in-flight: 67:do_work [dm_mod]
+[67501.195945] pending: do_work [dm_mod]
+[67501.195961] pool 8: cpus=4 node=0 flags=0x0 nice=0 hung=27s workers=3 idle: 129 23765
+
+The root cause for these issues is the way dm-snapshot uses kcopyd. In
+particular, the lack of an explicit or implicit limit to the maximum
+number of in-flight COW jobs. The merging path is not affected because
+it implicitly limits the in-flight kcopyd jobs to one.
+
+Fix these issues by using a semaphore to limit the maximum number of
+in-flight kcopyd jobs. We grab the semaphore before allocating a new
+kcopyd job in start_copy() and start_full_bio() and release it after the
+job finishes in copy_callback().
+
+The initial semaphore value is configurable through a module parameter,
+to allow fine tuning the maximum number of in-flight COW jobs. Setting
+this parameter to zero initializes the semaphore to INT_MAX.
+
+A default value of 2048 maximum in-flight kcopyd jobs was chosen. This
+value was decided experimentally as a trade-off between memory
+consumption, stalling the kernel's workqueues and maintaining a high
+enough throughput.
+
+Re-running the aforementioned test:
+
+ * Workqueue stalls are eliminated
+ * kcopyd's job slab cache uses a maximum of 130MB
+ * The time taken by the test to write to the snapshot-origin target is
+ reduced from 05m20.48s to 03m26.38s
+
+[1] https://github.com/jthornber/device-mapper-test-suite
+
+Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
+Signed-off-by: Ilias Tsitsimpis <iliastsi@arrikto.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/dm-snap.c | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
+index b91b39caf7a9..0a304e7de260 100644
+--- a/drivers/md/dm-snap.c
++++ b/drivers/md/dm-snap.c
+@@ -19,6 +19,7 @@
+ #include <linux/vmalloc.h>
+ #include <linux/log2.h>
+ #include <linux/dm-kcopyd.h>
++#include <linux/semaphore.h>
+
+ #include "dm.h"
+
+@@ -98,6 +99,9 @@ struct dm_snapshot {
+ /* The on disk metadata handler */
+ struct dm_exception_store *store;
+
++ /* Maximum number of in-flight COW jobs. */
++ struct semaphore cow_count;
++
+ struct dm_kcopyd_client *kcopyd_client;
+
+ /* Wait for events based on state_bits */
+@@ -138,6 +142,19 @@ struct dm_snapshot {
+ #define RUNNING_MERGE 0
+ #define SHUTDOWN_MERGE 1
+
++/*
++ * Maximum number of chunks being copied on write.
++ *
++ * The value was decided experimentally as a trade-off between memory
++ * consumption, stalling the kernel's workqueues and maintaining a high enough
++ * throughput.
++ */
++#define DEFAULT_COW_THRESHOLD 2048
++
++static int cow_threshold = DEFAULT_COW_THRESHOLD;
++module_param_named(snapshot_cow_threshold, cow_threshold, int, 0644);
++MODULE_PARM_DESC(snapshot_cow_threshold, "Maximum number of chunks being copied on write");
++
+ DECLARE_DM_KCOPYD_THROTTLE_WITH_MODULE_PARM(snapshot_copy_throttle,
+ "A percentage of time allocated for copy on write");
+
+@@ -1173,6 +1190,8 @@ static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
+ goto bad_hash_tables;
+ }
+
++ sema_init(&s->cow_count, (cow_threshold > 0) ? cow_threshold : INT_MAX);
++
+ s->kcopyd_client = dm_kcopyd_client_create(&dm_kcopyd_throttle);
+ if (IS_ERR(s->kcopyd_client)) {
+ r = PTR_ERR(s->kcopyd_client);
+@@ -1545,6 +1564,7 @@ static void copy_callback(int read_err, unsigned long write_err, void *context)
+ }
+ list_add(&pe->out_of_order_entry, lh);
+ }
++ up(&s->cow_count);
+ }
+
+ /*
+@@ -1568,6 +1588,7 @@ static void start_copy(struct dm_snap_pending_exception *pe)
+ dest.count = src.count;
+
+ /* Hand over to kcopyd */
++ down(&s->cow_count);
+ dm_kcopyd_copy(s->kcopyd_client, &src, 1, &dest, 0, copy_callback, pe);
+ }
+
+@@ -1588,6 +1609,7 @@ static void start_full_bio(struct dm_snap_pending_exception *pe,
+ pe->full_bio_end_io = bio->bi_end_io;
+ pe->full_bio_private = bio->bi_private;
+
++ down(&s->cow_count);
+ callback_data = dm_kcopyd_prepare_callback(s->kcopyd_client,
+ copy_callback, pe);
+
+--
+2.19.1
+
--- /dev/null
+From f4d0380e61d23cc96d42410a6676bb37105c7f1c Mon Sep 17 00:00:00 2001
+From: Daniel Santos <daniel.santos@pobox.com>
+Date: Fri, 19 Oct 2018 03:30:20 -0500
+Subject: jffs2: Fix use of uninitialized delayed_work, lockdep breakage
+
+[ Upstream commit a788c5272769ddbcdbab297cf386413eeac04463 ]
+
+jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
+is defined then a write buffer is available and has been initialized.
+However, this does is not the case when the mtd device has no
+out-of-band buffer:
+
+int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
+{
+ if (!c->mtd->oobsize)
+ return 0;
+...
+
+The resulting call to cancel_delayed_work_sync passing a uninitialized
+(but zeroed) delayed_work struct forces lockdep to become disabled.
+
+[ 90.050639] overlayfs: upper fs does not support tmpfile.
+[ 90.652264] INFO: trying to register non-static key.
+[ 90.662171] the code is fine but needs lockdep annotation.
+[ 90.673090] turning off the locking correctness validator.
+[ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
+[ 90.696672] Stack : 00000000 00000000 80d8f6a2 00000038 805f0000 80444600 8fe364f4 805dfbe7
+[ 90.713349] 80563a30 000006e2 8068370c 00000001 00000000 00000001 8e2fdc48 ffffffff
+[ 90.730020] 00000000 00000000 80d90000 00000000 00000106 00000000 6465746e 312e3420
+[ 90.746690] 6b636f6c 03bf0000 f8000000 20676e69 00000000 80000000 00000000 8e2c2a90
+[ 90.763362] 80d90000 00000001 00000000 8e2c2a90 00000003 80260dc0 08052098 80680000
+[ 90.780033] ...
+[ 90.784902] Call Trace:
+[ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148
+[ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c
+[ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
+[ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
+[ 90.828345] [<8003f27c>] flush_work+0x200/0x24c
+[ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
+[ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
+[ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
+[ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
+[ 90.875067] [<80014424>] syscall_common+0x34/0x58
+
+Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
+Reviewed-by: Hou Tao <houtao1@huawei.com>
+Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/jffs2/super.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
+index f3194e5147fd..0bbc31d10857 100644
+--- a/fs/jffs2/super.c
++++ b/fs/jffs2/super.c
+@@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int wait)
+ struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
+
+ #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
+- cancel_delayed_work_sync(&c->wbuf_dwork);
++ if (jffs2_is_writebuffered(c))
++ cancel_delayed_work_sync(&c->wbuf_dwork);
+ #endif
+
+ mutex_lock(&c->alloc_sem);
+--
+2.19.1
+
--- /dev/null
+From 74b09b671ea76ce1d9ecef2cc5b71756f29be8e9 Mon Sep 17 00:00:00 2001
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+Date: Tue, 11 Dec 2018 20:00:45 +0900
+Subject: kconfig: fix memory leak when EOF is encountered in quotation
+
+[ Upstream commit fbac5977d81cb2b2b7e37b11c459055d9585273c ]
+
+An unterminated string literal followed by new line is passed to the
+parser (with "multi-line strings not supported" warning shown), then
+handled properly there.
+
+On the other hand, an unterminated string literal at end of file is
+never passed to the parser, then results in memory leak.
+
+[Test Code]
+
+ ----------(Kconfig begin)----------
+ source "Kconfig.inc"
+
+ config A
+ bool "a"
+ -----------(Kconfig end)-----------
+
+ --------(Kconfig.inc begin)--------
+ config B
+ bool "b\No new line at end of file
+ ---------(Kconfig.inc end)---------
+
+[Summary from Valgrind]
+
+ Before the fix:
+
+ LEAK SUMMARY:
+ definitely lost: 16 bytes in 1 blocks
+ ...
+
+ After the fix:
+
+ LEAK SUMMARY:
+ definitely lost: 0 bytes in 0 blocks
+ ...
+
+Eliminate the memory leak path by handling this case. Of course, such
+a Kconfig file is wrong already, so I will add an error message later.
+
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/kconfig/zconf.l | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
+index 6c62d93b4ffb..485b19a461f8 100644
+--- a/scripts/kconfig/zconf.l
++++ b/scripts/kconfig/zconf.l
+@@ -180,6 +180,8 @@ n [A-Za-z0-9_]
+ }
+ <<EOF>> {
+ BEGIN(INITIAL);
++ yylval.string = text;
++ return T_WORD_QUOTE;
+ }
+ }
+
+--
+2.19.1
+
--- /dev/null
+From 8ea42c25ed3ab5519e7ab03b04b57968841436cb Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Thu, 18 Oct 2018 16:03:06 -0400
+Subject: media: firewire: Fix app_info parameter type in avc_ca{,_app}_info
+
+[ Upstream commit b2e9a4eda11fd2cb1e6714e9ad3f455c402568ff ]
+
+Clang warns:
+
+drivers/media/firewire/firedtv-avc.c:999:45: warning: implicit
+conversion from 'int' to 'char' changes value from 159 to -97
+[-Wconstant-conversion]
+ app_info[0] = (EN50221_TAG_APP_INFO >> 16) & 0xff;
+ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
+drivers/media/firewire/firedtv-avc.c:1000:45: warning: implicit
+conversion from 'int' to 'char' changes value from 128 to -128
+[-Wconstant-conversion]
+ app_info[1] = (EN50221_TAG_APP_INFO >> 8) & 0xff;
+ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
+drivers/media/firewire/firedtv-avc.c:1040:44: warning: implicit
+conversion from 'int' to 'char' changes value from 159 to -97
+[-Wconstant-conversion]
+ app_info[0] = (EN50221_TAG_CA_INFO >> 16) & 0xff;
+ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
+drivers/media/firewire/firedtv-avc.c:1041:44: warning: implicit
+conversion from 'int' to 'char' changes value from 128 to -128
+[-Wconstant-conversion]
+ app_info[1] = (EN50221_TAG_CA_INFO >> 8) & 0xff;
+ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
+4 warnings generated.
+
+Change app_info's type to unsigned char to match the type of the
+member msg in struct ca_msg, which is the only thing passed into the
+app_info parameter in this function.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/105
+
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/firewire/firedtv-avc.c | 6 ++++--
+ drivers/media/firewire/firedtv.h | 6 ++++--
+ 2 files changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/media/firewire/firedtv-avc.c b/drivers/media/firewire/firedtv-avc.c
+index 251a556112a9..280b5ffea592 100644
+--- a/drivers/media/firewire/firedtv-avc.c
++++ b/drivers/media/firewire/firedtv-avc.c
+@@ -968,7 +968,8 @@ static int get_ca_object_length(struct avc_response_frame *r)
+ return r->operand[7];
+ }
+
+-int avc_ca_app_info(struct firedtv *fdtv, char *app_info, unsigned int *len)
++int avc_ca_app_info(struct firedtv *fdtv, unsigned char *app_info,
++ unsigned int *len)
+ {
+ struct avc_command_frame *c = (void *)fdtv->avc_data;
+ struct avc_response_frame *r = (void *)fdtv->avc_data;
+@@ -1009,7 +1010,8 @@ out:
+ return ret;
+ }
+
+-int avc_ca_info(struct firedtv *fdtv, char *app_info, unsigned int *len)
++int avc_ca_info(struct firedtv *fdtv, unsigned char *app_info,
++ unsigned int *len)
+ {
+ struct avc_command_frame *c = (void *)fdtv->avc_data;
+ struct avc_response_frame *r = (void *)fdtv->avc_data;
+diff --git a/drivers/media/firewire/firedtv.h b/drivers/media/firewire/firedtv.h
+index c2ba085e0d20..54853159482e 100644
+--- a/drivers/media/firewire/firedtv.h
++++ b/drivers/media/firewire/firedtv.h
+@@ -124,8 +124,10 @@ int avc_lnb_control(struct firedtv *fdtv, char voltage, char burst,
+ struct dvb_diseqc_master_cmd *diseqcmd);
+ void avc_remote_ctrl_work(struct work_struct *work);
+ int avc_register_remote_control(struct firedtv *fdtv);
+-int avc_ca_app_info(struct firedtv *fdtv, char *app_info, unsigned int *len);
+-int avc_ca_info(struct firedtv *fdtv, char *app_info, unsigned int *len);
++int avc_ca_app_info(struct firedtv *fdtv, unsigned char *app_info,
++ unsigned int *len);
++int avc_ca_info(struct firedtv *fdtv, unsigned char *app_info,
++ unsigned int *len);
+ int avc_ca_reset(struct firedtv *fdtv);
+ int avc_ca_pmt(struct firedtv *fdtv, char *app_info, int length);
+ int avc_ca_get_time_date(struct firedtv *fdtv, int *interval);
+--
+2.19.1
+
--- /dev/null
+From a667b7548a8f960b8edaabcc40c4013686cdd1ac Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@linux-mips.org>
+Date: Tue, 13 Nov 2018 22:42:44 +0000
+Subject: MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
+
+[ Upstream commit e4849aff1e169b86c561738daf8ff020e9de1011 ]
+
+The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
+DRAM controller that supports memory amounts of up to 16GiB, and due to
+how the address decoder has been wired in the SOC any memory beyond 1GiB
+is actually mapped starting from 4GiB physical up, that is beyond the
+32-bit addressable limit[1]. Consequently if the maximum amount of
+memory has been installed, then it will span up to 19GiB.
+
+Many of the evaluation boards we support that are based on one of these
+SOCs have their memory soldered and the amount present fits in the
+32-bit address range. The BCM91250A SWARM board however has actual DIMM
+slots and accepts, depending on the peripherals revision of the SOC, up
+to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
+I believe this is also the case with the BCM91250C2 LittleSur board.
+This means that up to either 3GiB or 7GiB of memory requires 64-bit
+addressing to access.
+
+I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
+accepts at least as much memory, although I have no documentation or
+actual hardware available to verify that.
+
+Both systems have PCI slots installed for use by any PCI option boards,
+including ones that only support 32-bit addressing (additionally the
+32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
+addressing to 32-bits), and there is no IOMMU available. Therefore for
+PCI DMA to work in the presence of memory beyond enable swiotlb for the
+affected systems.
+
+All the other SOC onchip DMA devices use 40-bit addressing and therefore
+can address the whole memory, so only enable swiotlb if PCI support and
+support for DMA beyond 4GiB have been both enabled in the configuration
+of the kernel.
+
+This shows up as follows:
+
+Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
+Board type: SiByte BCM91250A (SWARM)
+Determined physical RAM map:
+ memory: 000000000fe7fe00 @ 0000000000000000 (usable)
+ memory: 000000001ffffe00 @ 0000000080000000 (usable)
+ memory: 000000000ffffe00 @ 00000000c0000000 (usable)
+ memory: 0000000087fffe00 @ 0000000100000000 (usable)
+software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)
+
+in the bootstrap log and removes failures like these:
+
+defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
+fddi0: Receive buffer allocation failed
+fddi0: Adapter open failed!
+IP-Config: Failed to open fddi0
+defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
+fddi1: Receive buffer allocation failed
+fddi1: Adapter open failed!
+IP-Config: Failed to open fddi1
+
+when memory beyond 4GiB is handed out to devices that can only do 32-bit
+addressing.
+
+This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need
+DMA32.").
+
+References:
+
+[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
+ Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
+ "Memory Map", pp. 34-38
+
+[2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
+ Corporation, 18 May 2004, Section 3: "Physical Description",
+ "Supported DRAM", p. 23
+
+Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
+[paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Patchwork: https://patchwork.linux-mips.org/patch/21108/
+References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.")
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: linux-mips@linux-mips.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/Kconfig | 3 +++
+ arch/mips/sibyte/common/Makefile | 1 +
+ arch/mips/sibyte/common/dma.c | 14 ++++++++++++++
+ 3 files changed, 18 insertions(+)
+ create mode 100644 arch/mips/sibyte/common/dma.c
+
+diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
+index 9536ef912f59..077ae203e8f9 100644
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -627,6 +627,7 @@ config SIBYTE_SWARM
+ select SYS_SUPPORTS_HIGHMEM
+ select SYS_SUPPORTS_LITTLE_ENDIAN
+ select ZONE_DMA32 if 64BIT
++ select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
+
+ config SIBYTE_LITTLESUR
+ bool "Sibyte BCM91250C2-LittleSur"
+@@ -649,6 +650,7 @@ config SIBYTE_SENTOSA
+ select SYS_HAS_CPU_SB1
+ select SYS_SUPPORTS_BIG_ENDIAN
+ select SYS_SUPPORTS_LITTLE_ENDIAN
++ select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
+
+ config SIBYTE_BIGSUR
+ bool "Sibyte BCM91480B-BigSur"
+@@ -662,6 +664,7 @@ config SIBYTE_BIGSUR
+ select SYS_SUPPORTS_HIGHMEM
+ select SYS_SUPPORTS_LITTLE_ENDIAN
+ select ZONE_DMA32 if 64BIT
++ select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
+
+ config SNI_RM
+ bool "SNI RM200/300/400"
+diff --git a/arch/mips/sibyte/common/Makefile b/arch/mips/sibyte/common/Makefile
+index b3d6bf23a662..3ef3fb658136 100644
+--- a/arch/mips/sibyte/common/Makefile
++++ b/arch/mips/sibyte/common/Makefile
+@@ -1,4 +1,5 @@
+ obj-y := cfe.o
++obj-$(CONFIG_SWIOTLB) += dma.o
+ obj-$(CONFIG_SIBYTE_BUS_WATCHER) += bus_watcher.o
+ obj-$(CONFIG_SIBYTE_CFE_CONSOLE) += cfe_console.o
+ obj-$(CONFIG_SIBYTE_TBPROF) += sb_tbprof.o
+diff --git a/arch/mips/sibyte/common/dma.c b/arch/mips/sibyte/common/dma.c
+new file mode 100644
+index 000000000000..eb47a94f3583
+--- /dev/null
++++ b/arch/mips/sibyte/common/dma.c
+@@ -0,0 +1,14 @@
++// SPDX-License-Identifier: GPL-2.0+
++/*
++ * DMA support for Broadcom SiByte platforms.
++ *
++ * Copyright (c) 2018 Maciej W. Rozycki
++ */
++
++#include <linux/swiotlb.h>
++#include <asm/bootinfo.h>
++
++void __init plat_swiotlb_setup(void)
++{
++ swiotlb_init(1);
++}
+--
+2.19.1
+
--- /dev/null
+From cd817dd3465b503a0cff79801753ecb2a436fb18 Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Fri, 28 Dec 2018 00:38:17 -0800
+Subject: mm, proc: be more verbose about unstable VMA flags in
+ /proc/<pid>/smaps
+
+[ Upstream commit 7550c6079846a24f30d15ac75a941c8515dbedfb ]
+
+Patch series "THP eligibility reporting via proc".
+
+This series of three patches aims at making THP eligibility reporting much
+more robust and long term sustainable. The trigger for the change is a
+regression report [2] and the long follow up discussion. In short the
+specific application didn't have good API to query whether a particular
+mapping can be backed by THP so it has used VMA flags to workaround that.
+These flags represent a deep internal state of VMAs and as such they
+should be used by userspace with a great deal of caution.
+
+A similar has happened for [3] when users complained that VM_MIXEDMAP is
+no longer set on DAX mappings. Again a lack of a proper API led to an
+abuse.
+
+The first patch in the series tries to emphasise that that the semantic of
+flags might change and any application consuming those should be really
+careful.
+
+The remaining two patches provide a more suitable interface to address [2]
+and provide a consistent API to query the THP status both for each VMA and
+process wide as well. [1]
+
+http://lkml.kernel.org/r/20181120103515.25280-1-mhocko@kernel.org [2]
+http://lkml.kernel.org/r/http://lkml.kernel.org/r/alpine.DEB.2.21.1809241054050.224429@chino.kir.corp.google.com
+[3] http://lkml.kernel.org/r/20181002100531.GC4135@quack2.suse.cz
+
+This patch (of 3):
+
+Even though vma flags exported via /proc/<pid>/smaps are explicitly
+documented to be not guaranteed for future compatibility the warning
+doesn't go far enough because it doesn't mention semantic changes to those
+flags. And they are important as well because these flags are a deep
+implementation internal to the MM code and the semantic might change at
+any time.
+
+Let's consider two recent examples:
+http://lkml.kernel.org/r/20181002100531.GC4135@quack2.suse.cz
+: commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
+: removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
+: mean time certain customer of ours started poking into /proc/<pid>/smaps
+: and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA
+: flags, the application just fails to start complaining that DAX support is
+: missing in the kernel.
+
+http://lkml.kernel.org/r/alpine.DEB.2.21.1809241054050.224429@chino.kir.corp.google.com
+: Commit 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active")
+: introduced a regression in that userspace cannot always determine the set
+: of vmas where thp is ineligible.
+: Userspace relies on the "nh" flag being emitted as part of /proc/pid/smaps
+: to determine if a vma is eligible to be backed by hugepages.
+: Previous to this commit, prctl(PR_SET_THP_DISABLE, 1) would cause thp to
+: be disabled and emit "nh" as a flag for the corresponding vmas as part of
+: /proc/pid/smaps. After the commit, thp is disabled by means of an mm
+: flag and "nh" is not emitted.
+: This causes smaps parsing libraries to assume a vma is eligible for thp
+: and ends up puzzling the user on why its memory is not backed by thp.
+
+In both cases userspace was relying on a semantic of a specific VMA flag.
+The primary reason why that happened is a lack of a proper interface.
+While this has been worked on and it will be fixed properly, it seems that
+our wording could see some refinement and be more vocal about semantic
+aspect of these flags as well.
+
+Link: http://lkml.kernel.org/r/20181211143641.3503-2-mhocko@kernel.org
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Jan Kara <jack@suse.cz>
+Acked-by: Dan Williams <dan.j.williams@intel.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Acked-by: Mike Rapoport <rppt@linux.ibm.com>
+Acked-by: Vlastimil Babka <vbabka@suse.cz>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Paul Oppenheimer <bepvte@gmail.com>
+Cc: William Kucharski <william.kucharski@oracle.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ Documentation/filesystems/proc.txt | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
+index 04b23a83ce68..3172a2465ff2 100644
+--- a/Documentation/filesystems/proc.txt
++++ b/Documentation/filesystems/proc.txt
+@@ -439,7 +439,9 @@ manner. The codes are the following:
+
+ Note that there is no guarantee that every flag and associated mnemonic will
+ be present in all further kernel releases. Things get changed, the flags may
+-be vanished or the reverse -- new added.
++be vanished or the reverse -- new added. Interpretation of their meaning
++might change in future as well. So each consumer of these flags has to
++follow each specific kernel version for the exact semantic.
+
+ This file is only present if the CONFIG_MMU kernel configuration option is
+ enabled.
+--
+2.19.1
+
--- /dev/null
+From 448b8ad7eaec7858f84db86fd4a286d89437533a Mon Sep 17 00:00:00 2001
+From: Jonas Danielsson <jonas@orbital-systems.com>
+Date: Fri, 19 Oct 2018 16:40:05 +0200
+Subject: mmc: atmel-mci: do not assume idle after atmci_request_end
+
+[ Upstream commit ae460c115b7aa50c9a36cf78fced07b27962c9d0 ]
+
+On our AT91SAM9260 board we use the same sdio bus for wifi and for the
+sd card slot. This caused the atmel-mci to give the following splat on
+the serial console:
+
+ ------------[ cut here ]------------
+ WARNING: CPU: 0 PID: 538 at drivers/mmc/host/atmel-mci.c:859 atmci_send_command+0x24/0x44
+ Modules linked in:
+ CPU: 0 PID: 538 Comm: mmcqd/0 Not tainted 4.14.76 #14
+ Hardware name: Atmel AT91SAM9
+ [<c000fccc>] (unwind_backtrace) from [<c000d3dc>] (show_stack+0x10/0x14)
+ [<c000d3dc>] (show_stack) from [<c0017644>] (__warn+0xd8/0xf4)
+ [<c0017644>] (__warn) from [<c0017704>] (warn_slowpath_null+0x1c/0x24)
+ [<c0017704>] (warn_slowpath_null) from [<c033bb9c>] (atmci_send_command+0x24/0x44)
+ [<c033bb9c>] (atmci_send_command) from [<c033e984>] (atmci_start_request+0x1f4/0x2dc)
+ [<c033e984>] (atmci_start_request) from [<c033f3b4>] (atmci_request+0xf0/0x164)
+ [<c033f3b4>] (atmci_request) from [<c0327108>] (mmc_start_request+0x280/0x2d0)
+ [<c0327108>] (mmc_start_request) from [<c032800c>] (mmc_start_areq+0x230/0x330)
+ [<c032800c>] (mmc_start_areq) from [<c03366f8>] (mmc_blk_issue_rw_rq+0xc4/0x310)
+ [<c03366f8>] (mmc_blk_issue_rw_rq) from [<c03372c4>] (mmc_blk_issue_rq+0x118/0x5ac)
+ [<c03372c4>] (mmc_blk_issue_rq) from [<c033781c>] (mmc_queue_thread+0xc4/0x118)
+ [<c033781c>] (mmc_queue_thread) from [<c002daf8>] (kthread+0x100/0x118)
+ [<c002daf8>] (kthread) from [<c000a580>] (ret_from_fork+0x14/0x34)
+ ---[ end trace 594371ddfa284bd6 ]---
+
+This is:
+ WARN_ON(host->cmd);
+
+This was fixed on our board by letting atmci_request_end determine what
+state we are in. Instead of unconditionally setting it to STATE_IDLE on
+STATE_END_REQUEST.
+
+Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/atmel-mci.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
+index 6423083c5238..bacc0368db6b 100644
+--- a/drivers/mmc/host/atmel-mci.c
++++ b/drivers/mmc/host/atmel-mci.c
+@@ -1838,13 +1838,14 @@ static void atmci_tasklet_func(unsigned long priv)
+ }
+
+ atmci_request_end(host, host->mrq);
+- state = STATE_IDLE;
++ goto unlock; /* atmci_request_end() sets host->state */
+ break;
+ }
+ } while (state != prev_state);
+
+ host->state = state;
+
++unlock:
+ spin_unlock(&host->lock);
+ }
+
+--
+2.19.1
+
--- /dev/null
+From c6a5e6907e1d133f83ce8483e958f0f4fe43453d Mon Sep 17 00:00:00 2001
+From: yupeng <yupeng0921@gmail.com>
+Date: Wed, 5 Dec 2018 18:56:28 -0800
+Subject: net: call sk_dst_reset when set SO_DONTROUTE
+
+[ Upstream commit 0fbe82e628c817e292ff588cd5847fc935e025f2 ]
+
+after set SO_DONTROUTE to 1, the IP layer should not route packets if
+the dest IP address is not in link scope. But if the socket has cached
+the dst_entry, such packets would be routed until the sk_dst_cache
+expires. So we should clean the sk_dst_cache when a user set
+SO_DONTROUTE option. Below are server/client python scripts which
+could reprodue this issue:
+
+server side code:
+
+==========================================================================
+import socket
+import struct
+import time
+
+s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+s.bind(('0.0.0.0', 9000))
+s.listen(1)
+sock, addr = s.accept()
+sock.setsockopt(socket.SOL_SOCKET, socket.SO_DONTROUTE, struct.pack('i', 1))
+while True:
+ sock.send(b'foo')
+ time.sleep(1)
+==========================================================================
+
+client side code:
+==========================================================================
+import socket
+import time
+
+s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+s.connect(('server_address', 9000))
+while True:
+ data = s.recv(1024)
+ print(data)
+==========================================================================
+
+Signed-off-by: yupeng <yupeng0921@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/sock.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/core/sock.c b/net/core/sock.c
+index 91ee0eb70fcf..039f101e7807 100644
+--- a/net/core/sock.c
++++ b/net/core/sock.c
+@@ -720,6 +720,7 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
+ break;
+ case SO_DONTROUTE:
+ sock_valbool_flag(sk, SOCK_LOCALROUTE, valbool);
++ sk_dst_reset(sk);
+ break;
+ case SO_BROADCAST:
+ sock_valbool_flag(sk, SOCK_BROADCAST, valbool);
+--
+2.19.1
+
--- /dev/null
+From fabcc4ccb617fa1d2efcb1792badc7ec7d2126ad Mon Sep 17 00:00:00 2001
+From: Junxiao Bi <junxiao.bi@oracle.com>
+Date: Fri, 28 Dec 2018 00:32:50 -0800
+Subject: ocfs2: fix panic due to unrecovered local alloc
+
+[ Upstream commit 532e1e54c8140188e192348c790317921cb2dc1c ]
+
+mount.ocfs2 ignore the inconsistent error that journal is clean but
+local alloc is unrecovered. After mount, local alloc not empty, then
+reserver cluster didn't alloc a new local alloc window, reserveration
+map is empty(ocfs2_reservation_map.m_bitmap_len = 0), that triggered the
+following panic.
+
+This issue was reported at
+
+ https://oss.oracle.com/pipermail/ocfs2-devel/2015-May/010854.html
+
+and was advised to fixed during mount. But this is a very unusual
+inconsistent state, usually journal dirty flag should be cleared at the
+last stage of umount until every other things go right. We may need do
+further debug to check that. Any way to avoid possible futher
+corruption, mount should be abort and fsck should be run.
+
+ (mount.ocfs2,1765,1):ocfs2_load_local_alloc:353 ERROR: Local alloc hasn't been recovered!
+ found = 6518, set = 6518, taken = 8192, off = 15912372
+ ocfs2: Mounting device (202,64) on (node 0, slot 3) with ordered data mode.
+ o2dlm: Joining domain 89CEAC63CC4F4D03AC185B44E0EE0F3F ( 0 1 2 3 4 5 6 8 ) 8 nodes
+ ocfs2: Mounting device (202,80) on (node 0, slot 3) with ordered data mode.
+ o2hb: Region 89CEAC63CC4F4D03AC185B44E0EE0F3F (xvdf) is now a quorum device
+ o2net: Accepted connection from node yvwsoa17p (num 7) at 172.22.77.88:7777
+ o2dlm: Node 7 joins domain 64FE421C8C984E6D96ED12C55FEE2435 ( 0 1 2 3 4 5 6 7 8 ) 9 nodes
+ o2dlm: Node 7 joins domain 89CEAC63CC4F4D03AC185B44E0EE0F3F ( 0 1 2 3 4 5 6 7 8 ) 9 nodes
+ ------------[ cut here ]------------
+ kernel BUG at fs/ocfs2/reservations.c:507!
+ invalid opcode: 0000 [#1] SMP
+ Modules linked in: ocfs2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 ovmapi ppdev parport_pc parport xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea acpi_cpufreq pcspkr i2c_piix4 i2c_core sg ext4 jbd2 mbcache2 sr_mod cdrom xen_blkfront pata_acpi ata_generic ata_piix floppy dm_mirror dm_region_hash dm_log dm_mod
+ CPU: 0 PID: 4349 Comm: startWebLogic.s Not tainted 4.1.12-124.19.2.el6uek.x86_64 #2
+ Hardware name: Xen HVM domU, BIOS 4.4.4OVM 09/06/2018
+ task: ffff8803fb04e200 ti: ffff8800ea4d8000 task.ti: ffff8800ea4d8000
+ RIP: 0010:[<ffffffffa05e96a8>] [<ffffffffa05e96a8>] __ocfs2_resv_find_window+0x498/0x760 [ocfs2]
+ Call Trace:
+ ocfs2_resmap_resv_bits+0x10d/0x400 [ocfs2]
+ ocfs2_claim_local_alloc_bits+0xd0/0x640 [ocfs2]
+ __ocfs2_claim_clusters+0x178/0x360 [ocfs2]
+ ocfs2_claim_clusters+0x1f/0x30 [ocfs2]
+ ocfs2_convert_inline_data_to_extents+0x634/0xa60 [ocfs2]
+ ocfs2_write_begin_nolock+0x1c6/0x1da0 [ocfs2]
+ ocfs2_write_begin+0x13e/0x230 [ocfs2]
+ generic_perform_write+0xbf/0x1c0
+ __generic_file_write_iter+0x19c/0x1d0
+ ocfs2_file_write_iter+0x589/0x1360 [ocfs2]
+ __vfs_write+0xb8/0x110
+ vfs_write+0xa9/0x1b0
+ SyS_write+0x46/0xb0
+ system_call_fastpath+0x18/0xd7
+ Code: ff ff 8b 75 b8 39 75 b0 8b 45 c8 89 45 98 0f 84 e5 fe ff ff 45 8b 74 24 18 41 8b 54 24 1c e9 56 fc ff ff 85 c0 0f 85 48 ff ff ff <0f> 0b 48 8b 05 cf c3 de ff 48 ba 00 00 00 00 00 00 00 10 48 85
+ RIP __ocfs2_resv_find_window+0x498/0x760 [ocfs2]
+ RSP <ffff8800ea4db668>
+ ---[ end trace 566f07529f2edf3c ]---
+ Kernel panic - not syncing: Fatal exception
+ Kernel Offset: disabled
+
+Link: http://lkml.kernel.org/r/20181121020023.3034-2-junxiao.bi@oracle.com
+Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
+Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com>
+Acked-by: Joseph Qi <jiangqi903@gmail.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: Mark Fasheh <mfasheh@versity.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Changwei Ge <ge.changwei@h3c.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/ocfs2/localalloc.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/fs/ocfs2/localalloc.c b/fs/ocfs2/localalloc.c
+index 044013455621..12675bb5304a 100644
+--- a/fs/ocfs2/localalloc.c
++++ b/fs/ocfs2/localalloc.c
+@@ -345,13 +345,18 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb)
+ if (num_used
+ || alloc->id1.bitmap1.i_used
+ || alloc->id1.bitmap1.i_total
+- || la->la_bm_off)
+- mlog(ML_ERROR, "Local alloc hasn't been recovered!\n"
++ || la->la_bm_off) {
++ mlog(ML_ERROR, "inconsistent detected, clean journal with"
++ " unrecovered local alloc, please run fsck.ocfs2!\n"
+ "found = %u, set = %u, taken = %u, off = %u\n",
+ num_used, le32_to_cpu(alloc->id1.bitmap1.i_used),
+ le32_to_cpu(alloc->id1.bitmap1.i_total),
+ OCFS2_LOCAL_ALLOC(alloc)->la_bm_off);
+
++ status = -EINVAL;
++ goto bail;
++ }
++
+ osb->local_alloc_bh = alloc_bh;
+ osb->local_alloc_state = OCFS2_LA_ENABLED;
+
+--
+2.19.1
+
--- /dev/null
+From 77a58a00aa765d316f243d0ff7ddd7e91c55a111 Mon Sep 17 00:00:00 2001
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+Date: Thu, 6 Dec 2018 13:52:13 -0300
+Subject: perf parse-events: Fix unchecked usage of strncpy()
+
+[ Upstream commit bd8d57fb7e25e9fcf67a9eef5fa13aabe2016e07 ]
+
+The strncpy() function may leave the destination string buffer
+unterminated, better use strlcpy() that we have a __weak fallback
+implementation for systems without it.
+
+This fixes this warning on an Alpine Linux Edge system with gcc 8.2:
+
+ util/parse-events.c: In function 'print_symbol_events':
+ util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation]
+ strncpy(name, syms->symbol, MAX_NAME_LEN);
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ In function 'print_symbol_events.constprop',
+ inlined from 'print_events' at util/parse-events.c:2508:2:
+ util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation]
+ strncpy(name, syms->symbol, MAX_NAME_LEN);
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ In function 'print_symbol_events.constprop',
+ inlined from 'print_events' at util/parse-events.c:2511:2:
+ util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation]
+ strncpy(name, syms->symbol, MAX_NAME_LEN);
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ cc1: all warnings being treated as errors
+
+Cc: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Fixes: 947b4ad1d198 ("perf list: Fix max event string size")
+Link: https://lkml.kernel.org/n/tip-b663e33bm6x8hrkie4uxh7u2@git.kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/parse-events.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
+index c659a3ca1283..78b452421375 100644
+--- a/tools/perf/util/parse-events.c
++++ b/tools/perf/util/parse-events.c
+@@ -1319,7 +1319,7 @@ static void print_symbol_events(const char *event_glob, unsigned type,
+ if (strlen(syms->alias))
+ snprintf(name, MAX_NAME_LEN, "%s OR %s", syms->symbol, syms->alias);
+ else
+- strncpy(name, syms->symbol, MAX_NAME_LEN);
++ strlcpy(name, syms->symbol, MAX_NAME_LEN);
+
+ printf(" %-50s [%s]\n", name, event_type_descriptors[type]);
+
+--
+2.19.1
+
--- /dev/null
+From 0dcc456be195f11e054f69b6d2c4c4bcb0865156 Mon Sep 17 00:00:00 2001
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+Date: Thu, 6 Dec 2018 11:29:48 -0300
+Subject: perf svghelper: Fix unchecked usage of strncpy()
+
+[ Upstream commit 2f5302533f306d5ee87bd375aef9ca35b91762cb ]
+
+The strncpy() function may leave the destination string buffer
+unterminated, better use strlcpy() that we have a __weak fallback
+implementation for systems without it.
+
+In this specific case this would only happen if fgets() was buggy, as
+its man page states that it should read one less byte than the size of
+the destination buffer, so that it can put the nul byte at the end of
+it, so it would never copy 255 non-nul chars, as fgets reads into the
+orig buffer at most 254 non-nul chars and terminates it. But lets just
+switch to strlcpy to keep the original intent and silence the gcc 8.2
+warning.
+
+This fixes this warning on an Alpine Linux Edge system with gcc 8.2:
+
+ In function 'cpu_model',
+ inlined from 'svg_cpu_box' at util/svghelper.c:378:2:
+ util/svghelper.c:337:5: error: 'strncpy' output may be truncated copying 255 bytes from a string of length 255 [-Werror=stringop-truncation]
+ strncpy(cpu_m, &buf[13], 255);
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Cc: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Arjan van de Ven <arjan@linux.intel.com>
+Fixes: f48d55ce7871 ("perf: Add a SVG helper library file")
+Link: https://lkml.kernel.org/n/tip-xzkoo0gyr56gej39ltivuh9g@git.kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/svghelper.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/perf/util/svghelper.c b/tools/perf/util/svghelper.c
+index 283d3e73e2f2..48a841462536 100644
+--- a/tools/perf/util/svghelper.c
++++ b/tools/perf/util/svghelper.c
+@@ -333,7 +333,7 @@ static char *cpu_model(void)
+ if (file) {
+ while (fgets(buf, 255, file)) {
+ if (strstr(buf, "model name")) {
+- strncpy(cpu_m, &buf[13], 255);
++ strlcpy(cpu_m, &buf[13], 255);
+ break;
+ }
+ }
+--
+2.19.1
+
--- /dev/null
+From f42eb4e52536e370a61e69435cbcb26ea87f2950 Mon Sep 17 00:00:00 2001
+From: Breno Leitao <leitao@debian.org>
+Date: Fri, 23 Nov 2018 14:30:11 -0200
+Subject: powerpc/pseries/cpuidle: Fix preempt warning
+
+[ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]
+
+When booting a pseries kernel with PREEMPT enabled, it dumps the
+following warning:
+
+ BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
+ caller is pseries_processor_idle_init+0x5c/0x22c
+ CPU: 13 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc3-00090-g12201a0128bc-dirty #828
+ Call Trace:
+ [c000000429437ab0] [c0000000009c8878] dump_stack+0xec/0x164 (unreliable)
+ [c000000429437b00] [c0000000005f2f24] check_preemption_disabled+0x154/0x160
+ [c000000429437b90] [c000000000cab8e8] pseries_processor_idle_init+0x5c/0x22c
+ [c000000429437c10] [c000000000010ed4] do_one_initcall+0x64/0x300
+ [c000000429437ce0] [c000000000c54500] kernel_init_freeable+0x3f0/0x500
+ [c000000429437db0] [c0000000000112dc] kernel_init+0x2c/0x160
+ [c000000429437e20] [c00000000000c1d0] ret_from_kernel_thread+0x5c/0x6c
+
+This happens because the code calls get_lppaca() which calls
+get_paca() and it checks if preemption is disabled through
+check_preemption_disabled().
+
+Preemption should be disabled because the per CPU variable may make no
+sense if there is a preemption (and a CPU switch) after it reads the
+per CPU data and when it is used.
+
+In this device driver specifically, it is not a problem, because this
+code just needs to have access to one lppaca struct, and it does not
+matter if it is the current per CPU lppaca struct or not (i.e. when
+there is a preemption and a CPU migration).
+
+That said, the most appropriate fix seems to be related to avoiding
+the debug_smp_processor_id() call at get_paca(), instead of calling
+preempt_disable() before get_paca().
+
+Signed-off-by: Breno Leitao <leitao@debian.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpuidle/cpuidle-pseries.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
+index 6f7b01956885..b755d3a54e3c 100644
+--- a/drivers/cpuidle/cpuidle-pseries.c
++++ b/drivers/cpuidle/cpuidle-pseries.c
+@@ -237,7 +237,13 @@ static int pseries_idle_probe(void)
+ return -ENODEV;
+
+ if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+- if (lppaca_shared_proc(get_lppaca())) {
++ /*
++ * Use local_paca instead of get_lppaca() since
++ * preemption is not disabled, and it is not required in
++ * fact, since lppaca_ptr does not need to be the value
++ * associated to the current CPU, it can be from any CPU.
++ */
++ if (lppaca_shared_proc(local_paca->lppaca_ptr)) {
+ cpuidle_state_table = shared_states;
+ max_idle_state = ARRAY_SIZE(shared_states);
+ } else {
+--
+2.19.1
+
--- /dev/null
+From 4e4e4cb6de9190e48206f648e28bb91397970617 Mon Sep 17 00:00:00 2001
+From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
+Date: Sat, 3 Nov 2018 16:38:18 -0700
+Subject: pstore/ram: Do not treat empty buffers as valid
+
+[ Upstream commit 30696378f68a9e3dad6bfe55938b112e72af00c2 ]
+
+The ramoops backend currently calls persistent_ram_save_old() even
+if a buffer is empty. While this appears to work, it is does not seem
+like the right thing to do and could lead to future bugs so lets avoid
+that. It also prevents misleading prints in the logs which claim the
+buffer is valid.
+
+I got something like:
+
+ found existing buffer, size 0, start 0
+
+When I was expecting:
+
+ no valid data in buffer (sig = ...)
+
+This bails out early (and reports with pr_debug()), since it's an
+acceptable state.
+
+Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
+Co-developed-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/pstore/ram_core.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
+index 288ce45f613e..5ffbf60f5c88 100644
+--- a/fs/pstore/ram_core.c
++++ b/fs/pstore/ram_core.c
+@@ -484,6 +484,11 @@ static int persistent_ram_post_init(struct persistent_ram_zone *prz, u32 sig,
+ sig ^= PERSISTENT_RAM_SIG;
+
+ if (prz->buffer->sig == sig) {
++ if (buffer_size(prz) == 0) {
++ pr_debug("found existing empty buffer\n");
++ return 0;
++ }
++
+ if (buffer_size(prz) > prz->buffer_size ||
+ buffer_start(prz) > buffer_size(prz))
+ pr_info("found existing invalid buffer, size %zu, start %zu\n",
+--
+2.19.1
+
--- /dev/null
+From 3a6dc699cd9a436feb631e1500bcbd11662d5e85 Mon Sep 17 00:00:00 2001
+From: David Disseldorp <ddiss@suse.de>
+Date: Wed, 5 Dec 2018 13:18:34 +0100
+Subject: scsi: target: use consistent left-aligned ASCII INQUIRY data
+
+[ Upstream commit 0de263577de5d5e052be5f4f93334e63cc8a7f0b ]
+
+spc5r17.pdf specifies:
+
+ 4.3.1 ASCII data field requirements
+ ASCII data fields shall contain only ASCII printable characters (i.e.,
+ code values 20h to 7Eh) and may be terminated with one or more ASCII null
+ (00h) characters. ASCII data fields described as being left-aligned
+ shall have any unused bytes at the end of the field (i.e., highest
+ offset) and the unused bytes shall be filled with ASCII space characters
+ (20h).
+
+LIO currently space-pads the T10 VENDOR IDENTIFICATION and PRODUCT
+IDENTIFICATION fields in the standard INQUIRY data. However, the PRODUCT
+REVISION LEVEL field in the standard INQUIRY data as well as the T10 VENDOR
+IDENTIFICATION field in the INQUIRY Device Identification VPD Page are
+zero-terminated/zero-padded.
+
+Fix this inconsistency by using space-padding for all of the above fields.
+
+Signed-off-by: David Disseldorp <ddiss@suse.de>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Bryant G. Ly <bly@catalogicsoftware.com>
+Reviewed-by: Lee Duncan <lduncan@suse.com>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/target/target_core_spc.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
+index 614005b6b08b..3ab264d4fb1f 100644
+--- a/drivers/target/target_core_spc.c
++++ b/drivers/target/target_core_spc.c
+@@ -112,12 +112,17 @@ spc_emulate_inquiry_std(struct se_cmd *cmd, unsigned char *buf)
+
+ buf[7] = 0x2; /* CmdQue=1 */
+
+- memcpy(&buf[8], "LIO-ORG ", 8);
+- memset(&buf[16], 0x20, 16);
++ /*
++ * ASCII data fields described as being left-aligned shall have any
++ * unused bytes at the end of the field (i.e., highest offset) and the
++ * unused bytes shall be filled with ASCII space characters (20h).
++ */
++ memset(&buf[8], 0x20, 8 + 16 + 4);
++ memcpy(&buf[8], "LIO-ORG", sizeof("LIO-ORG") - 1);
+ memcpy(&buf[16], dev->t10_wwn.model,
+- min_t(size_t, strlen(dev->t10_wwn.model), 16));
++ strnlen(dev->t10_wwn.model, 16));
+ memcpy(&buf[32], dev->t10_wwn.revision,
+- min_t(size_t, strlen(dev->t10_wwn.revision), 4));
++ strnlen(dev->t10_wwn.revision, 4));
+ buf[4] = 31; /* Set additional length to 31 */
+
+ return 0;
+@@ -257,7 +262,9 @@ check_t10_vend_desc:
+ buf[off] = 0x2; /* ASCII */
+ buf[off+1] = 0x1; /* T10 Vendor ID */
+ buf[off+2] = 0x0;
+- memcpy(&buf[off+4], "LIO-ORG", 8);
++ /* left align Vendor ID and pad with spaces */
++ memset(&buf[off+4], 0x20, 8);
++ memcpy(&buf[off+4], "LIO-ORG", sizeof("LIO-ORG") - 1);
+ /* Extra Byte for NULL Terminator */
+ id_len++;
+ /* Identifier Length */
+--
+2.19.1
+
drm-fb-helper-ignore-the-value-of-fb_var_screeninfo.pixclock.patch
media-vb2-be-sure-to-unlock-mutex-on-errors.patch
r8169-add-support-for-new-realtek-ethernet.patch
+mips-sibyte-enable-swiotlb-for-swarm-littlesur-and-b.patch
+jffs2-fix-use-of-uninitialized-delayed_work-lockdep-.patch
+pstore-ram-do-not-treat-empty-buffers-as-valid.patch
+powerpc-pseries-cpuidle-fix-preempt-warning.patch
+media-firewire-fix-app_info-parameter-type-in-avc_ca.patch
+net-call-sk_dst_reset-when-set-so_dontroute.patch
+scsi-target-use-consistent-left-aligned-ascii-inquir.patch
+clk-imx6q-reset-exclusive-gates-on-init.patch
+kconfig-fix-memory-leak-when-eof-is-encountered-in-q.patch
+mmc-atmel-mci-do-not-assume-idle-after-atmci_request.patch
+perf-svghelper-fix-unchecked-usage-of-strncpy.patch
+perf-parse-events-fix-unchecked-usage-of-strncpy.patch
+dm-kcopyd-fix-bug-causing-workqueue-stalls.patch
+dm-snapshot-fix-excessive-memory-usage-and-workqueue.patch
+alsa-bebob-fix-model-id-of-unit-for-apogee-ensemble.patch
+sysfs-disable-lockdep-for-driver-bind-unbind-files.patch
+ocfs2-fix-panic-due-to-unrecovered-local-alloc.patch
+mm-proc-be-more-verbose-about-unstable-vma-flags-in-.patch
--- /dev/null
+From 69b2df0d73dc8ecc115f5508d2141a70ddd45552 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Wed, 19 Dec 2018 13:39:09 +0100
+Subject: sysfs: Disable lockdep for driver bind/unbind files
+
+[ Upstream commit 4f4b374332ec0ae9c738ff8ec9bed5cd97ff9adc ]
+
+This is the much more correct fix for my earlier attempt at:
+
+https://lkml.org/lkml/2018/12/10/118
+
+Short recap:
+
+- There's not actually a locking issue, it's just lockdep being a bit
+ too eager to complain about a possible deadlock.
+
+- Contrary to what I claimed the real problem is recursion on
+ kn->count. Greg pointed me at sysfs_break_active_protection(), used
+ by the scsi subsystem to allow a sysfs file to unbind itself. That
+ would be a real deadlock, which isn't what's happening here. Also,
+ breaking the active protection means we'd need to manually handle
+ all the lifetime fun.
+
+- With Rafael we discussed the task_work approach, which kinda works,
+ but has two downsides: It's a functional change for a lockdep
+ annotation issue, and it won't work for the bind file (which needs
+ to get the errno from the driver load function back to userspace).
+
+- Greg also asked why this never showed up: To hit this you need to
+ unregister a 2nd driver from the unload code of your first driver. I
+ guess only gpus do that. The bug has always been there, but only
+ with a recent patch series did we add more locks so that lockdep
+ built a chain from unbinding the snd-hda driver to the
+ acpi_video_unregister call.
+
+Full lockdep splat:
+
+[12301.898799] ============================================
+[12301.898805] WARNING: possible recursive locking detected
+[12301.898811] 4.20.0-rc7+ #84 Not tainted
+[12301.898815] --------------------------------------------
+[12301.898821] bash/5297 is trying to acquire lock:
+[12301.898826] 00000000f61c6093 (kn->count#39){++++}, at: kernfs_remove_by_name_ns+0x3b/0x80
+[12301.898841] but task is already holding lock:
+[12301.898847] 000000005f634021 (kn->count#39){++++}, at: kernfs_fop_write+0xdc/0x190
+[12301.898856] other info that might help us debug this:
+[12301.898862] Possible unsafe locking scenario:
+[12301.898867] CPU0
+[12301.898870] ----
+[12301.898874] lock(kn->count#39);
+[12301.898879] lock(kn->count#39);
+[12301.898883] *** DEADLOCK ***
+[12301.898891] May be due to missing lock nesting notation
+[12301.898899] 5 locks held by bash/5297:
+[12301.898903] #0: 00000000cd800e54 (sb_writers#4){.+.+}, at: vfs_write+0x17f/0x1b0
+[12301.898915] #1: 000000000465e7c2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xd3/0x190
+[12301.898925] #2: 000000005f634021 (kn->count#39){++++}, at: kernfs_fop_write+0xdc/0x190
+[12301.898936] #3: 00000000414ef7ac (&dev->mutex){....}, at: device_release_driver_internal+0x34/0x240
+[12301.898950] #4: 000000003218fbdf (register_count_mutex){+.+.}, at: acpi_video_unregister+0xe/0x40
+[12301.898960] stack backtrace:
+[12301.898968] CPU: 1 PID: 5297 Comm: bash Not tainted 4.20.0-rc7+ #84
+[12301.898974] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS 68SCF Ver. F.01 03/11/2011
+[12301.898982] Call Trace:
+[12301.898989] dump_stack+0x67/0x9b
+[12301.898997] __lock_acquire+0x6ad/0x1410
+[12301.899003] ? kernfs_remove_by_name_ns+0x3b/0x80
+[12301.899010] ? find_held_lock+0x2d/0x90
+[12301.899017] ? mutex_spin_on_owner+0xe4/0x150
+[12301.899023] ? find_held_lock+0x2d/0x90
+[12301.899030] ? lock_acquire+0x90/0x180
+[12301.899036] lock_acquire+0x90/0x180
+[12301.899042] ? kernfs_remove_by_name_ns+0x3b/0x80
+[12301.899049] __kernfs_remove+0x296/0x310
+[12301.899055] ? kernfs_remove_by_name_ns+0x3b/0x80
+[12301.899060] ? kernfs_name_hash+0xd/0x80
+[12301.899066] ? kernfs_find_ns+0x6c/0x100
+[12301.899073] kernfs_remove_by_name_ns+0x3b/0x80
+[12301.899080] bus_remove_driver+0x92/0xa0
+[12301.899085] acpi_video_unregister+0x24/0x40
+[12301.899127] i915_driver_unload+0x42/0x130 [i915]
+[12301.899160] i915_pci_remove+0x19/0x30 [i915]
+[12301.899169] pci_device_remove+0x36/0xb0
+[12301.899176] device_release_driver_internal+0x185/0x240
+[12301.899183] unbind_store+0xaf/0x180
+[12301.899189] kernfs_fop_write+0x104/0x190
+[12301.899195] __vfs_write+0x31/0x180
+[12301.899203] ? rcu_read_lock_sched_held+0x6f/0x80
+[12301.899209] ? rcu_sync_lockdep_assert+0x29/0x50
+[12301.899216] ? __sb_start_write+0x13c/0x1a0
+[12301.899221] ? vfs_write+0x17f/0x1b0
+[12301.899227] vfs_write+0xb9/0x1b0
+[12301.899233] ksys_write+0x50/0xc0
+[12301.899239] do_syscall_64+0x4b/0x180
+[12301.899247] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+[12301.899253] RIP: 0033:0x7f452ac7f7a4
+[12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
+[12301.899273] RSP: 002b:00007ffceafa6918 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+[12301.899282] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f452ac7f7a4
+[12301.899288] RDX: 000000000000000d RSI: 00005612a1abf7c0 RDI: 0000000000000001
+[12301.899295] RBP: 00005612a1abf7c0 R08: 000000000000000a R09: 00005612a1c46730
+[12301.899301] R10: 000000000000000a R11: 0000000000000246 R12: 000000000000000d
+[12301.899308] R13: 0000000000000001 R14: 00007f452af4a740 R15: 000000000000000d
+
+Looking around I've noticed that usb and i2c already handle similar
+recursion problems, where a sysfs file can unbind the same type of
+sysfs somewhere else in the hierarchy. Relevant commits are:
+
+commit 356c05d58af05d582e634b54b40050c73609617b
+Author: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon May 14 13:30:03 2012 -0400
+
+ sysfs: get rid of some lockdep false positives
+
+commit e9b526fe704812364bca07edd15eadeba163ebfb
+Author: Alexander Sverdlin <alexander.sverdlin@nsn.com>
+Date: Fri May 17 14:56:35 2013 +0200
+
+ i2c: suppress lockdep warning on delete_device
+
+Implement the same trick for driver bind/unbind.
+
+v2: Put the macro into bus.c (Greg).
+
+Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: Ramalingam C <ramalingam.c@intel.com>
+Cc: Arend van Spriel <aspriel@gmail.com>
+Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: Bartosz Golaszewski <brgl@bgdev.pl>
+Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Cc: Vivek Gautam <vivek.gautam@codeaurora.org>
+Cc: Joe Perches <joe@perches.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/base/bus.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/base/bus.c b/drivers/base/bus.c
+index 07ea8608fb0b..c05561e26d85 100644
+--- a/drivers/base/bus.c
++++ b/drivers/base/bus.c
+@@ -32,6 +32,9 @@ static struct kset *system_kset;
+
+ #define to_drv_attr(_attr) container_of(_attr, struct driver_attribute, attr)
+
++#define DRIVER_ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store) \
++ struct driver_attribute driver_attr_##_name = \
++ __ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store)
+
+ static int __must_check bus_rescan_devices_helper(struct device *dev,
+ void *data);
+@@ -197,7 +200,7 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf,
+ bus_put(bus);
+ return err;
+ }
+-static DRIVER_ATTR_WO(unbind);
++static DRIVER_ATTR_IGNORE_LOCKDEP(unbind, S_IWUSR, NULL, unbind_store);
+
+ /*
+ * Manually attach a device to a driver.
+@@ -233,7 +236,7 @@ static ssize_t bind_store(struct device_driver *drv, const char *buf,
+ bus_put(bus);
+ return err;
+ }
+-static DRIVER_ATTR_WO(bind);
++static DRIVER_ATTR_IGNORE_LOCKDEP(bind, S_IWUSR, NULL, bind_store);
+
+ static ssize_t show_drivers_autoprobe(struct bus_type *bus, char *buf)
+ {
+--
+2.19.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
