]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.4
authorSasha Levin <sashal@kernel.org>
Sun, 8 Nov 2020 23:14:04 +0000 (18:14 -0500)
committerSasha Levin <sashal@kernel.org>
Sun, 8 Nov 2020 23:16:45 +0000 (18:16 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.4/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch [new file with mode: 0644]
queue-4.4/of-fix-reserved-memory-overlap-detection.patch [new file with mode: 0644]
queue-4.4/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch [new file with mode: 0644]
queue-4.4/series
queue-4.4/vsock-use-ns_capable_noaudit-on-socket-create.patch [new file with mode: 0644]
queue-4.4/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch [new file with mode: 0644]

diff --git a/queue-4.4/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch b/queue-4.4/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch
new file mode 100644 (file)
index 0000000..8e82ba7
--- /dev/null
@@ -0,0 +1,43 @@
+From f015c0794d5e71d882af85f7423d2511cc22a669 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 aa90f319309ba..b8bbc8c187994 100644
+--- a/arch/arm/boot/dts/sun4i-a10.dtsi
++++ b/arch/arm/boot/dts/sun4i-a10.dtsi
+@@ -137,7 +137,7 @@
+                       trips {
+                               cpu_alert0: cpu_alert0 {
+                                       /* milliCelsius */
+-                                      temperature = <850000>;
++                                      temperature = <85000>;
+                                       hysteresis = <2000>;
+                                       type = "passive";
+                               };
+-- 
+2.27.0
+
diff --git a/queue-4.4/of-fix-reserved-memory-overlap-detection.patch b/queue-4.4/of-fix-reserved-memory-overlap-detection.patch
new file mode 100644 (file)
index 0000000..90de114
--- /dev/null
@@ -0,0 +1,85 @@
+From 0bd0e7c3a50ecb56ff8156f022dd97653ce94ed1 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 07dd81586c52b..7ccf077c72a05 100644
+--- a/drivers/of/of_reserved_mem.c
++++ b/drivers/of/of_reserved_mem.c
+@@ -218,6 +218,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;
+ }
+@@ -235,8 +245,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
+
diff --git a/queue-4.4/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch b/queue-4.4/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch
new file mode 100644 (file)
index 0000000..e881564
--- /dev/null
@@ -0,0 +1,75 @@
+From 37e622f8d48f2f678ba1bcf801fc74ce96898863 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 3e2288af56bc3..647a057a9b6cc 100644
+--- a/drivers/scsi/scsi_scan.c
++++ b/drivers/scsi/scsi_scan.c
+@@ -1710,15 +1710,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);
+@@ -1729,7 +1730,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);
+@@ -1744,6 +1744,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
+
index 4b9377d7e36598927b5089a4f9c6dc41896edecd..e4bee3a821d2c6b03a1cb460f3313afa1224a355 100644 (file)
@@ -69,3 +69,8 @@ fonts-replace-discarded-const-qualifier.patch
 alsa-usb-audio-add-implicit-feedback-quirk-for-qu-16.patch
 ftrace-fix-recursion-check-for-nmi-test.patch
 ftrace-handle-tracing-when-switching-between-context.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
+scsi-core-don-t-start-concurrent-async-scan-on-same-.patch
+vsock-use-ns_capable_noaudit-on-socket-create.patch
diff --git a/queue-4.4/vsock-use-ns_capable_noaudit-on-socket-create.patch b/queue-4.4/vsock-use-ns_capable_noaudit-on-socket-create.patch
new file mode 100644 (file)
index 0000000..4e13642
--- /dev/null
@@ -0,0 +1,46 @@
+From 770a069ec0d20a1909d0f5000b3c62d2b310212b 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 a645352e366aa..07b1a2775210b 100644
+--- a/net/vmw_vsock/af_vsock.c
++++ b/net/vmw_vsock/af_vsock.c
+@@ -633,7 +633,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
+
diff --git a/queue-4.4/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch b/queue-4.4/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch
new file mode 100644 (file)
index 0000000..25bba5e
--- /dev/null
@@ -0,0 +1,50 @@
+From 4caf81a3b198bee1f672fef78d3c84ddaa789b95 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 0bf17576dd2af..299e7fb55f16e 100644
+--- a/arch/x86/kernel/kexec-bzimage64.c
++++ b/arch/x86/kernel/kexec-bzimage64.c
+@@ -212,8 +212,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(&params->screen_info, &boot_params.screen_info,
+-                              sizeof(struct screen_info));
++      memcpy(&params->screen_info, &screen_info, sizeof(struct screen_info));
+       /* Fill in memsize later */
+       params->screen_info.ext_mem_k = 0;
+-- 
+2.27.0
+