--- /dev/null
+From 3bec9bf29ced572cfcdac4f9d285e75d3f17d8a7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 27 Oct 2020 21:49:01 +0800
+Subject: ACPI: NFIT: Fix comparison to '-ENXIO'
+
+From: Zhang Qilong <zhangqilong3@huawei.com>
+
+[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ]
+
+Initial value of rc is '-ENXIO', and we should
+use the initial value to check it.
+
+Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
+Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
+Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
+[ rjw: Subject edit ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/nfit/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
+index 68205002f561e..20fd197ef74cc 100644
+--- a/drivers/acpi/nfit/core.c
++++ b/drivers/acpi/nfit/core.c
+@@ -1273,7 +1273,7 @@ static ssize_t format1_show(struct device *dev,
+ le16_to_cpu(nfit_dcr->dcr->code));
+ break;
+ }
+- if (rc != ENXIO)
++ if (rc != -ENXIO)
+ break;
+ }
+ mutex_unlock(&acpi_desc->init_mutex);
+--
+2.27.0
+
--- /dev/null
+From bf04fc5873f36f5c76d6a79fdc484b130a1e7e98 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 3 Oct 2020 12:03:32 +0200
+Subject: ARM: dts: sun4i-a10: fix cpu_alert temperature
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Clément Péron <peron.clem@gmail.com>
+
+[ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ]
+
+When running dtbs_check thermal_zone warn about the
+temperature declared.
+
+thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000
+
+It's indeed wrong the real value is 85°C and not 850°C.
+
+Signed-off-by: Clément Péron <peron.clem@gmail.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
+index 41c2579143fd6..b3a3488fdfd68 100644
+--- a/arch/arm/boot/dts/sun4i-a10.dtsi
++++ b/arch/arm/boot/dts/sun4i-a10.dtsi
+@@ -143,7 +143,7 @@
+ trips {
+ cpu_alert0: cpu_alert0 {
+ /* milliCelsius */
+- temperature = <850000>;
++ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+--
+2.27.0
+
--- /dev/null
+From 774b2fbafc52e868be9b32997e7cf230f10e6ae8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 16:58:41 -0400
+Subject: blk-cgroup: Fix memleak on error path
+
+From: Gabriel Krisman Bertazi <krisman@collabora.com>
+
+[ Upstream commit 52abfcbd57eefdd54737fc8c2dc79d8f46d4a3e5 ]
+
+If new_blkg allocation raced with blk_policy change and
+blkg_lookup_check fails, new_blkg is leaked.
+
+Acked-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-cgroup.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
+index 3dc7c0b4adcbb..a7217caea699d 100644
+--- a/block/blk-cgroup.c
++++ b/block/blk-cgroup.c
+@@ -878,6 +878,7 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol,
+ blkg = blkg_lookup_check(pos, pol, q);
+ if (IS_ERR(blkg)) {
+ ret = PTR_ERR(blkg);
++ blkg_free(new_blkg);
+ goto fail_unlock;
+ }
+
+--
+2.27.0
+
--- /dev/null
+From 15d5f9f04753e207cfc06c0c260c09d51df4dbad Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 16:58:42 -0400
+Subject: blk-cgroup: Pre-allocate tree node on blkg_conf_prep
+
+From: Gabriel Krisman Bertazi <krisman@collabora.com>
+
+[ Upstream commit f255c19b3ab46d3cad3b1b2e1036f4c926cb1d0c ]
+
+Similarly to commit 457e490f2b741 ("blkcg: allocate struct blkcg_gq
+outside request queue spinlock"), blkg_create can also trigger
+occasional -ENOMEM failures at the radix insertion because any
+allocation inside blkg_create has to be non-blocking, making it more
+likely to fail. This causes trouble for userspace tools trying to
+configure io weights who need to deal with this condition.
+
+This patch reduces the occurrence of -ENOMEMs on this path by preloading
+the radix tree element on a GFP_KERNEL context, such that we guarantee
+the later non-blocking insertion won't fail.
+
+A similar solution exists in blkcg_init_queue for the same situation.
+
+Acked-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-cgroup.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
+index a7217caea699d..34f8e69078cc1 100644
+--- a/block/blk-cgroup.c
++++ b/block/blk-cgroup.c
+@@ -872,6 +872,12 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol,
+ goto fail;
+ }
+
++ if (radix_tree_preload(GFP_KERNEL)) {
++ blkg_free(new_blkg);
++ ret = -ENOMEM;
++ goto fail;
++ }
++
+ rcu_read_lock();
+ spin_lock_irq(q->queue_lock);
+
+@@ -879,7 +885,7 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol,
+ if (IS_ERR(blkg)) {
+ ret = PTR_ERR(blkg);
+ blkg_free(new_blkg);
+- goto fail_unlock;
++ goto fail_preloaded;
+ }
+
+ if (blkg) {
+@@ -888,10 +894,12 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol,
+ blkg = blkg_create(pos, q, new_blkg);
+ if (unlikely(IS_ERR(blkg))) {
+ ret = PTR_ERR(blkg);
+- goto fail_unlock;
++ goto fail_preloaded;
+ }
+ }
+
++ radix_tree_preload_end();
++
+ if (pos == blkcg)
+ goto success;
+ }
+@@ -901,6 +909,8 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol,
+ ctx->body = body;
+ return 0;
+
++fail_preloaded:
++ radix_tree_preload_end();
+ fail_unlock:
+ spin_unlock_irq(q->queue_lock);
+ rcu_read_unlock();
+--
+2.27.0
+
--- /dev/null
+From 55b443c3ecacca7bf1d22f4b728ffcf65d613d0a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 27 Oct 2020 13:14:42 +0900
+Subject: drm/vc4: drv: Add error handding for bind
+
+From: Hoegeun Kwon <hoegeun.kwon@samsung.com>
+
+[ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ]
+
+There is a problem that if vc4_drm bind fails, a memory leak occurs on
+the drm_property_create side. Add error handding for drm_mode_config.
+
+Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/vc4/vc4_drv.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
+index 1c96edcb302be..028dc2819a368 100644
+--- a/drivers/gpu/drm/vc4/vc4_drv.c
++++ b/drivers/gpu/drm/vc4/vc4_drv.c
+@@ -283,6 +283,7 @@ static int vc4_drm_bind(struct device *dev)
+ component_unbind_all(dev, drm);
+ gem_destroy:
+ vc4_gem_destroy(drm);
++ drm_mode_config_cleanup(drm);
+ vc4_bo_cache_destroy(drm);
+ dev_unref:
+ drm_dev_unref(drm);
+--
+2.27.0
+
--- /dev/null
+From 3d19bdec779c3c21fa1c6662a1bac2b85b0a8aa5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 25 Oct 2020 19:51:24 +0800
+Subject: nvme-rdma: handle unexpected nvme completion data length
+
+From: zhenwei pi <pizhenwei@bytedance.com>
+
+[ Upstream commit 25c1ca6ecaba3b751d3f7ff92d5cddff3b05f8d0 ]
+
+Receiving a zero length message leads to the following warnings because
+the CQE is processed twice:
+
+refcount_t: underflow; use-after-free.
+WARNING: CPU: 0 PID: 0 at lib/refcount.c:28
+
+RIP: 0010:refcount_warn_saturate+0xd9/0xe0
+Call Trace:
+ <IRQ>
+ nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma]
+ __ib_process_cq+0x76/0x150 [ib_core]
+ ...
+
+Sanity check the received data length, to avoids this.
+
+Thanks to Chao Leng & Sagi for suggestions.
+
+Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/rdma.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
+index 564e457f1345e..d04c9769ebfa2 100644
+--- a/drivers/nvme/host/rdma.c
++++ b/drivers/nvme/host/rdma.c
+@@ -1382,6 +1382,14 @@ static int __nvme_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc, int tag)
+ return 0;
+ }
+
++ /* sanity checking for received data length */
++ if (unlikely(wc->byte_len < len)) {
++ dev_err(queue->ctrl->ctrl.device,
++ "Unexpected nvme completion length(%d)\n", wc->byte_len);
++ nvme_rdma_error_recovery(queue->ctrl);
++ return;
++ }
++
+ ib_dma_sync_single_for_cpu(ibdev, qe->dma, len, DMA_FROM_DEVICE);
+ /*
+ * AEN requests are special as they don't time out and can
+--
+2.27.0
+
--- /dev/null
+From 52411fa7afcace155145bd008d673ea69ee331cc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 21 Oct 2020 11:53:59 +0200
+Subject: of: Fix reserved-memory overlap detection
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ Upstream commit ca05f33316559a04867295dd49f85aeedbfd6bfd ]
+
+The reserved-memory overlap detection code fails to detect overlaps if
+either of the regions starts at address 0x0. The code explicitly checks
+for and ignores such regions, apparently in order to ignore dynamically
+allocated regions which have an address of 0x0 at this point. These
+dynamically allocated regions also have a size of 0x0 at this point, so
+fix this by removing the check and sorting the dynamically allocated
+regions ahead of any static regions at address 0x0.
+
+For example, there are two overlaps in this case but they are not
+currently reported:
+
+ foo@0 {
+ reg = <0x0 0x2000>;
+ };
+
+ bar@0 {
+ reg = <0x0 0x1000>;
+ };
+
+ baz@1000 {
+ reg = <0x1000 0x1000>;
+ };
+
+ quux {
+ size = <0x1000>;
+ };
+
+but they are after this patch:
+
+ OF: reserved mem: OVERLAP DETECTED!
+ bar@0 (0x00000000--0x00001000) overlaps with foo@0 (0x00000000--0x00002000)
+ OF: reserved mem: OVERLAP DETECTED!
+ foo@0 (0x00000000--0x00002000) overlaps with baz@1000 (0x00001000--0x00002000)
+
+Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/of/of_reserved_mem.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
+index 32771c2ced7bb..55cbafdb93aef 100644
+--- a/drivers/of/of_reserved_mem.c
++++ b/drivers/of/of_reserved_mem.c
+@@ -222,6 +222,16 @@ static int __init __rmem_cmp(const void *a, const void *b)
+ if (ra->base > rb->base)
+ return 1;
+
++ /*
++ * Put the dynamic allocations (address == 0, size == 0) before static
++ * allocations at address 0x0 so that overlap detection works
++ * correctly.
++ */
++ if (ra->size < rb->size)
++ return -1;
++ if (ra->size > rb->size)
++ return 1;
++
+ return 0;
+ }
+
+@@ -239,8 +249,7 @@ static void __init __rmem_check_for_overlap(void)
+
+ this = &reserved_mem[i];
+ next = &reserved_mem[i + 1];
+- if (!(this->base && next->base))
+- continue;
++
+ if (this->base + this->size > next->base) {
+ phys_addr_t this_end, next_end;
+
+--
+2.27.0
+
--- /dev/null
+From b961fc34a96fc44f2cb41f1bb9c5f5640fdbd520 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 10 Oct 2020 11:25:39 +0800
+Subject: scsi: core: Don't start concurrent async scan on same host
+
+From: Ming Lei <ming.lei@redhat.com>
+
+[ Upstream commit 831e3405c2a344018a18fcc2665acc5a38c3a707 ]
+
+The current scanning mechanism is supposed to fall back to a synchronous
+host scan if an asynchronous scan is in progress. However, this rule isn't
+strictly respected, scsi_prep_async_scan() doesn't hold scan_mutex when
+checking shost->async_scan. When scsi_scan_host() is called concurrently,
+two async scans on same host can be started and a hang in do_scan_async()
+is observed.
+
+Fixes this issue by checking & setting shost->async_scan atomically with
+shost->scan_mutex.
+
+Link: https://lore.kernel.org/r/20201010032539.426615-1-ming.lei@redhat.com
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Ewan D. Milne <emilne@redhat.com>
+Cc: Hannes Reinecke <hare@suse.de>
+Cc: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Lee Duncan <lduncan@suse.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/scsi_scan.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
+index 0b11405bfd7ea..40acc060b6558 100644
+--- a/drivers/scsi/scsi_scan.c
++++ b/drivers/scsi/scsi_scan.c
+@@ -1720,15 +1720,16 @@ static void scsi_sysfs_add_devices(struct Scsi_Host *shost)
+ */
+ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
+ {
+- struct async_scan_data *data;
++ struct async_scan_data *data = NULL;
+ unsigned long flags;
+
+ if (strncmp(scsi_scan_type, "sync", 4) == 0)
+ return NULL;
+
++ mutex_lock(&shost->scan_mutex);
+ if (shost->async_scan) {
+ shost_printk(KERN_DEBUG, shost, "%s called twice\n", __func__);
+- return NULL;
++ goto err;
+ }
+
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+@@ -1739,7 +1740,6 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
+ goto err;
+ init_completion(&data->prev_finished);
+
+- mutex_lock(&shost->scan_mutex);
+ spin_lock_irqsave(shost->host_lock, flags);
+ shost->async_scan = 1;
+ spin_unlock_irqrestore(shost->host_lock, flags);
+@@ -1754,6 +1754,7 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost)
+ return data;
+
+ err:
++ mutex_unlock(&shost->scan_mutex);
+ kfree(data);
+ return NULL;
+ }
+--
+2.27.0
+
ftrace-handle-tracing-when-switching-between-context.patch
tracing-fix-out-of-bounds-write-in-get_trace_buf.patch
futex-handle-transient-ownerless-rtmutex-state-correctly.patch
+arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch
+x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch
+of-fix-reserved-memory-overlap-detection.patch
+blk-cgroup-fix-memleak-on-error-path.patch
+blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch
+scsi-core-don-t-start-concurrent-async-scan-on-same-.patch
+vsock-use-ns_capable_noaudit-on-socket-create.patch
+nvme-rdma-handle-unexpected-nvme-completion-data-len.patch
+drm-vc4-drv-add-error-handding-for-bind.patch
+acpi-nfit-fix-comparison-to-enxio.patch
--- /dev/null
+From 6edf9145cdbc9bcff2174e3054dd4497fa2024ee Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 23 Oct 2020 16:37:57 +0200
+Subject: vsock: use ns_capable_noaudit() on socket create
+
+From: Jeff Vander Stoep <jeffv@google.com>
+
+[ Upstream commit af545bb5ee53f5261db631db2ac4cde54038bdaf ]
+
+During __vsock_create() CAP_NET_ADMIN is used to determine if the
+vsock_sock->trusted should be set to true. This value is used later
+for determing if a remote connection should be allowed to connect
+to a restricted VM. Unfortunately, if the caller doesn't have
+CAP_NET_ADMIN, an audit message such as an selinux denial is
+generated even if the caller does not want a trusted socket.
+
+Logging errors on success is confusing. To avoid this, switch the
+capable(CAP_NET_ADMIN) check to the noaudit version.
+
+Reported-by: Roman Kiryanov <rkir@google.com>
+https://android-review.googlesource.com/c/device/generic/goldfish/+/1468545/
+Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
+Reviewed-by: James Morris <jamorris@linux.microsoft.com>
+Link: https://lore.kernel.org/r/20201023143757.377574-1-jeffv@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/vmw_vsock/af_vsock.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
+index f297a427b421b..29f7491acb354 100644
+--- a/net/vmw_vsock/af_vsock.c
++++ b/net/vmw_vsock/af_vsock.c
+@@ -636,7 +636,7 @@ struct sock *__vsock_create(struct net *net,
+ vsk->owner = get_cred(psk->owner);
+ vsk->connect_timeout = psk->connect_timeout;
+ } else {
+- vsk->trusted = capable(CAP_NET_ADMIN);
++ vsk->trusted = ns_capable_noaudit(&init_user_ns, CAP_NET_ADMIN);
+ vsk->owner = get_current_cred();
+ vsk->connect_timeout = VSOCK_DEFAULT_CONNECT_TIMEOUT;
+ }
+--
+2.27.0
+
--- /dev/null
+From a6f66e425e2587598ecac85ab45834c4a7db9648 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Oct 2020 17:24:28 +0800
+Subject: x86/kexec: Use up-to-dated screen_info copy to fill boot params
+
+From: Kairui Song <kasong@redhat.com>
+
+[ Upstream commit afc18069a2cb7ead5f86623a5f3d4ad6e21f940d ]
+
+kexec_file_load() currently reuses the old boot_params.screen_info,
+but if drivers have change the hardware state, boot_param.screen_info
+could contain invalid info.
+
+For example, the video type might be no longer VGA, or the frame buffer
+address might be changed. If the kexec kernel keeps using the old screen_info,
+kexec'ed kernel may attempt to write to an invalid framebuffer
+memory region.
+
+There are two screen_info instances globally available, boot_params.screen_info
+and screen_info. Later one is a copy, and is updated by drivers.
+
+So let kexec_file_load use the updated copy.
+
+[ mingo: Tidied up the changelog. ]
+
+Signed-off-by: Kairui Song <kasong@redhat.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Link: https://lore.kernel.org/r/20201014092429.1415040-2-kasong@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kernel/kexec-bzimage64.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
+index 4d948d87f01cc..a65636d60296c 100644
+--- a/arch/x86/kernel/kexec-bzimage64.c
++++ b/arch/x86/kernel/kexec-bzimage64.c
+@@ -211,8 +211,7 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
+ params->hdr.hardware_subarch = boot_params.hdr.hardware_subarch;
+
+ /* Copying screen_info will do? */
+- memcpy(¶ms->screen_info, &boot_params.screen_info,
+- sizeof(struct screen_info));
++ memcpy(¶ms->screen_info, &screen_info, sizeof(struct screen_info));
+
+ /* Fill in memsize later */
+ params->screen_info.ext_mem_k = 0;
+--
+2.27.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
