--- /dev/null
+From f014ffb025c159fd51d19af8af0022a991aaa4f8 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Fri, 12 Oct 2018 14:00:57 +0100
+Subject: afs: Fix afs_server struct leak
+
+From: David Howells <dhowells@redhat.com>
+
+commit f014ffb025c159fd51d19af8af0022a991aaa4f8 upstream.
+
+Fix a leak of afs_server structs. The routine that installs them in the
+various lookup lists and trees gets a ref on leaving the function, whether
+it added the server or a server already exists. It shouldn't increment
+the refcount if it added the server.
+
+The effect of this that "rmmod kafs" will hang waiting for the leaked
+server to become unused.
+
+Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/afs/server.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/afs/server.c
++++ b/fs/afs/server.c
+@@ -199,9 +199,11 @@ static struct afs_server *afs_install_se
+
+ write_sequnlock(&net->fs_addr_lock);
+ ret = 0;
++ goto out;
+
+ exists:
+ afs_get_server(server);
++out:
+ write_sequnlock(&net->fs_lock);
+ return server;
+ }
--- /dev/null
+From f0a7d1883d9f78ae7bf15fc258bf9a2b20f35b76 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Mon, 15 Oct 2018 12:43:02 +0100
+Subject: afs: Fix clearance of reply
+
+From: David Howells <dhowells@redhat.com>
+
+commit f0a7d1883d9f78ae7bf15fc258bf9a2b20f35b76 upstream.
+
+The recent patch to fix the afs_server struct leak didn't actually fix the
+bug, but rather fixed some of the symptoms. The problem is that an
+asynchronous call that holds a resource pointed to by call->reply[0] will
+find the pointer cleared in the call destructor, thereby preventing the
+resource from being cleaned up.
+
+In the case of the server record leak, the afs_fs_get_capabilities()
+function in devel code sets up a call with reply[0] pointing at the server
+record that should be altered when the result is obtained, but this was
+being cleared before the destructor was called, so the put in the
+destructor does nothing and the record is leaked.
+
+Commit f014ffb025c1 removed the additional ref obtained by
+afs_install_server(), but the removal of this ref is actually used by the
+garbage collector to mark a server record as being defunct after the record
+has expired through lack of use.
+
+The offending clearance of call->reply[0] upon completion in
+afs_process_async_call() has been there from the origin of the code, but
+none of the asynchronous calls actually use that pointer currently, so it
+should be safe to remove (note that synchronous calls don't involve this
+function).
+
+Fix this by the following means:
+
+ (1) Revert commit f014ffb025c1.
+
+ (2) Remove the clearance of reply[0] from afs_process_async_call().
+
+Without this, afs_manage_servers() will suffer an assertion failure if it
+sees a server record that didn't get used because the usage count is not 1.
+
+Fixes: f014ffb025c1 ("afs: Fix afs_server struct leak")
+Fixes: 08e0e7c82eea ("[AF_RXRPC]: Make the in-kernel AFS filesystem use AF_RXRPC.")
+Signed-off-by: David Howells <dhowells@redhat.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/afs/rxrpc.c | 2 --
+ fs/afs/server.c | 2 --
+ 2 files changed, 4 deletions(-)
+
+--- a/fs/afs/rxrpc.c
++++ b/fs/afs/rxrpc.c
+@@ -690,8 +690,6 @@ static void afs_process_async_call(struc
+ }
+
+ if (call->state == AFS_CALL_COMPLETE) {
+- call->reply[0] = NULL;
+-
+ /* We have two refs to release - one from the alloc and one
+ * queued with the work item - and we can't just deallocate the
+ * call because the work item may be queued again.
+--- a/fs/afs/server.c
++++ b/fs/afs/server.c
+@@ -199,11 +199,9 @@ static struct afs_server *afs_install_se
+
+ write_sequnlock(&net->fs_addr_lock);
+ ret = 0;
+- goto out;
+
+ exists:
+ afs_get_server(server);
+-out:
+ write_sequnlock(&net->fs_lock);
+ return server;
+ }
--- /dev/null
+From ca2b497253ad01c80061a1f3ee9eb91b5d54a849 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+Date: Fri, 5 Oct 2018 13:24:36 +0100
+Subject: arm64: perf: Reject stand-alone CHAIN events for PMUv3
+
+From: Will Deacon <will.deacon@arm.com>
+
+commit ca2b497253ad01c80061a1f3ee9eb91b5d54a849 upstream.
+
+It doesn't make sense for a perf event to be configured as a CHAIN event
+in isolation, so extend the arm_pmu structure with a ->filter_match()
+function to allow the backend PMU implementation to reject CHAIN events
+early.
+
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/perf_event.c | 7 +++++++
+ drivers/perf/arm_pmu.c | 8 +++++++-
+ include/linux/perf/arm_pmu.h | 1 +
+ 3 files changed, 15 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/kernel/perf_event.c
++++ b/arch/arm64/kernel/perf_event.c
+@@ -823,6 +823,12 @@ static int armv8pmu_set_event_filter(str
+ return 0;
+ }
+
++static int armv8pmu_filter_match(struct perf_event *event)
++{
++ unsigned long evtype = event->hw.config_base & ARMV8_PMU_EVTYPE_EVENT;
++ return evtype != ARMV8_PMUV3_PERFCTR_CHAIN;
++}
++
+ static void armv8pmu_reset(void *info)
+ {
+ struct arm_pmu *cpu_pmu = (struct arm_pmu *)info;
+@@ -968,6 +974,7 @@ static int armv8_pmu_init(struct arm_pmu
+ cpu_pmu->reset = armv8pmu_reset,
+ cpu_pmu->max_period = (1LLU << 32) - 1,
+ cpu_pmu->set_event_filter = armv8pmu_set_event_filter;
++ cpu_pmu->filter_match = armv8pmu_filter_match;
+
+ return 0;
+ }
+--- a/drivers/perf/arm_pmu.c
++++ b/drivers/perf/arm_pmu.c
+@@ -474,7 +474,13 @@ static int armpmu_filter_match(struct pe
+ {
+ struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
+ unsigned int cpu = smp_processor_id();
+- return cpumask_test_cpu(cpu, &armpmu->supported_cpus);
++ int ret;
++
++ ret = cpumask_test_cpu(cpu, &armpmu->supported_cpus);
++ if (ret && armpmu->filter_match)
++ return armpmu->filter_match(event);
++
++ return ret;
+ }
+
+ static ssize_t armpmu_cpumask_show(struct device *dev,
+--- a/include/linux/perf/arm_pmu.h
++++ b/include/linux/perf/arm_pmu.h
+@@ -93,6 +93,7 @@ struct arm_pmu {
+ void (*stop)(struct arm_pmu *);
+ void (*reset)(void *);
+ int (*map_event)(struct perf_event *event);
++ int (*filter_match)(struct perf_event *event);
+ int num_events;
+ u64 max_period;
+ bool secure_access; /* 32-bit ARM only */
--- /dev/null
+From 479adb89a97b0a33e5a9d702119872cc82ca21aa Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Thu, 4 Oct 2018 13:28:08 -0700
+Subject: cgroup: Fix dom_cgrp propagation when enabling threaded mode
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 479adb89a97b0a33e5a9d702119872cc82ca21aa upstream.
+
+A cgroup which is already a threaded domain may be converted into a
+threaded cgroup if the prerequisite conditions are met. When this
+happens, all threaded descendant should also have their ->dom_cgrp
+updated to the new threaded domain cgroup. Unfortunately, this
+propagation was missing leading to the following failure.
+
+ # cd /sys/fs/cgroup/unified
+ # cat cgroup.subtree_control # show that no controllers are enabled
+
+ # mkdir -p mycgrp/a/b/c
+ # echo threaded > mycgrp/a/b/cgroup.type
+
+ At this point, the hierarchy looks as follows:
+
+ mycgrp [d]
+ a [dt]
+ b [t]
+ c [inv]
+
+ Now let's make node "a" threaded (and thus "mycgrp" s made "domain threaded"):
+
+ # echo threaded > mycgrp/a/cgroup.type
+
+ By this point, we now have a hierarchy that looks as follows:
+
+ mycgrp [dt]
+ a [t]
+ b [t]
+ c [inv]
+
+ But, when we try to convert the node "c" from "domain invalid" to
+ "threaded", we get ENOTSUP on the write():
+
+ # echo threaded > mycgrp/a/b/c/cgroup.type
+ sh: echo: write error: Operation not supported
+
+This patch fixes the problem by
+
+* Moving the opencoded ->dom_cgrp save and restoration in
+ cgroup_enable_threaded() into cgroup_{save|restore}_control() so
+ that mulitple cgroups can be handled.
+
+* Updating all threaded descendants' ->dom_cgrp to point to the new
+ dom_cgrp when enabling threaded mode.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-and-tested-by: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
+Reported-by: Amin Jamali <ajamali@pivotal.io>
+Reported-by: Joao De Almeida Pereira <jpereira@pivotal.io>
+Link: https://lore.kernel.org/r/CAKgNAkhHYCMn74TCNiMJ=ccLd7DcmXSbvw3CbZ1YREeG7iJM5g@mail.gmail.com
+Fixes: 454000adaa2a ("cgroup: introduce cgroup->dom_cgrp and threaded css_set handling")
+Cc: stable@vger.kernel.org # v4.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/cgroup-defs.h | 1 +
+ kernel/cgroup/cgroup.c | 25 ++++++++++++++++---------
+ 2 files changed, 17 insertions(+), 9 deletions(-)
+
+--- a/include/linux/cgroup-defs.h
++++ b/include/linux/cgroup-defs.h
+@@ -412,6 +412,7 @@ struct cgroup {
+ * specific task are charged to the dom_cgrp.
+ */
+ struct cgroup *dom_cgrp;
++ struct cgroup *old_dom_cgrp; /* used while enabling threaded */
+
+ /* per-cpu recursive resource statistics */
+ struct cgroup_rstat_cpu __percpu *rstat_cpu;
+--- a/kernel/cgroup/cgroup.c
++++ b/kernel/cgroup/cgroup.c
+@@ -2833,11 +2833,12 @@ restart:
+ }
+
+ /**
+- * cgroup_save_control - save control masks of a subtree
++ * cgroup_save_control - save control masks and dom_cgrp of a subtree
+ * @cgrp: root of the target subtree
+ *
+- * Save ->subtree_control and ->subtree_ss_mask to the respective old_
+- * prefixed fields for @cgrp's subtree including @cgrp itself.
++ * Save ->subtree_control, ->subtree_ss_mask and ->dom_cgrp to the
++ * respective old_ prefixed fields for @cgrp's subtree including @cgrp
++ * itself.
+ */
+ static void cgroup_save_control(struct cgroup *cgrp)
+ {
+@@ -2847,6 +2848,7 @@ static void cgroup_save_control(struct c
+ cgroup_for_each_live_descendant_pre(dsct, d_css, cgrp) {
+ dsct->old_subtree_control = dsct->subtree_control;
+ dsct->old_subtree_ss_mask = dsct->subtree_ss_mask;
++ dsct->old_dom_cgrp = dsct->dom_cgrp;
+ }
+ }
+
+@@ -2872,11 +2874,12 @@ static void cgroup_propagate_control(str
+ }
+
+ /**
+- * cgroup_restore_control - restore control masks of a subtree
++ * cgroup_restore_control - restore control masks and dom_cgrp of a subtree
+ * @cgrp: root of the target subtree
+ *
+- * Restore ->subtree_control and ->subtree_ss_mask from the respective old_
+- * prefixed fields for @cgrp's subtree including @cgrp itself.
++ * Restore ->subtree_control, ->subtree_ss_mask and ->dom_cgrp from the
++ * respective old_ prefixed fields for @cgrp's subtree including @cgrp
++ * itself.
+ */
+ static void cgroup_restore_control(struct cgroup *cgrp)
+ {
+@@ -2886,6 +2889,7 @@ static void cgroup_restore_control(struc
+ cgroup_for_each_live_descendant_post(dsct, d_css, cgrp) {
+ dsct->subtree_control = dsct->old_subtree_control;
+ dsct->subtree_ss_mask = dsct->old_subtree_ss_mask;
++ dsct->dom_cgrp = dsct->old_dom_cgrp;
+ }
+ }
+
+@@ -3193,6 +3197,8 @@ static int cgroup_enable_threaded(struct
+ {
+ struct cgroup *parent = cgroup_parent(cgrp);
+ struct cgroup *dom_cgrp = parent->dom_cgrp;
++ struct cgroup *dsct;
++ struct cgroup_subsys_state *d_css;
+ int ret;
+
+ lockdep_assert_held(&cgroup_mutex);
+@@ -3222,12 +3228,13 @@ static int cgroup_enable_threaded(struct
+ */
+ cgroup_save_control(cgrp);
+
+- cgrp->dom_cgrp = dom_cgrp;
++ cgroup_for_each_live_descendant_pre(dsct, d_css, cgrp)
++ if (dsct == cgrp || cgroup_is_threaded(dsct))
++ dsct->dom_cgrp = dom_cgrp;
++
+ ret = cgroup_apply_control(cgrp);
+ if (!ret)
+ parent->nr_threaded_children++;
+- else
+- cgrp->dom_cgrp = cgrp;
+
+ cgroup_finalize_control(cgrp, ret);
+ return ret;
--- /dev/null
+From c7cd55504a5b0fc826a2cd9540845979d24ae542 Mon Sep 17 00:00:00 2001
+From: Shenghui Wang <shhuiw@foxmail.com>
+Date: Sun, 7 Oct 2018 14:45:41 +0800
+Subject: dm cache: destroy migration_cache if cache target registration failed
+
+From: Shenghui Wang <shhuiw@foxmail.com>
+
+commit c7cd55504a5b0fc826a2cd9540845979d24ae542 upstream.
+
+Commit 7e6358d244e47 ("dm: fix various targets to dm_register_target
+after module __init resources created") inadvertently introduced this
+bug when it moved dm_register_target() after the call to KMEM_CACHE().
+
+Fixes: 7e6358d244e47 ("dm: fix various targets to dm_register_target after module __init resources created")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shenghui Wang <shhuiw@foxmail.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-cache-target.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm-cache-target.c
++++ b/drivers/md/dm-cache-target.c
+@@ -3492,14 +3492,13 @@ static int __init dm_cache_init(void)
+ int r;
+
+ migration_cache = KMEM_CACHE(dm_cache_migration, 0);
+- if (!migration_cache) {
+- dm_unregister_target(&cache_target);
++ if (!migration_cache)
+ return -ENOMEM;
+- }
+
+ r = dm_register_target(&cache_target);
+ if (r) {
+ DMERR("cache target registration failed: %d", r);
++ kmem_cache_destroy(migration_cache);
+ return r;
+ }
+
--- /dev/null
+From 9864cd5dc54cade89fd4b0954c2e522841aa247c Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@wdc.com>
+Date: Tue, 9 Oct 2018 14:24:31 +0900
+Subject: dm: fix report zone remapping to account for partition offset
+
+From: Damien Le Moal <damien.lemoal@wdc.com>
+
+commit 9864cd5dc54cade89fd4b0954c2e522841aa247c upstream.
+
+If dm-linear or dm-flakey are layered on top of a partition of a zoned
+block device, remapping of the start sector and write pointer position
+of the zones reported by a report zones BIO must be modified to account
+for the target table entry mapping (start offset within the device and
+entry mapping with the dm device). If the target's backing device is a
+partition of a whole disk, the start sector on the physical device of
+the partition must also be accounted for when modifying the zone
+information. However, dm_remap_zone_report() was not considering this
+last case, resulting in incorrect zone information remapping with
+targets using disk partitions.
+
+Fix this by calculating the target backing device start sector using
+the position of the completed report zones BIO and the unchanged
+position and size of the original report zone BIO. With this value
+calculated, the start sector and write pointer position of the target
+zones can be correctly remapped.
+
+Fixes: 10999307c14e ("dm: introduce dm_remap_zone_report()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm.c | 27 ++++++++++++++++++++-------
+ 1 file changed, 20 insertions(+), 7 deletions(-)
+
+--- a/drivers/md/dm.c
++++ b/drivers/md/dm.c
+@@ -1153,12 +1153,14 @@ void dm_accept_partial_bio(struct bio *b
+ EXPORT_SYMBOL_GPL(dm_accept_partial_bio);
+
+ /*
+- * The zone descriptors obtained with a zone report indicate
+- * zone positions within the target device. The zone descriptors
+- * must be remapped to match their position within the dm device.
+- * A target may call dm_remap_zone_report after completion of a
+- * REQ_OP_ZONE_REPORT bio to remap the zone descriptors obtained
+- * from the target device mapping to the dm device.
++ * The zone descriptors obtained with a zone report indicate zone positions
++ * within the target backing device, regardless of that device is a partition
++ * and regardless of the target mapping start sector on the device or partition.
++ * The zone descriptors start sector and write pointer position must be adjusted
++ * to match their relative position within the dm device.
++ * A target may call dm_remap_zone_report() after completion of a
++ * REQ_OP_ZONE_REPORT bio to remap the zone descriptors obtained from the
++ * backing device.
+ */
+ void dm_remap_zone_report(struct dm_target *ti, struct bio *bio, sector_t start)
+ {
+@@ -1169,6 +1171,7 @@ void dm_remap_zone_report(struct dm_targ
+ struct blk_zone *zone;
+ unsigned int nr_rep = 0;
+ unsigned int ofst;
++ sector_t part_offset;
+ struct bio_vec bvec;
+ struct bvec_iter iter;
+ void *addr;
+@@ -1177,6 +1180,15 @@ void dm_remap_zone_report(struct dm_targ
+ return;
+
+ /*
++ * bio sector was incremented by the request size on completion. Taking
++ * into account the original request sector, the target start offset on
++ * the backing device and the target mapping offset (ti->begin), the
++ * start sector of the backing device. The partition offset is always 0
++ * if the target uses a whole device.
++ */
++ part_offset = bio->bi_iter.bi_sector + ti->begin - (start + bio_end_sector(report_bio));
++
++ /*
+ * Remap the start sector of the reported zones. For sequential zones,
+ * also remap the write pointer position.
+ */
+@@ -1193,6 +1205,7 @@ void dm_remap_zone_report(struct dm_targ
+ /* Set zones start sector */
+ while (hdr->nr_zones && ofst < bvec.bv_len) {
+ zone = addr + ofst;
++ zone->start -= part_offset;
+ if (zone->start >= start + ti->len) {
+ hdr->nr_zones = 0;
+ break;
+@@ -1204,7 +1217,7 @@ void dm_remap_zone_report(struct dm_targ
+ else if (zone->cond == BLK_ZONE_COND_EMPTY)
+ zone->wp = zone->start;
+ else
+- zone->wp = zone->wp + ti->begin - start;
++ zone->wp = zone->wp + ti->begin - start - part_offset;
+ }
+ ofst += sizeof(struct blk_zone);
+ hdr->nr_zones--;
--- /dev/null
+From beb9caac211c1be1bc118bb62d5cf09c4107e6a5 Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Wed, 10 Oct 2018 12:01:55 -0400
+Subject: dm linear: eliminate linear_end_io call if CONFIG_DM_ZONED disabled
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit beb9caac211c1be1bc118bb62d5cf09c4107e6a5 upstream.
+
+It is best to avoid any extra overhead associated with bio completion.
+DM core will indirectly call a DM target's .end_io if it is defined.
+In the case of DM linear, there is no need to do so (for every bio that
+completes) if CONFIG_DM_ZONED is not enabled.
+
+Avoiding an extra indirect call for every bio completion is very
+important for ensuring DM linear doesn't incur more overhead that
+further widens the performance gap between dm-linear and raw block
+devices.
+
+Fixes: 0be12c1c7fce7 ("dm linear: add support for zoned block devices")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-linear.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-linear.c
++++ b/drivers/md/dm-linear.c
+@@ -102,6 +102,7 @@ static int linear_map(struct dm_target *
+ return DM_MAPIO_REMAPPED;
+ }
+
++#ifdef CONFIG_DM_ZONED
+ static int linear_end_io(struct dm_target *ti, struct bio *bio,
+ blk_status_t *error)
+ {
+@@ -112,6 +113,7 @@ static int linear_end_io(struct dm_targe
+
+ return DM_ENDIO_DONE;
+ }
++#endif
+
+ static void linear_status(struct dm_target *ti, status_type_t type,
+ unsigned status_flags, char *result, unsigned maxlen)
+@@ -208,12 +210,16 @@ static size_t linear_dax_copy_to_iter(st
+ static struct target_type linear_target = {
+ .name = "linear",
+ .version = {1, 4, 0},
++#ifdef CONFIG_DM_ZONED
++ .end_io = linear_end_io,
+ .features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_ZONED_HM,
++#else
++ .features = DM_TARGET_PASSES_INTEGRITY,
++#endif
+ .module = THIS_MODULE,
+ .ctr = linear_ctr,
+ .dtr = linear_dtr,
+ .map = linear_map,
+- .end_io = linear_end_io,
+ .status = linear_status,
+ .prepare_ioctl = linear_prepare_ioctl,
+ .iterate_devices = linear_iterate_devices,
--- /dev/null
+From 118aa47c7072bce05fc39bd40a1c0a90caed72ab Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@wdc.com>
+Date: Thu, 11 Oct 2018 11:45:30 +0900
+Subject: dm linear: fix linear_end_io conditional definition
+
+From: Damien Le Moal <damien.lemoal@wdc.com>
+
+commit 118aa47c7072bce05fc39bd40a1c0a90caed72ab upstream.
+
+The dm-linear target is independent of the dm-zoned target. For code
+requiring support for zoned block devices, use CONFIG_BLK_DEV_ZONED
+instead of CONFIG_DM_ZONED.
+
+While at it, similarly to dm linear, also enable the DM_TARGET_ZONED_HM
+feature in dm-flakey only if CONFIG_BLK_DEV_ZONED is defined.
+
+Fixes: beb9caac211c1 ("dm linear: eliminate linear_end_io call if CONFIG_DM_ZONED disabled")
+Fixes: 0be12c1c7fce7 ("dm linear: add support for zoned block devices")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-flakey.c | 2 ++
+ drivers/md/dm-linear.c | 4 ++--
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/md/dm-flakey.c
++++ b/drivers/md/dm-flakey.c
+@@ -467,7 +467,9 @@ static int flakey_iterate_devices(struct
+ static struct target_type flakey_target = {
+ .name = "flakey",
+ .version = {1, 5, 0},
++#ifdef CONFIG_BLK_DEV_ZONED
+ .features = DM_TARGET_ZONED_HM,
++#endif
+ .module = THIS_MODULE,
+ .ctr = flakey_ctr,
+ .dtr = flakey_dtr,
+--- a/drivers/md/dm-linear.c
++++ b/drivers/md/dm-linear.c
+@@ -102,7 +102,7 @@ static int linear_map(struct dm_target *
+ return DM_MAPIO_REMAPPED;
+ }
+
+-#ifdef CONFIG_DM_ZONED
++#ifdef CONFIG_BLK_DEV_ZONED
+ static int linear_end_io(struct dm_target *ti, struct bio *bio,
+ blk_status_t *error)
+ {
+@@ -210,7 +210,7 @@ static size_t linear_dax_copy_to_iter(st
+ static struct target_type linear_target = {
+ .name = "linear",
+ .version = {1, 4, 0},
+-#ifdef CONFIG_DM_ZONED
++#ifdef CONFIG_BLK_DEV_ZONED
+ .end_io = linear_end_io,
+ .features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_ZONED_HM,
+ #else
--- /dev/null
+From e46368cf77f2cb6304c51d9ff5f147cfb7dc0074 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Fri, 14 Sep 2018 16:44:03 -0400
+Subject: drm/nouveau/drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit e46368cf77f2cb6304c51d9ff5f147cfb7dc0074 upstream.
+
+While we currently grab a runtime PM ref in nouveau's normal connector
+detection code, we apparently don't do this for MST. This means if we're
+in a scenario where the GPU is suspended and userspace attempts to do a
+connector probe on an MSTC connector, the probe will fail entirely due
+to the DP aux channel and GPU not being woken up:
+
+[ 316.633489] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff
+[ 316.635713] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff
+[ 316.637785] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff
+...
+
+So, grab a runtime PM ref here.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
++++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
+@@ -875,9 +875,22 @@ static enum drm_connector_status
+ nv50_mstc_detect(struct drm_connector *connector, bool force)
+ {
+ struct nv50_mstc *mstc = nv50_mstc(connector);
++ enum drm_connector_status conn_status;
++ int ret;
++
+ if (!mstc->port)
+ return connector_status_disconnected;
+- return drm_dp_mst_detect_port(connector, mstc->port->mgr, mstc->port);
++
++ ret = pm_runtime_get_sync(connector->dev->dev);
++ if (ret < 0 && ret != -EACCES)
++ return connector_status_disconnected;
++
++ conn_status = drm_dp_mst_detect_port(connector, mstc->port->mgr,
++ mstc->port);
++
++ pm_runtime_mark_last_busy(connector->dev->dev);
++ pm_runtime_put_autosuspend(connector->dev->dev);
++ return conn_status;
+ }
+
+ static void
--- /dev/null
+From d7782145e1ad537df4ce74e58c50f1f732a1462d Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Sat, 6 Oct 2018 10:56:11 -0700
+Subject: filesystem-dax: Fix dax_layout_busy_page() livelock
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit d7782145e1ad537df4ce74e58c50f1f732a1462d upstream.
+
+In the presence of multi-order entries the typical
+pagevec_lookup_entries() pattern may loop forever:
+
+ while (index < end && pagevec_lookup_entries(&pvec, mapping, index,
+ min(end - index, (pgoff_t)PAGEVEC_SIZE),
+ indices)) {
+ ...
+ for (i = 0; i < pagevec_count(&pvec); i++) {
+ index = indices[i];
+ ...
+ }
+ index++; /* BUG */
+ }
+
+The loop updates 'index' for each index found and then increments to the
+next possible page to continue the lookup. However, if the last entry in
+the pagevec is multi-order then the next possible page index is more
+than 1 page away. Fix this locally for the filesystem-dax case by
+checking for dax-multi-order entries. Going forward new users of
+multi-order entries need to be similarly careful, or we need a generic
+way to report the page increment in the radix iterator.
+
+Fixes: 5fac7408d828 ("mm, fs, dax: handle layout changes to pinned dax...")
+Cc: <stable@vger.kernel.org>
+Cc: Ross Zwisler <zwisler@kernel.org>
+Cc: Matthew Wilcox <willy@infradead.org>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/dax.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/fs/dax.c
++++ b/fs/dax.c
+@@ -558,6 +558,8 @@ struct page *dax_layout_busy_page(struct
+ while (index < end && pagevec_lookup_entries(&pvec, mapping, index,
+ min(end - index, (pgoff_t)PAGEVEC_SIZE),
+ indices)) {
++ pgoff_t nr_pages = 1;
++
+ for (i = 0; i < pagevec_count(&pvec); i++) {
+ struct page *pvec_ent = pvec.pages[i];
+ void *entry;
+@@ -571,8 +573,15 @@ struct page *dax_layout_busy_page(struct
+
+ xa_lock_irq(&mapping->i_pages);
+ entry = get_unlocked_mapping_entry(mapping, index, NULL);
+- if (entry)
++ if (entry) {
+ page = dax_busy_page(entry);
++ /*
++ * Account for multi-order entries at
++ * the end of the pagevec.
++ */
++ if (i + 1 >= pagevec_count(&pvec))
++ nr_pages = 1UL << dax_radix_order(entry);
++ }
+ put_unlocked_mapping_entry(mapping, index, entry);
+ xa_unlock_irq(&mapping->i_pages);
+ if (page)
+@@ -580,7 +589,7 @@ struct page *dax_layout_busy_page(struct
+ }
+ pagevec_remove_exceptionals(&pvec);
+ pagevec_release(&pvec);
+- index++;
++ index += nr_pages;
+
+ if (page)
+ break;
--- /dev/null
+From 9735082a7cbae572c2eabdc45acecc8c9fa0759b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ramses=20Ram=C3=ADrez?= <ramzeto@gmail.com>
+Date: Fri, 28 Sep 2018 16:59:26 -0700
+Subject: Input: xpad - add support for Xbox1 PDP Camo series gamepad
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ramses Ramírez <ramzeto@gmail.com>
+
+commit 9735082a7cbae572c2eabdc45acecc8c9fa0759b upstream.
+
+The "Xbox One PDP Wired Controller - Camo series" has a different
+product-id than the regular PDP controller and the PDP stealth series,
+but it uses the same initialization sequence. This patch adds the
+product-id of the camo series to the structures that handle the other
+PDP Xbox One controllers.
+
+Signed-off-by: Ramses Ramírez <ramzeto@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/joystick/xpad.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/input/joystick/xpad.c
++++ b/drivers/input/joystick/xpad.c
+@@ -231,6 +231,7 @@ static const struct xpad_device {
+ { 0x0e6f, 0x0246, "Rock Candy Gamepad for Xbox One 2015", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a4, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE },
++ { 0x0e6f, 0x02a6, "PDP Wired Controller for Xbox One - Camo Series", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 },
+ { 0x0e6f, 0x0346, "Rock Candy Gamepad for Xbox One 2016", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 },
+@@ -530,6 +531,8 @@ static const struct xboxone_init_packet
+ XBOXONE_INIT_PKT(0x0e6f, 0x02ab, xboxone_pdp_init2),
+ XBOXONE_INIT_PKT(0x0e6f, 0x02a4, xboxone_pdp_init1),
+ XBOXONE_INIT_PKT(0x0e6f, 0x02a4, xboxone_pdp_init2),
++ XBOXONE_INIT_PKT(0x0e6f, 0x02a6, xboxone_pdp_init1),
++ XBOXONE_INIT_PKT(0x0e6f, 0x02a6, xboxone_pdp_init2),
+ XBOXONE_INIT_PKT(0x24c6, 0x541a, xboxone_rumblebegin_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x542a, xboxone_rumblebegin_init),
+ XBOXONE_INIT_PKT(0x24c6, 0x543a, xboxone_rumblebegin_init),
--- /dev/null
+From 76ebebd2464c5c8a4453c98b6dbf9c95a599e810 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Fri, 17 Aug 2018 15:19:37 -0400
+Subject: mach64: detect the dot clock divider correctly on sparc
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 76ebebd2464c5c8a4453c98b6dbf9c95a599e810 upstream.
+
+On Sun Ultra 5, it happens that the dot clock is not set up properly for
+some videomodes. For example, if we set the videomode "r1024x768x60" in
+the firmware, Linux would incorrectly set a videomode with refresh rate
+180Hz when booting (suprisingly, my LCD monitor can display it, although
+display quality is very low).
+
+The reason is this: Older mach64 cards set the divider in the register
+VCLK_POST_DIV. The register has four 2-bit fields (the field that is
+actually used is specified in the lowest two bits of the register
+CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
+there's another bit added - the top four bits of PLL_EXT_CNTL extend the
+divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
+The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
+them, so it can work regardless if the card supports them. However, the
+sparc64 firmware may set these extended dividers during boot - and the
+mach64 driver detects incorrect dot clock in this case.
+
+This patch makes the driver read the additional divider bit from
+PLL_EXT_CNTL and calculate the initial refresh rate properly.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Acked-by: David S. Miller <davem@davemloft.net>
+Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/aty/atyfb.h | 3 ++-
+ drivers/video/fbdev/aty/atyfb_base.c | 7 ++++---
+ drivers/video/fbdev/aty/mach64_ct.c | 10 +++++-----
+ 3 files changed, 11 insertions(+), 9 deletions(-)
+
+--- a/drivers/video/fbdev/aty/atyfb.h
++++ b/drivers/video/fbdev/aty/atyfb.h
+@@ -333,6 +333,8 @@ extern const struct aty_pll_ops aty_pll_
+ extern void aty_set_pll_ct(const struct fb_info *info, const union aty_pll *pll);
+ extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
+
++extern const u8 aty_postdividers[8];
++
+
+ /*
+ * Hardware cursor support
+@@ -359,7 +361,6 @@ static inline void wait_for_idle(struct
+
+ extern void aty_reset_engine(const struct atyfb_par *par);
+ extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
+-extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
+
+ void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
+ void atyfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
+--- a/drivers/video/fbdev/aty/atyfb_base.c
++++ b/drivers/video/fbdev/aty/atyfb_base.c
+@@ -3087,17 +3087,18 @@ static int atyfb_setup_sparc(struct pci_
+ /*
+ * PLL Reference Divider M:
+ */
+- M = pll_regs[2];
++ M = pll_regs[PLL_REF_DIV];
+
+ /*
+ * PLL Feedback Divider N (Dependent on CLOCK_CNTL):
+ */
+- N = pll_regs[7 + (clock_cntl & 3)];
++ N = pll_regs[VCLK0_FB_DIV + (clock_cntl & 3)];
+
+ /*
+ * PLL Post Divider P (Dependent on CLOCK_CNTL):
+ */
+- P = 1 << (pll_regs[6] >> ((clock_cntl & 3) << 1));
++ P = aty_postdividers[((pll_regs[VCLK_POST_DIV] >> ((clock_cntl & 3) << 1)) & 3) |
++ ((pll_regs[PLL_EXT_CNTL] >> (2 + (clock_cntl & 3))) & 4)];
+
+ /*
+ * PLL Divider Q:
+--- a/drivers/video/fbdev/aty/mach64_ct.c
++++ b/drivers/video/fbdev/aty/mach64_ct.c
+@@ -115,7 +115,7 @@ static void aty_st_pll_ct(int offset, u8
+ */
+
+ #define Maximum_DSP_PRECISION 7
+-static u8 postdividers[] = {1,2,4,8,3};
++const u8 aty_postdividers[8] = {1,2,4,8,3,5,6,12};
+
+ static int aty_dsp_gt(const struct fb_info *info, u32 bpp, struct pll_ct *pll)
+ {
+@@ -222,7 +222,7 @@ static int aty_valid_pll_ct(const struct
+ pll->vclk_post_div += (q < 64*8);
+ pll->vclk_post_div += (q < 32*8);
+ }
+- pll->vclk_post_div_real = postdividers[pll->vclk_post_div];
++ pll->vclk_post_div_real = aty_postdividers[pll->vclk_post_div];
+ // pll->vclk_post_div <<= 6;
+ pll->vclk_fb_div = q * pll->vclk_post_div_real / 8;
+ pllvclk = (1000000 * 2 * pll->vclk_fb_div) /
+@@ -513,7 +513,7 @@ static int aty_init_pll_ct(const struct
+ u8 mclk_fb_div, pll_ext_cntl;
+ pll->ct.pll_ref_div = aty_ld_pll_ct(PLL_REF_DIV, par);
+ pll_ext_cntl = aty_ld_pll_ct(PLL_EXT_CNTL, par);
+- pll->ct.xclk_post_div_real = postdividers[pll_ext_cntl & 0x07];
++ pll->ct.xclk_post_div_real = aty_postdividers[pll_ext_cntl & 0x07];
+ mclk_fb_div = aty_ld_pll_ct(MCLK_FB_DIV, par);
+ if (pll_ext_cntl & PLL_MFB_TIMES_4_2B)
+ mclk_fb_div <<= 1;
+@@ -535,7 +535,7 @@ static int aty_init_pll_ct(const struct
+ xpost_div += (q < 64*8);
+ xpost_div += (q < 32*8);
+ }
+- pll->ct.xclk_post_div_real = postdividers[xpost_div];
++ pll->ct.xclk_post_div_real = aty_postdividers[xpost_div];
+ pll->ct.mclk_fb_div = q * pll->ct.xclk_post_div_real / 8;
+
+ #ifdef CONFIG_PPC
+@@ -584,7 +584,7 @@ static int aty_init_pll_ct(const struct
+ mpost_div += (q < 64*8);
+ mpost_div += (q < 32*8);
+ }
+- sclk_post_div_real = postdividers[mpost_div];
++ sclk_post_div_real = aty_postdividers[mpost_div];
+ pll->ct.sclk_fb_div = q * sclk_post_div_real / 8;
+ pll->ct.spll_cntl2 = mpost_div << 4;
+ #ifdef DEBUG
--- /dev/null
+From 951d223c6c16ed5d2a71a4d1f13c1e65d6882156 Mon Sep 17 00:00:00 2001
+From: Paul Burton <paul.burton@mips.com>
+Date: Thu, 27 Sep 2018 22:59:18 +0000
+Subject: MIPS: Fix CONFIG_CMDLINE handling
+
+From: Paul Burton <paul.burton@mips.com>
+
+commit 951d223c6c16ed5d2a71a4d1f13c1e65d6882156 upstream.
+
+Commit 8ce355cf2e38 ("MIPS: Setup boot_command_line before
+plat_mem_setup") fixed a problem for systems which have
+CONFIG_CMDLINE_BOOL=y & use a DT with a chosen node that has either no
+bootargs property or an empty one. In this configuration
+early_init_dt_scan_chosen() copies CONFIG_CMDLINE into
+boot_command_line, but the MIPS code doesn't know this so it appends
+CONFIG_CMDLINE (via builtin_cmdline) to boot_command_line again. The
+result is that boot_command_line contains the arguments from
+CONFIG_CMDLINE twice.
+
+That commit took the approach of simply setting up boot_command_line
+from the MIPS code before early_init_dt_scan_chosen() runs, causing it
+not to copy CONFIG_CMDLINE to boot_command_line if a chosen node with no
+bootargs property is found.
+
+Unfortunately this is problematic for systems which do have a non-empty
+bootargs property & CONFIG_CMDLINE_BOOL=y. There
+early_init_dt_scan_chosen() will overwrite boot_command_line with the
+arguments from DT, which means we lose those from CONFIG_CMDLINE
+entirely. This breaks CONFIG_MIPS_CMDLINE_DTB_EXTEND. If we have
+CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER or
+CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND selected and the DT has a bootargs
+property which we should ignore, it will instead be honoured breaking
+those configurations too.
+
+Fix this by reverting commit 8ce355cf2e38 ("MIPS: Setup
+boot_command_line before plat_mem_setup") to restore the former
+behaviour, and fixing the CONFIG_CMDLINE duplication issue by
+initializing boot_command_line to a non-empty string that
+early_init_dt_scan_chosen() will not overwrite with CONFIG_CMDLINE.
+
+This is a little ugly, but cleanup in this area is on its way. In the
+meantime this is at least easy to backport & contains the ugliness
+within arch/mips/.
+
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Fixes: 8ce355cf2e38 ("MIPS: Setup boot_command_line before plat_mem_setup")
+References: https://patchwork.linux-mips.org/patch/18804/
+Patchwork: https://patchwork.linux-mips.org/patch/20813/
+Cc: Frank Rowand <frowand.list@gmail.com>
+Cc: Jaedon Shin <jaedon.shin@gmail.com>
+Cc: Mathieu Malaterre <malat@debian.org>
+Cc: Rob Herring <robh+dt@kernel.org>
+Cc: devicetree@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: linux-mips@linux-mips.org
+Cc: stable@vger.kernel.org # v4.16+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/kernel/setup.c | 48 +++++++++++++++++++++++++++--------------------
+ 1 file changed, 28 insertions(+), 20 deletions(-)
+
+--- a/arch/mips/kernel/setup.c
++++ b/arch/mips/kernel/setup.c
+@@ -835,6 +835,34 @@ static void __init arch_mem_init(char **
+ struct memblock_region *reg;
+ extern void plat_mem_setup(void);
+
++ /*
++ * Initialize boot_command_line to an innocuous but non-empty string in
++ * order to prevent early_init_dt_scan_chosen() from copying
++ * CONFIG_CMDLINE into it without our knowledge. We handle
++ * CONFIG_CMDLINE ourselves below & don't want to duplicate its
++ * content because repeating arguments can be problematic.
++ */
++ strlcpy(boot_command_line, " ", COMMAND_LINE_SIZE);
++
++ /* call board setup routine */
++ plat_mem_setup();
++
++ /*
++ * Make sure all kernel memory is in the maps. The "UP" and
++ * "DOWN" are opposite for initdata since if it crosses over
++ * into another memory section you don't want that to be
++ * freed when the initdata is freed.
++ */
++ arch_mem_addpart(PFN_DOWN(__pa_symbol(&_text)) << PAGE_SHIFT,
++ PFN_UP(__pa_symbol(&_edata)) << PAGE_SHIFT,
++ BOOT_MEM_RAM);
++ arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT,
++ PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT,
++ BOOT_MEM_INIT_RAM);
++
++ pr_info("Determined physical RAM map:\n");
++ print_memory_map();
++
+ #if defined(CONFIG_CMDLINE_BOOL) && defined(CONFIG_CMDLINE_OVERRIDE)
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ #else
+@@ -862,26 +890,6 @@ static void __init arch_mem_init(char **
+ }
+ #endif
+ #endif
+-
+- /* call board setup routine */
+- plat_mem_setup();
+-
+- /*
+- * Make sure all kernel memory is in the maps. The "UP" and
+- * "DOWN" are opposite for initdata since if it crosses over
+- * into another memory section you don't want that to be
+- * freed when the initdata is freed.
+- */
+- arch_mem_addpart(PFN_DOWN(__pa_symbol(&_text)) << PAGE_SHIFT,
+- PFN_UP(__pa_symbol(&_edata)) << PAGE_SHIFT,
+- BOOT_MEM_RAM);
+- arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT,
+- PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT,
+- BOOT_MEM_INIT_RAM);
+-
+- pr_info("Determined physical RAM map:\n");
+- print_memory_map();
+-
+ strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
+
+ *cmdline_p = command_line;
--- /dev/null
+From ea7e0480a4b695d0aa6b3fa99bd658a003122113 Mon Sep 17 00:00:00 2001
+From: Paul Burton <paul.burton@mips.com>
+Date: Tue, 25 Sep 2018 15:51:26 -0700
+Subject: MIPS: VDSO: Always map near top of user memory
+
+From: Paul Burton <paul.burton@mips.com>
+
+commit ea7e0480a4b695d0aa6b3fa99bd658a003122113 upstream.
+
+When using the legacy mmap layout, for example triggered using ulimit -s
+unlimited, get_unmapped_area() fills memory from bottom to top starting
+from a fairly low address near TASK_UNMAPPED_BASE.
+
+This placement is suboptimal if the user application wishes to allocate
+large amounts of heap memory using the brk syscall. With the VDSO being
+located low in the user's virtual address space, the amount of space
+available for access using brk is limited much more than it was prior to
+the introduction of the VDSO.
+
+For example:
+
+ # ulimit -s unlimited; cat /proc/self/maps
+ 00400000-004ec000 r-xp 00000000 08:00 71436 /usr/bin/coreutils
+ 004fc000-004fd000 rwxp 000ec000 08:00 71436 /usr/bin/coreutils
+ 004fd000-0050f000 rwxp 00000000 00:00 0
+ 00cc3000-00ce4000 rwxp 00000000 00:00 0 [heap]
+ 2ab96000-2ab98000 r--p 00000000 00:00 0 [vvar]
+ 2ab98000-2ab99000 r-xp 00000000 00:00 0 [vdso]
+ 2ab99000-2ab9d000 rwxp 00000000 00:00 0
+ ...
+
+Resolve this by adjusting STACK_TOP to reserve space for the VDSO &
+providing an address hint to get_unmapped_area() causing it to use this
+space even when using the legacy mmap layout.
+
+We reserve enough space for the VDSO, plus 1MB or 256MB for 32 bit & 64
+bit systems respectively within which we randomize the VDSO base
+address. Previously this randomization was taken care of by the mmap
+base address randomization performed by arch_mmap_rnd(). The 1MB & 256MB
+sizes are somewhat arbitrary but chosen such that we have some
+randomization without taking up too much of the user's virtual address
+space, which is often in short supply for 32 bit systems.
+
+With this the VDSO is always mapped at a high address, leaving lots of
+space for statically linked programs to make use of brk:
+
+ # ulimit -s unlimited; cat /proc/self/maps
+ 00400000-004ec000 r-xp 00000000 08:00 71436 /usr/bin/coreutils
+ 004fc000-004fd000 rwxp 000ec000 08:00 71436 /usr/bin/coreutils
+ 004fd000-0050f000 rwxp 00000000 00:00 0
+ 00c28000-00c49000 rwxp 00000000 00:00 0 [heap]
+ ...
+ 7f67c000-7f69d000 rwxp 00000000 00:00 0 [stack]
+ 7f7fc000-7f7fd000 rwxp 00000000 00:00 0
+ 7fcf1000-7fcf3000 r--p 00000000 00:00 0 [vvar]
+ 7fcf3000-7fcf4000 r-xp 00000000 00:00 0 [vdso]
+
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Reported-by: Huacai Chen <chenhc@lemote.com>
+Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
+Cc: Huacai Chen <chenhc@lemote.com>
+Cc: linux-mips@linux-mips.org
+Cc: stable@vger.kernel.org # v4.4+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/include/asm/processor.h | 10 +++++-----
+ arch/mips/kernel/process.c | 25 +++++++++++++++++++++++++
+ arch/mips/kernel/vdso.c | 18 +++++++++++++++++-
+ 3 files changed, 47 insertions(+), 6 deletions(-)
+
+--- a/arch/mips/include/asm/processor.h
++++ b/arch/mips/include/asm/processor.h
+@@ -13,6 +13,7 @@
+
+ #include <linux/atomic.h>
+ #include <linux/cpumask.h>
++#include <linux/sizes.h>
+ #include <linux/threads.h>
+
+ #include <asm/cachectl.h>
+@@ -80,11 +81,10 @@ extern unsigned int vced_count, vcei_cou
+
+ #endif
+
+-/*
+- * One page above the stack is used for branch delay slot "emulation".
+- * See dsemul.c for details.
+- */
+-#define STACK_TOP ((TASK_SIZE & PAGE_MASK) - PAGE_SIZE)
++#define VDSO_RANDOMIZE_SIZE (TASK_IS_32BIT_ADDR ? SZ_1M : SZ_256M)
++
++extern unsigned long mips_stack_top(void);
++#define STACK_TOP mips_stack_top()
+
+ /*
+ * This decides where the kernel will search for a free chunk of vm
+--- a/arch/mips/kernel/process.c
++++ b/arch/mips/kernel/process.c
+@@ -31,6 +31,7 @@
+ #include <linux/prctl.h>
+ #include <linux/nmi.h>
+
++#include <asm/abi.h>
+ #include <asm/asm.h>
+ #include <asm/bootinfo.h>
+ #include <asm/cpu.h>
+@@ -38,6 +39,7 @@
+ #include <asm/dsp.h>
+ #include <asm/fpu.h>
+ #include <asm/irq.h>
++#include <asm/mips-cps.h>
+ #include <asm/msa.h>
+ #include <asm/pgtable.h>
+ #include <asm/mipsregs.h>
+@@ -644,6 +646,29 @@ out:
+ return pc;
+ }
+
++unsigned long mips_stack_top(void)
++{
++ unsigned long top = TASK_SIZE & PAGE_MASK;
++
++ /* One page for branch delay slot "emulation" */
++ top -= PAGE_SIZE;
++
++ /* Space for the VDSO, data page & GIC user page */
++ top -= PAGE_ALIGN(current->thread.abi->vdso->size);
++ top -= PAGE_SIZE;
++ top -= mips_gic_present() ? PAGE_SIZE : 0;
++
++ /* Space for cache colour alignment */
++ if (cpu_has_dc_aliases)
++ top -= shm_align_mask + 1;
++
++ /* Space to randomize the VDSO base */
++ if (current->flags & PF_RANDOMIZE)
++ top -= VDSO_RANDOMIZE_SIZE;
++
++ return top;
++}
++
+ /*
+ * Don't forget that the stack pointer must be aligned on a 8 bytes
+ * boundary for 32-bits ABI and 16 bytes for 64-bits ABI.
+--- a/arch/mips/kernel/vdso.c
++++ b/arch/mips/kernel/vdso.c
+@@ -15,6 +15,7 @@
+ #include <linux/ioport.h>
+ #include <linux/kernel.h>
+ #include <linux/mm.h>
++#include <linux/random.h>
+ #include <linux/sched.h>
+ #include <linux/slab.h>
+ #include <linux/timekeeper_internal.h>
+@@ -97,6 +98,21 @@ void update_vsyscall_tz(void)
+ }
+ }
+
++static unsigned long vdso_base(void)
++{
++ unsigned long base;
++
++ /* Skip the delay slot emulation page */
++ base = STACK_TOP + PAGE_SIZE;
++
++ if (current->flags & PF_RANDOMIZE) {
++ base += get_random_int() & (VDSO_RANDOMIZE_SIZE - 1);
++ base = PAGE_ALIGN(base);
++ }
++
++ return base;
++}
++
+ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
+ {
+ struct mips_vdso_image *image = current->thread.abi->vdso;
+@@ -137,7 +153,7 @@ int arch_setup_additional_pages(struct l
+ if (cpu_has_dc_aliases)
+ size += shm_align_mask + 1;
+
+- base = get_unmapped_area(NULL, 0, size, 0, 0);
++ base = get_unmapped_area(NULL, vdso_base(), size, 0, 0);
+ if (IS_ERR_VALUE(base)) {
+ ret = base;
+ goto out;
--- /dev/null
+From 7aa867dd89526e9cfd9714d8b9b587c016eaea34 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Fri, 12 Oct 2018 21:34:32 -0700
+Subject: mm/mmap.c: don't clobber partially overlapping VMA with MAP_FIXED_NOREPLACE
+
+From: Jann Horn <jannh@google.com>
+
+commit 7aa867dd89526e9cfd9714d8b9b587c016eaea34 upstream.
+
+Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
+application causes that application to randomly crash. The existing check
+for handling MAP_FIXED_NOREPLACE looks up the first VMA that either
+overlaps or follows the requested region, and then bails out if that VMA
+overlaps *the start* of the requested region. It does not bail out if the
+VMA only overlaps another part of the requested region.
+
+Fix it by checking that the found VMA only starts at or after the end of
+the requested region, in which case there is no overlap.
+
+Test case:
+
+user@debian:~$ cat mmap_fixed_simple.c
+#include <sys/mman.h>
+#include <errno.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+
+#ifndef MAP_FIXED_NOREPLACE
+#define MAP_FIXED_NOREPLACE 0x100000
+#endif
+
+int main(void) {
+ char *p;
+
+ errno = 0;
+ p = mmap((void*)0x10001000, 0x4000, PROT_NONE,
+MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
+ printf("p1=%p err=%m\n", p);
+
+ errno = 0;
+ p = mmap((void*)0x10000000, 0x2000, PROT_READ,
+MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
+ printf("p2=%p err=%m\n", p);
+
+ char cmd[100];
+ sprintf(cmd, "cat /proc/%d/maps", getpid());
+ system(cmd);
+
+ return 0;
+}
+user@debian:~$ gcc -o mmap_fixed_simple mmap_fixed_simple.c
+user@debian:~$ ./mmap_fixed_simple
+p1=0x10001000 err=Success
+p2=0x10000000 err=Success
+10000000-10002000 r--p 00000000 00:00 0
+10002000-10005000 ---p 00000000 00:00 0
+564a9a06f000-564a9a070000 r-xp 00000000 fe:01 264004
+ /home/user/mmap_fixed_simple
+564a9a26f000-564a9a270000 r--p 00000000 fe:01 264004
+ /home/user/mmap_fixed_simple
+564a9a270000-564a9a271000 rw-p 00001000 fe:01 264004
+ /home/user/mmap_fixed_simple
+564a9a54a000-564a9a56b000 rw-p 00000000 00:00 0 [heap]
+7f8eba447000-7f8eba5dc000 r-xp 00000000 fe:01 405885
+ /lib/x86_64-linux-gnu/libc-2.24.so
+7f8eba5dc000-7f8eba7dc000 ---p 00195000 fe:01 405885
+ /lib/x86_64-linux-gnu/libc-2.24.so
+7f8eba7dc000-7f8eba7e0000 r--p 00195000 fe:01 405885
+ /lib/x86_64-linux-gnu/libc-2.24.so
+7f8eba7e0000-7f8eba7e2000 rw-p 00199000 fe:01 405885
+ /lib/x86_64-linux-gnu/libc-2.24.so
+7f8eba7e2000-7f8eba7e6000 rw-p 00000000 00:00 0
+7f8eba7e6000-7f8eba809000 r-xp 00000000 fe:01 405876
+ /lib/x86_64-linux-gnu/ld-2.24.so
+7f8eba9e9000-7f8eba9eb000 rw-p 00000000 00:00 0
+7f8ebaa06000-7f8ebaa09000 rw-p 00000000 00:00 0
+7f8ebaa09000-7f8ebaa0a000 r--p 00023000 fe:01 405876
+ /lib/x86_64-linux-gnu/ld-2.24.so
+7f8ebaa0a000-7f8ebaa0b000 rw-p 00024000 fe:01 405876
+ /lib/x86_64-linux-gnu/ld-2.24.so
+7f8ebaa0b000-7f8ebaa0c000 rw-p 00000000 00:00 0
+7ffcc99fa000-7ffcc9a1b000 rw-p 00000000 00:00 0 [stack]
+7ffcc9b44000-7ffcc9b47000 r--p 00000000 00:00 0 [vvar]
+7ffcc9b47000-7ffcc9b49000 r-xp 00000000 00:00 0 [vdso]
+ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
+ [vsyscall]
+user@debian:~$ uname -a
+Linux debian 4.19.0-rc6+ #181 SMP Wed Oct 3 23:43:42 CEST 2018 x86_64 GNU/Linux
+user@debian:~$
+
+As you can see, the first page of the mapping at 0x10001000 was clobbered.
+
+Link: http://lkml.kernel.org/r/20181010152736.99475-1-jannh@google.com
+Fixes: a4ff8e8620d3 ("mm: introduce MAP_FIXED_NOREPLACE")
+Signed-off-by: Jann Horn <jannh@google.com>
+Reported-by: Daniel Micay <danielmicay@gmail.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: John Hubbard <jhubbard@nvidia.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mmap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -1410,7 +1410,7 @@ unsigned long do_mmap(struct file *file,
+ if (flags & MAP_FIXED_NOREPLACE) {
+ struct vm_area_struct *vma = find_vma(mm, addr);
+
+- if (vma && vma->vm_start <= addr)
++ if (vma && vma->vm_start < addr + len)
+ return -EEXIST;
+ }
+
--- /dev/null
+From 4628a64591e6cee181237060961e98c615c33966 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Tue, 9 Oct 2018 12:19:17 +0200
+Subject: mm: Preserve _PAGE_DEVMAP across mprotect() calls
+
+From: Jan Kara <jack@suse.cz>
+
+commit 4628a64591e6cee181237060961e98c615c33966 upstream.
+
+Currently _PAGE_DEVMAP bit is not preserved in mprotect(2) calls. As a
+result we will see warnings such as:
+
+BUG: Bad page map in process JobWrk0013 pte:800001803875ea25 pmd:7624381067
+addr:00007f0930720000 vm_flags:280000f9 anon_vma: (null) mapping:ffff97f2384056f0 index:0
+file:457-000000fe00000030-00000009-000000ca-00000001_2001.fileblock fault:xfs_filemap_fault [xfs] mmap:xfs_file_mmap [xfs] readpage: (null)
+CPU: 3 PID: 15848 Comm: JobWrk0013 Tainted: G W 4.12.14-2.g7573215-default #1 SLE12-SP4 (unreleased)
+Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.01.00.0833.051120182255 05/11/2018
+Call Trace:
+ dump_stack+0x5a/0x75
+ print_bad_pte+0x217/0x2c0
+ ? enqueue_task_fair+0x76/0x9f0
+ _vm_normal_page+0xe5/0x100
+ zap_pte_range+0x148/0x740
+ unmap_page_range+0x39a/0x4b0
+ unmap_vmas+0x42/0x90
+ unmap_region+0x99/0xf0
+ ? vma_gap_callbacks_rotate+0x1a/0x20
+ do_munmap+0x255/0x3a0
+ vm_munmap+0x54/0x80
+ SyS_munmap+0x1d/0x30
+ do_syscall_64+0x74/0x150
+ entry_SYSCALL_64_after_hwframe+0x3d/0xa2
+...
+
+when mprotect(2) gets used on DAX mappings. Also there is a wide variety
+of other failures that can result from the missing _PAGE_DEVMAP flag
+when the area gets used by get_user_pages() later.
+
+Fix the problem by including _PAGE_DEVMAP in a set of flags that get
+preserved by mprotect(2).
+
+Fixes: 69660fd797c3 ("x86, mm: introduce _PAGE_DEVMAP")
+Fixes: ebd31197931d ("powerpc/mm: Add devmap support for ppc64")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/book3s/64/pgtable.h | 4 ++--
+ arch/x86/include/asm/pgtable_types.h | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
++++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
+@@ -104,7 +104,7 @@
+ */
+ #define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
+ _PAGE_ACCESSED | H_PAGE_THP_HUGE | _PAGE_PTE | \
+- _PAGE_SOFT_DIRTY)
++ _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
+ /*
+ * user access blocked by key
+ */
+@@ -122,7 +122,7 @@
+ */
+ #define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
+ _PAGE_ACCESSED | _PAGE_SPECIAL | _PAGE_PTE | \
+- _PAGE_SOFT_DIRTY)
++ _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
+
+ #define H_PTE_PKEY (H_PTE_PKEY_BIT0 | H_PTE_PKEY_BIT1 | H_PTE_PKEY_BIT2 | \
+ H_PTE_PKEY_BIT3 | H_PTE_PKEY_BIT4)
+--- a/arch/x86/include/asm/pgtable_types.h
++++ b/arch/x86/include/asm/pgtable_types.h
+@@ -123,7 +123,7 @@
+ */
+ #define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \
+ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \
+- _PAGE_SOFT_DIRTY)
++ _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
+ #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
+
+ /*
--- /dev/null
+From bfba8e5cf28f413aa05571af493871d74438979f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
+Date: Fri, 12 Oct 2018 21:34:36 -0700
+Subject: mm/thp: fix call to mmu_notifier in set_pmd_migration_entry() v2
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jérôme Glisse <jglisse@redhat.com>
+
+commit bfba8e5cf28f413aa05571af493871d74438979f upstream.
+
+Inside set_pmd_migration_entry() we are holding page table locks and thus
+we can not sleep so we can not call invalidate_range_start/end()
+
+So remove call to mmu_notifier_invalidate_range_start/end() because they
+are call inside the function calling set_pmd_migration_entry() (see
+try_to_unmap_one()).
+
+Link: http://lkml.kernel.org/r/20181012181056.7864-1-jglisse@redhat.com
+Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
+Reported-by: Andrea Arcangeli <aarcange@redhat.com>
+Reviewed-by: Zi Yan <zi.yan@cs.rutgers.edu>
+Acked-by: Michal Hocko <mhocko@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+Cc: Dave Hansen <dave.hansen@intel.com>
+Cc: David Nellans <dnellans@nvidia.com>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/huge_memory.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -2883,9 +2883,6 @@ void set_pmd_migration_entry(struct page
+ if (!(pvmw->pmd && !pvmw->pte))
+ return;
+
+- mmu_notifier_invalidate_range_start(mm, address,
+- address + HPAGE_PMD_SIZE);
+-
+ flush_cache_range(vma, address, address + HPAGE_PMD_SIZE);
+ pmdval = *pvmw->pmd;
+ pmdp_invalidate(vma, address, pvmw->pmd);
+@@ -2898,9 +2895,6 @@ void set_pmd_migration_entry(struct page
+ set_pmd_at(mm, address, pvmw->pmd, pmdswp);
+ page_remove_rmap(page, true);
+ put_page(page);
+-
+- mmu_notifier_invalidate_range_end(mm, address,
+- address + HPAGE_PMD_SIZE);
+ }
+
+ void remove_migration_pmd(struct page_vma_mapped_walk *pvmw, struct page *new)
--- /dev/null
+From 28e2c4bb99aa40f9d5f07ac130cbc4da0ea93079 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Fri, 5 Oct 2018 15:52:03 -0700
+Subject: mm/vmstat.c: fix outdated vmstat_text
+
+From: Jann Horn <jannh@google.com>
+
+commit 28e2c4bb99aa40f9d5f07ac130cbc4da0ea93079 upstream.
+
+7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely") removed the
+VMACACHE_FULL_FLUSHES statistics, but didn't remove the corresponding
+entry in vmstat_text. This causes an out-of-bounds access in
+vmstat_show().
+
+Luckily this only affects kernels with CONFIG_DEBUG_VM_VMACACHE=y, which
+is probably very rare.
+
+Link: http://lkml.kernel.org/r/20181001143138.95119-1-jannh@google.com
+Fixes: 7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely")
+Signed-off-by: Jann Horn <jannh@google.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Roman Gushchin <guro@fb.com>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Christoph Lameter <clameter@sgi.com>
+Cc: Kemi Wang <kemi.wang@intel.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/vmstat.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/mm/vmstat.c
++++ b/mm/vmstat.c
+@@ -1286,7 +1286,6 @@ const char * const vmstat_text[] = {
+ #ifdef CONFIG_DEBUG_VM_VMACACHE
+ "vmacache_find_calls",
+ "vmacache_find_hits",
+- "vmacache_full_flushes",
+ #endif
+ #ifdef CONFIG_SWAP
+ "swap_ra",
--- /dev/null
+From 41591b38f5f8f78344954b68582b5f00e56ffe61 Mon Sep 17 00:00:00 2001
+From: Chris Boot <bootc@bootc.net>
+Date: Mon, 8 Oct 2018 17:07:30 +0200
+Subject: mmc: block: avoid multiblock reads for the last sector in SPI mode
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chris Boot <bootc@bootc.net>
+
+commit 41591b38f5f8f78344954b68582b5f00e56ffe61 upstream.
+
+On some SD cards over SPI, reading with the multiblock read command the last
+sector will leave the card in a bad state.
+
+Remove last sectors from the multiblock reading cmd.
+
+Signed-off-by: Chris Boot <bootc@bootc.net>
+Signed-off-by: Clément Péron <peron.clem@gmail.com>
+Cc: stable@vger.kernel.org # v4.10+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/block.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/mmc/core/block.c
++++ b/drivers/mmc/core/block.c
+@@ -1371,6 +1371,16 @@ static void mmc_blk_data_prep(struct mmc
+
+ if (brq->data.blocks > 1) {
+ /*
++ * Some SD cards in SPI mode return a CRC error or even lock up
++ * completely when trying to read the last block using a
++ * multiblock read command.
++ */
++ if (mmc_host_is_spi(card->host) && (rq_data_dir(req) == READ) &&
++ (blk_rq_pos(req) + blk_rq_sectors(req) ==
++ get_capacity(md->disk)))
++ brq->data.blocks--;
++
++ /*
+ * After a read error, we redo the request one sector
+ * at a time in order to accurately determine which
+ * sectors can be read successfully.
--- /dev/null
+From 6685b357363bfe295e3ae73665014db4aed62c58 Mon Sep 17 00:00:00 2001
+From: Mike Rapoport <rppt@linux.vnet.ibm.com>
+Date: Sun, 7 Oct 2018 11:31:51 +0300
+Subject: percpu: stop leaking bitmap metadata blocks
+
+From: Mike Rapoport <rppt@linux.vnet.ibm.com>
+
+commit 6685b357363bfe295e3ae73665014db4aed62c58 upstream.
+
+The commit ca460b3c9627 ("percpu: introduce bitmap metadata blocks")
+introduced bitmap metadata blocks. These metadata blocks are allocated
+whenever a new chunk is created, but they are never freed. Fix it.
+
+Fixes: ca460b3c9627 ("percpu: introduce bitmap metadata blocks")
+Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dennis Zhou <dennis@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/percpu.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/mm/percpu.c
++++ b/mm/percpu.c
+@@ -1204,6 +1204,7 @@ static void pcpu_free_chunk(struct pcpu_
+ {
+ if (!chunk)
+ return;
++ pcpu_mem_free(chunk->md_blocks);
+ pcpu_mem_free(chunk->bound_map);
+ pcpu_mem_free(chunk->alloc_map);
+ pcpu_mem_free(chunk);
--- /dev/null
+From 25e11700b54c7b6b5ebfc4361981dae12299557b Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Tue, 11 Sep 2018 14:45:03 +0300
+Subject: perf script python: Fix export-to-postgresql.py occasional failure
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 25e11700b54c7b6b5ebfc4361981dae12299557b upstream.
+
+Occasional export failures were found to be caused by truncating 64-bit
+pointers to 32-bits. Fix by explicitly setting types for all ctype
+arguments and results.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/20180911114504.28516-2-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/scripts/python/export-to-postgresql.py | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/tools/perf/scripts/python/export-to-postgresql.py
++++ b/tools/perf/scripts/python/export-to-postgresql.py
+@@ -204,14 +204,23 @@ from ctypes import *
+ libpq = CDLL("libpq.so.5")
+ PQconnectdb = libpq.PQconnectdb
+ PQconnectdb.restype = c_void_p
++PQconnectdb.argtypes = [ c_char_p ]
+ PQfinish = libpq.PQfinish
++PQfinish.argtypes = [ c_void_p ]
+ PQstatus = libpq.PQstatus
++PQstatus.restype = c_int
++PQstatus.argtypes = [ c_void_p ]
+ PQexec = libpq.PQexec
+ PQexec.restype = c_void_p
++PQexec.argtypes = [ c_void_p, c_char_p ]
+ PQresultStatus = libpq.PQresultStatus
++PQresultStatus.restype = c_int
++PQresultStatus.argtypes = [ c_void_p ]
+ PQputCopyData = libpq.PQputCopyData
++PQputCopyData.restype = c_int
+ PQputCopyData.argtypes = [ c_void_p, c_void_p, c_int ]
+ PQputCopyEnd = libpq.PQputCopyEnd
++PQputCopyEnd.restype = c_int
+ PQputCopyEnd.argtypes = [ c_void_p, c_void_p ]
+
+ sys.path.append(os.environ['PERF_EXEC_PATH'] + \
--- /dev/null
+From d005efe18db0b4a123dd92ea8e77e27aee8f99fd Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Tue, 11 Sep 2018 14:45:04 +0300
+Subject: perf script python: Fix export-to-sqlite.py sample columns
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit d005efe18db0b4a123dd92ea8e77e27aee8f99fd upstream.
+
+With the "branches" export option, not all sample columns are exported.
+However the unwanted columns are not at the end of the tuple, as assumed
+by the code. Fix by taking the first 15 and last 3 values, instead of
+the first 18.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/20180911114504.28516-3-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/scripts/python/export-to-sqlite.py | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/scripts/python/export-to-sqlite.py
++++ b/tools/perf/scripts/python/export-to-sqlite.py
+@@ -440,7 +440,11 @@ def branch_type_table(*x):
+
+ def sample_table(*x):
+ if branches:
+- bind_exec(sample_query, 18, x)
++ for xx in x[0:15]:
++ sample_query.addBindValue(str(xx))
++ for xx in x[19:22]:
++ sample_query.addBindValue(str(xx))
++ do_query_(sample_query)
+ else:
+ bind_exec(sample_query, 22, x)
+
--- /dev/null
+From f259f896f2348f0302f6f88d4382378cf9d23a7e Mon Sep 17 00:00:00 2001
+From: Marco Felsch <m.felsch@pengutronix.de>
+Date: Tue, 2 Oct 2018 10:06:46 +0200
+Subject: pinctrl: mcp23s08: fix irq and irqchip setup order
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marco Felsch <m.felsch@pengutronix.de>
+
+commit f259f896f2348f0302f6f88d4382378cf9d23a7e upstream.
+
+Since 'commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' the
+irq request isn't the last devm_* allocation. Without a deeper look at
+the irq and testing this isn't a good solution. Since this driver relies
+on the devm mechanism, requesting a interrupt should be the last thing
+to avoid memory corruptions during unbinding.
+
+'Commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' fixed the
+order for the interrupt-controller use case only. The
+mcp23s08_irq_setup() must be split into two to fix it for the
+interrupt-controller use case and to register the irq at last. So the
+irq will be freed first during unbind.
+
+Cc: stable@vger.kernel.org
+Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
+Cc: Dmitry Mastykin <mastichi@gmail.com>
+Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
+Fixes: 82039d244f87 ("pinctrl: mcp23s08: add pinconf support")
+Fixes: 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")
+Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
+Tested-by: Phil Reid <preid@electromag.com.au>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-mcp23s08.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+--- a/drivers/pinctrl/pinctrl-mcp23s08.c
++++ b/drivers/pinctrl/pinctrl-mcp23s08.c
+@@ -636,6 +636,14 @@ static int mcp23s08_irq_setup(struct mcp
+ return err;
+ }
+
++ return 0;
++}
++
++static int mcp23s08_irqchip_setup(struct mcp23s08 *mcp)
++{
++ struct gpio_chip *chip = &mcp->chip;
++ int err;
++
+ err = gpiochip_irqchip_add_nested(chip,
+ &mcp23s08_irq_chip,
+ 0,
+@@ -912,7 +920,7 @@ static int mcp23s08_probe_one(struct mcp
+ }
+
+ if (mcp->irq && mcp->irq_controller) {
+- ret = mcp23s08_irq_setup(mcp);
++ ret = mcp23s08_irqchip_setup(mcp);
+ if (ret)
+ goto fail;
+ }
+@@ -944,6 +952,9 @@ static int mcp23s08_probe_one(struct mcp
+ goto fail;
+ }
+
++ if (mcp->irq)
++ ret = mcp23s08_irq_setup(mcp);
++
+ fail:
+ if (ret < 0)
+ dev_dbg(dev, "can't setup chip %d, --> %d\n", addr, ret);
--- /dev/null
+From 24abf2901b18bf941b9f21ea2ce5791f61097ae4 Mon Sep 17 00:00:00 2001
+From: Eric Farman <farman@linux.ibm.com>
+Date: Tue, 2 Oct 2018 03:02:35 +0200
+Subject: s390/cio: Fix how vfio-ccw checks pinned pages
+
+From: Eric Farman <farman@linux.ibm.com>
+
+commit 24abf2901b18bf941b9f21ea2ce5791f61097ae4 upstream.
+
+We have two nested loops to check the entries within the pfn_array_table
+arrays. But we mistakenly use the outer array as an index in our check,
+and completely ignore the indexing performed by the inner loop.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Farman <farman@linux.ibm.com>
+Message-Id: <20181002010235.42483-1-farman@linux.ibm.com>
+Signed-off-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/cio/vfio_ccw_cp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/s390/cio/vfio_ccw_cp.c
++++ b/drivers/s390/cio/vfio_ccw_cp.c
+@@ -163,7 +163,7 @@ static bool pfn_array_table_iova_pinned(
+
+ for (i = 0; i < pat->pat_nr; i++, pa++)
+ for (j = 0; j < pa->pa_nr; j++)
+- if (pa->pa_iova_pfn[i] == iova_pfn)
++ if (pa->pa_iova_pfn[j] == iova_pfn)
+ return true;
+
+ return false;
drm-amdkfd-change-the-control-stack-mtype-from-uc-to-nc-on-gfx9.patch
drm-amdkfd-fix-ats-capablity-was-not-reported-correctly-on-some-apus.patch
mm-slowly-shrink-slabs-with-a-relatively-small-number-of-objects.patch
+mm-vmstat.c-fix-outdated-vmstat_text.patch
+afs-fix-afs_server-struct-leak.patch
+afs-fix-clearance-of-reply.patch
+mips-fix-config_cmdline-handling.patch
+mips-vdso-always-map-near-top-of-user-memory.patch
+mach64-detect-the-dot-clock-divider-correctly-on-sparc.patch
+vsprintf-fix-off-by-one-bug-in-bstr_printf-processing-dereferenced-pointers.patch
+percpu-stop-leaking-bitmap-metadata-blocks.patch
+perf-script-python-fix-export-to-postgresql.py-occasional-failure.patch
+perf-script-python-fix-export-to-sqlite.py-sample-columns.patch
+s390-cio-fix-how-vfio-ccw-checks-pinned-pages.patch
+dm-cache-destroy-migration_cache-if-cache-target-registration-failed.patch
+dm-fix-report-zone-remapping-to-account-for-partition-offset.patch
+dm-linear-eliminate-linear_end_io-call-if-config_dm_zoned-disabled.patch
+dm-linear-fix-linear_end_io-conditional-definition.patch
+cgroup-fix-dom_cgrp-propagation-when-enabling-threaded-mode.patch
+input-xpad-add-support-for-xbox1-pdp-camo-series-gamepad.patch
+drm-nouveau-drm-nouveau-grab-runtime-pm-ref-in-nv50_mstc_detect.patch
+mmc-block-avoid-multiblock-reads-for-the-last-sector-in-spi-mode.patch
+pinctrl-mcp23s08-fix-irq-and-irqchip-setup-order.patch
+arm64-perf-reject-stand-alone-chain-events-for-pmuv3.patch
+mm-mmap.c-don-t-clobber-partially-overlapping-vma-with-map_fixed_noreplace.patch
+mm-thp-fix-call-to-mmu_notifier-in-set_pmd_migration_entry-v2.patch
+filesystem-dax-fix-dax_layout_busy_page-livelock.patch
+mm-preserve-_page_devmap-across-mprotect-calls.patch
--- /dev/null
+From 62165600ae73ebd76e2d9b992b36360408d570d8 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Fri, 5 Oct 2018 10:08:03 -0400
+Subject: vsprintf: Fix off-by-one bug in bstr_printf() processing dereferenced pointers
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 62165600ae73ebd76e2d9b992b36360408d570d8 upstream.
+
+The functions vbin_printf() and bstr_printf() are used by trace_printk() to
+try to keep the overhead down during printing. trace_printk() uses
+vbin_printf() at the time of execution, as it only scans the fmt string to
+record the printf values into the buffer, and then uses vbin_printf() to do
+the conversions to print the string based on the format and the saved
+values in the buffer.
+
+This is an issue for dereferenced pointers, as before commit 841a915d20c7b,
+the processing of the pointer could happen some time after the pointer value
+was recorded (reading the trace buffer). This means the processing of the
+value at a later time could show different results, or even crash the
+system, if the pointer no longer existed.
+
+Commit 841a915d20c7b addressed this by processing dereferenced pointers at
+the time of execution and save the result in the ring buffer as a string.
+The bstr_printf() would then treat these pointers as normal strings, and
+print the value. But there was an off-by-one bug here, where after
+processing the argument, it move the pointer only "strlen(arg)" which made
+the arg pointer not point to the next argument in the ring buffer, but
+instead point to the nul character of the last argument. This causes any
+values after a dereferenced pointer to be corrupted.
+
+Cc: stable@vger.kernel.org
+Fixes: 841a915d20c7b ("vsprintf: Do not have bprintf dereference pointers")
+Reported-by: Nikolay Borisov <nborisov@suse.com>
+Tested-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ lib/vsprintf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/lib/vsprintf.c
++++ b/lib/vsprintf.c
+@@ -2769,7 +2769,7 @@ int bstr_printf(char *buf, size_t size,
+ copy = end - str;
+ memcpy(str, args, copy);
+ str += len;
+- args += len;
++ args += len + 1;
+ }
+ }
+ if (process)
projects / thirdparty / kernel / stable-queue.git / commitdiff
