* [PATCH for 5.4] Fix unsynchronized access to sev members through svm_register_enc_region
From: Peter Gonda @ 2021-02-08 16:48 UTC (permalink / raw)
To: stable
Cc: Peter Gonda, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Joerg Roedel, Tom Lendacky, Brijesh Singh,
Sean Christopherson, x86, kvm, linux-kernel
commit 19a23da53932bc8011220bd8c410cb76012de004 upstream.
Grab kvm->lock before pinning memory when registering an encrypted
region; sev_pin_memory() relies on kvm->lock being held to ensure
correctness when checking and updating the number of pinned pages.
Add a lockdep assertion to help prevent future regressions.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active")
Signed-off-by: Peter Gonda <pgonda@google.com>
V2
- Fix up patch description
- Correct file paths svm.c -> sev.c
- Add unlock of kvm->lock on sev_pin_memory error
V1
- https://lore.kernel.org/kvm/20210126185431.1824530-1-pgonda@google.com/
Message-Id: <20210127161524.2832400-1-pgonda@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/svm.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 2b506904be02..93c89f1ffc5d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1830,6 +1830,8 @@ static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
struct page **pages;
unsigned long first, last;
+ lockdep_assert_held(&kvm->lock);
+
if (ulen == 0 || uaddr + ulen < uaddr)
return NULL;
@@ -7086,12 +7088,21 @@ static int svm_register_enc_region(struct kvm *kvm,
if (!region)
return -ENOMEM;
+ mutex_lock(&kvm->lock);
region->pages = sev_pin_memory(kvm, range->addr, range->size, ®ion->npages, 1);
if (!region->pages) {
ret = -ENOMEM;
+ mutex_unlock(&kvm->lock);
goto e_free;
}
+ region->uaddr = range->addr;
+ region->size = range->size;
+
+ mutex_lock(&kvm->lock);
+ list_add_tail(®ion->list, &sev->regions_list);
+ mutex_unlock(&kvm->lock);
+
/*
* The guest may change the memory encryption attribute from C=0 -> C=1
* or vice versa for this memory range. Lets make sure caches are
@@ -7100,13 +7111,6 @@ static int svm_register_enc_region(struct kvm *kvm,
*/
sev_clflush_pages(region->pages, region->npages);
- region->uaddr = range->addr;
- region->size = range->size;
-
- mutex_lock(&kvm->lock);
- list_add_tail(®ion->list, &sev->regions_list);
- mutex_unlock(&kvm->lock);
-
return ret;
e_free:
--
2.30.0.478.g8a0d178c01-goog
^ permalink raw reply related
* [PATCH for 4.19] Fix unsynchronized access to sev members through svm_register_enc_region
From: Peter Gonda @ 2021-02-08 16:48 UTC (permalink / raw)
To: stable
Cc: Peter Gonda, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Paolo Bonzini, Joerg Roedel, Tom Lendacky, Brijesh Singh,
Sean Christopherson, x86, kvm, linux-kernel
commit 19a23da53932bc8011220bd8c410cb76012de004 upstream.
Grab kvm->lock before pinning memory when registering an encrypted
region; sev_pin_memory() relies on kvm->lock being held to ensure
correctness when checking and updating the number of pinned pages.
Add a lockdep assertion to help prevent future regressions.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active")
Signed-off-by: Peter Gonda <pgonda@google.com>
V2
- Fix up patch description
- Correct file paths svm.c -> sev.c
- Add unlock of kvm->lock on sev_pin_memory error
V1
- https://lore.kernel.org/kvm/20210126185431.1824530-1-pgonda@google.com/
Message-Id: <20210127161524.2832400-1-pgonda@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/svm.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 2b506904be02..93c89f1ffc5d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1830,6 +1830,8 @@ static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
struct page **pages;
unsigned long first, last;
+ lockdep_assert_held(&kvm->lock);
+
if (ulen == 0 || uaddr + ulen < uaddr)
return NULL;
@@ -7086,12 +7088,21 @@ static int svm_register_enc_region(struct kvm *kvm,
if (!region)
return -ENOMEM;
+ mutex_lock(&kvm->lock);
region->pages = sev_pin_memory(kvm, range->addr, range->size, ®ion->npages, 1);
if (!region->pages) {
ret = -ENOMEM;
+ mutex_unlock(&kvm->lock);
goto e_free;
}
+ region->uaddr = range->addr;
+ region->size = range->size;
+
+ mutex_lock(&kvm->lock);
+ list_add_tail(®ion->list, &sev->regions_list);
+ mutex_unlock(&kvm->lock);
+
/*
* The guest may change the memory encryption attribute from C=0 -> C=1
* or vice versa for this memory range. Lets make sure caches are
@@ -7100,13 +7111,6 @@ static int svm_register_enc_region(struct kvm *kvm,
*/
sev_clflush_pages(region->pages, region->npages);
- region->uaddr = range->addr;
- region->size = range->size;
-
- mutex_lock(&kvm->lock);
- list_add_tail(®ion->list, &sev->regions_list);
- mutex_unlock(&kvm->lock);
-
return ret;
e_free:
--
2.30.0.478.g8a0d178c01-goog
^ permalink raw reply related
* Re: Linux 4.9.256
From: Greg Kroah-Hartman @ 2021-02-08 16:31 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-kernel, akpm, torvalds, stable, lwn, jslaby
In-Reply-To: <23a28990-c465-f813-52a4-f7f3db007f9d@scylladb.com>
On Mon, Feb 08, 2021 at 05:50:21PM +0200, Avi Kivity wrote:
> On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
> > I'm announcing the release of the 4.9.256 kernel.
> >
> > This, and the 4.4.256 release are a little bit "different" than normal.
> >
> > This contains only 1 patch, just the version bump from .255 to .256 which ends
> > up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> > than normal due to the "overflow".
> >
> > With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
>
>
> I think this is a bad idea. Many kernel features can only be discovered by
> checking the kernel version. If a feature was introduced in 4.10, then an
> application can be tricked into thinking a 4.9 kernel has it.
>
>
> IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a
> LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel.
We are going to stop LINUX_VERSION_CODE at 255 now, see the posted
patches from Sasha, I think we are now ok.
thanks,
greg k-h
^ permalink raw reply
* Re: FAILED: patch "[PATCH] fgraph: Initialize tracing_graph_pause at task creation" failed to apply to 4.14-stable tree
From: Steven Rostedt @ 2021-02-08 16:25 UTC (permalink / raw)
To: gregkh; +Cc: stable
In-Reply-To: <161277913410730@kroah.com>
On Mon, 08 Feb 2021 11:12:14 +0100
<gregkh@linuxfoundation.org> wrote:
> The patch below does not apply to the 4.14-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> thanks,
>
> greg k-h
Here's the 4.14 port (should also work for 4.9 and 4.4):
------------------ original commit in Linus's tree ------------------
>From 7e0a9220467dbcfdc5bc62825724f3e52e50ab31 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Date: Fri, 29 Jan 2021 10:13:53 -0500
Subject: [PATCH] fgraph: Initialize tracing_graph_pause at task creation
On some archs, the idle task can call into cpu_suspend(). The cpu_suspend()
will disable or pause function graph tracing, as there's some paths in
bringing down the CPU that can have issues with its return address being
modified. The task_struct structure has a "tracing_graph_pause" atomic
counter, that when set to something other than zero, the function graph
tracer will not modify the return address.
The problem is that the tracing_graph_pause counter is initialized when the
function graph tracer is enabled. This can corrupt the counter for the idle
task if it is suspended in these architectures.
CPU 1 CPU 2
----- -----
do_idle()
cpu_suspend()
pause_graph_tracing()
task_struct->tracing_graph_pause++ (0 -> 1)
start_graph_tracing()
for_each_online_cpu(cpu) {
ftrace_graph_init_idle_task(cpu)
task-struct->tracing_graph_pause = 0 (1 -> 0)
unpause_graph_tracing()
task_struct->tracing_graph_pause-- (0 -> -1)
The above should have gone from 1 to zero, and enabled function graph
tracing again. But instead, it is set to -1, which keeps it disabled.
There's no reason that the field tracing_graph_pause on the task_struct can
not be initialized at boot up.
Cc: stable@vger.kernel.org
Fixes: 380c4b1411ccd ("tracing/function-graph-tracer: append the tracing_graph_flag")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211339
Reported-by: pierre.gondois@arm.com
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Index: linux-test.git/kernel/trace/ftrace.c
===================================================================
--- linux-test.git.orig/kernel/trace/ftrace.c
+++ linux-test.git/kernel/trace/ftrace.c
@@ -6666,7 +6666,6 @@ static int alloc_retstack_tasklist(struc
}
if (t->ret_stack == NULL) {
- atomic_set(&t->tracing_graph_pause, 0);
atomic_set(&t->trace_overrun, 0);
t->curr_ret_stack = -1;
/* Make sure the tasks see the -1 first: */
@@ -6878,7 +6877,6 @@ static DEFINE_PER_CPU(struct ftrace_ret_
static void
graph_init_task(struct task_struct *t, struct ftrace_ret_stack *ret_stack)
{
- atomic_set(&t->tracing_graph_pause, 0);
atomic_set(&t->trace_overrun, 0);
t->ftrace_timestamp = 0;
/* make curr_ret_stack visible before we add the ret_stack */
Index: linux-test.git/include/linux/ftrace.h
===================================================================
--- linux-test.git.orig/include/linux/ftrace.h
+++ linux-test.git/include/linux/ftrace.h
@@ -792,7 +792,9 @@ typedef int (*trace_func_graph_ent_t)(st
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
/* for init task */
-#define INIT_FTRACE_GRAPH .ret_stack = NULL,
+#define INIT_FTRACE_GRAPH \
+ .ret_stack = NULL, \
+ .tracing_graph_pause = ATOMIC_INIT(0),
/*
* Stack of return addresses for functions
^ permalink raw reply
* Re: FAILED: patch "[PATCH] fgraph: Initialize tracing_graph_pause at task creation" failed to apply to 4.19-stable tree
From: Steven Rostedt @ 2021-02-08 16:24 UTC (permalink / raw)
To: gregkh; +Cc: stable
In-Reply-To: <1612779135196131@kroah.com>
On Mon, 08 Feb 2021 11:12:15 +0100
<gregkh@linuxfoundation.org> wrote:
> The patch below does not apply to the 4.19-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> thanks,
>
> greg k-h
>
Here's the 4.19 port:
------------------ original commit in Linus's tree ------------------
>From 7e0a9220467dbcfdc5bc62825724f3e52e50ab31 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Date: Fri, 29 Jan 2021 10:13:53 -0500
Subject: [PATCH] fgraph: Initialize tracing_graph_pause at task creation
On some archs, the idle task can call into cpu_suspend(). The cpu_suspend()
will disable or pause function graph tracing, as there's some paths in
bringing down the CPU that can have issues with its return address being
modified. The task_struct structure has a "tracing_graph_pause" atomic
counter, that when set to something other than zero, the function graph
tracer will not modify the return address.
The problem is that the tracing_graph_pause counter is initialized when the
function graph tracer is enabled. This can corrupt the counter for the idle
task if it is suspended in these architectures.
CPU 1 CPU 2
----- -----
do_idle()
cpu_suspend()
pause_graph_tracing()
task_struct->tracing_graph_pause++ (0 -> 1)
start_graph_tracing()
for_each_online_cpu(cpu) {
ftrace_graph_init_idle_task(cpu)
task-struct->tracing_graph_pause = 0 (1 -> 0)
unpause_graph_tracing()
task_struct->tracing_graph_pause-- (0 -> -1)
The above should have gone from 1 to zero, and enabled function graph
tracing again. But instead, it is set to -1, which keeps it disabled.
There's no reason that the field tracing_graph_pause on the task_struct can
not be initialized at boot up.
Cc: stable@vger.kernel.org
Fixes: 380c4b1411ccd ("tracing/function-graph-tracer: append the tracing_graph_flag")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211339
Reported-by: pierre.gondois@arm.com
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Index: linux-test.git/init/init_task.c
===================================================================
--- linux-test.git.orig/init/init_task.c
+++ linux-test.git/init/init_task.c
@@ -168,7 +168,8 @@ struct task_struct init_task
.lockdep_recursion = 0,
#endif
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- .ret_stack = NULL,
+ .ret_stack = NULL,
+ .tracing_graph_pause = ATOMIC_INIT(0),
#endif
#if defined(CONFIG_TRACING) && defined(CONFIG_PREEMPT)
.trace_recursion = 0,
Index: linux-test.git/kernel/trace/ftrace.c
===================================================================
--- linux-test.git.orig/kernel/trace/ftrace.c
+++ linux-test.git/kernel/trace/ftrace.c
@@ -6875,7 +6875,6 @@ static int alloc_retstack_tasklist(struc
}
if (t->ret_stack == NULL) {
- atomic_set(&t->tracing_graph_pause, 0);
atomic_set(&t->trace_overrun, 0);
t->curr_ret_stack = -1;
t->curr_ret_depth = -1;
@@ -7088,7 +7087,6 @@ static DEFINE_PER_CPU(struct ftrace_ret_
static void
graph_init_task(struct task_struct *t, struct ftrace_ret_stack *ret_stack)
{
- atomic_set(&t->tracing_graph_pause, 0);
atomic_set(&t->trace_overrun, 0);
t->ftrace_timestamp = 0;
/* make curr_ret_stack visible before we add the ret_stack */
^ permalink raw reply
* stable-rc/queue/4.4 baseline: 110 runs, 12 regressions (v4.4.256-29-gd00804edfe40)
From: kernelci.org bot @ 2021-02-08 15:53 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/4.4 baseline: 110 runs, 12 regressions (v4.4.256-29-gd00804edfe40)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
dove-cubox | arm | lab-pengutronix | gcc-8 | mvebu_v7_defconfig | 1
panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1
qemu_arm-virt-gicv2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv2 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv2 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv2 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv2 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv3 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv3 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv3 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1
qemu_arm-virt-gicv3 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.4/kernel/v4.4.256-29-gd00804edfe40/plan/baseline/
Test: baseline
Tree: stable-rc
Branch: queue/4.4
Describe: v4.4.256-29-gd00804edfe40
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
SHA: d00804edfe4046ecb2b43020db212ef394066536
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
dove-cubox | arm | lab-pengutronix | gcc-8 | mvebu_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/602128824204380d3b3abe69
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: mvebu_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/mvebu_v7_defconfig/gcc-8/lab-pengutronix/baseline-dove-cubox.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/mvebu_v7_defconfig/gcc-8/lab-pengutronix/baseline-dove-cubox.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/602128824204380d3b3abe6a
new failure (last pass: v4.4.256-20-g4fae0faf0ebd)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1
Details: https://kernelci.org/test/plan/id/6021294df166a6c68a3abe6c
Results: 3 PASS, 1 FAIL, 1 SKIP
Full config: omap2plus_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/omap2plus_defconfig/gcc-8/lab-collabora/baseline-panda.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/omap2plus_defconfig/gcc-8/lab-collabora/baseline-panda.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6021294df166a6c68a3abe73
failing since 2 days (last pass: v4.4.255-14-ge5269953cc26, first fail: v4.4.256-14-g2d58dd4004a4)
2 lines
2021-02-08 12:06:33.233000+00:00 kern :emerg : lock: emif_lock+0x0/0xfffff26c [emif], .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
2021-02-08 12:06:33.248000+00:00 [ 19.126495] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=emerg RESULT=fail UNITS=lines MEASUREMENT=2>
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/602129a046bfaa311a3abe7c
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-qemu_arm-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-qemu_arm-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/602129a046bfaa311a3abe7d
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv2 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/60212a8698edcdfc423abe6c
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-broonie/baseline-qemu_arm-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-broonie/baseline-qemu_arm-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/60212a8698edcdfc423abe6d
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv2 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/602129793de47908473abe83
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-cip/baseline-qemu_arm-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-cip/baseline-qemu_arm-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/602129793de47908473abe84
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv2 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/60212a5684df18a3f83abe62
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-collabora/baseline-qemu_arm-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-collabora/baseline-qemu_arm-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/60212a5684df18a3f83abe63
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv2 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/6021299670521ce4433abe67
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-linaro-lkft/baseline-qemu_arm-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-linaro-lkft/baseline-qemu_arm-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/6021299670521ce4433abe68
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv3 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/60212989e6e09dbce53abe62
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-qemu_arm-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-baylibre/baseline-qemu_arm-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/60212989e6e09dbce53abe63
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv3 | arm | lab-broonie | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/60212992e6e09dbce53abe6e
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-broonie/baseline-qemu_arm-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-broonie/baseline-qemu_arm-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/60212992e6e09dbce53abe6f
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv3 | arm | lab-cip | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/6021296d731130ba703abe80
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-cip/baseline-qemu_arm-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-cip/baseline-qemu_arm-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/6021296d731130ba703abe81
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/6021297a3de47908473abe86
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-collabora/baseline-qemu_arm-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-collabora/baseline-qemu_arm-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/6021297a3de47908473abe87
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
platform | arch | lab | compiler | defconfig | regressions
--------------------+------+-----------------+----------+---------------------+------------
qemu_arm-virt-gicv3 | arm | lab-linaro-lkft | gcc-8 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/6021299570521ce4433abe62
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-linaro-lkft/baseline-qemu_arm-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.256-29-gd00804edfe40/arm/multi_v7_defconfig/gcc-8/lab-linaro-lkft/baseline-qemu_arm-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d9567/armel/baseline/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/6021299570521ce4433abe63
failing since 86 days (last pass: v4.4.243-18-gfc7e8c68369a, first fail: v4.4.243-19-g71b6c961c7fe)
^ permalink raw reply
* Re: [PATCH] drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
From: Souza, Jose @ 2021-02-08 15:51 UTC (permalink / raw)
To: intel-gfx@lists.freedesktop.org, Deak, Imre
Cc: stable@vger.kernel.org, pmenzel@molgen.mpg.de
In-Reply-To: <20210208154303.6839-1-imre.deak@intel.com>
On Mon, 2021-02-08 at 17:43 +0200, Imre Deak wrote:
> The TypeC FIA can be powered down if the TC-COLD power state is allowed,
> so block the TC-COLD state when initializing the FIA.
>
> Note that this isn't needed on ICL where the FIA is never modular and
> which has no generic way to block TC-COLD (except for platforms with a
> legacy TypeC port and on those too only via these legacy ports, not via
> a DP-alt/TBT port).
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
>
> Cc: <stable@vger.kernel.org> # v5.10+
> Cc: José Roberto de Souza <jose.souza@intel.com>
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3027
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 67 ++++++++++++++-----------
> 1 file changed, 37 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c
> index 27dc2dad6809c..2cefc13535a0f 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -23,36 +23,6 @@ static const char *tc_port_mode_name(enum tc_port_mode mode)
> return names[mode];
> }
>
>
>
>
> -static void
> -tc_port_load_fia_params(struct drm_i915_private *i915,
> - struct intel_digital_port *dig_port)
> -{
> - enum port port = dig_port->base.port;
> - enum tc_port tc_port = intel_port_to_tc(i915, port);
> - u32 modular_fia;
> -
> - if (INTEL_INFO(i915)->display.has_modular_fia) {
> - modular_fia = intel_uncore_read(&i915->uncore,
> - PORT_TX_DFLEXDPSP(FIA1));
> - drm_WARN_ON(&i915->drm, modular_fia == 0xffffffff);
> - modular_fia &= MODULAR_FIA_MASK;
> - } else {
> - modular_fia = 0;
> - }
> -
> - /*
> - * Each Modular FIA instance houses 2 TC ports. In SOC that has more
> - * than two TC ports, there are multiple instances of Modular FIA.
> - */
> - if (modular_fia) {
> - dig_port->tc_phy_fia = tc_port / 2;
> - dig_port->tc_phy_fia_idx = tc_port % 2;
> - } else {
> - dig_port->tc_phy_fia = FIA1;
> - dig_port->tc_phy_fia_idx = tc_port;
> - }
> -}
> -
> static enum intel_display_power_domain
> tc_cold_get_power_domain(struct intel_digital_port *dig_port)
> {
> @@ -646,6 +616,43 @@ void intel_tc_port_put_link(struct intel_digital_port *dig_port)
> mutex_unlock(&dig_port->tc_lock);
> }
>
>
>
>
> +static bool
> +tc_has_modular_fia(struct drm_i915_private *i915, struct intel_digital_port *dig_port)
> +{
> + intel_wakeref_t wakeref;
> + u32 val;
> +
> + if (!INTEL_INFO(i915)->display.has_modular_fia)
> + return false;
> +
> + wakeref = tc_cold_block(dig_port);
> + val = intel_uncore_read(&i915->uncore, PORT_TX_DFLEXDPSP(FIA1));
> + tc_cold_unblock(dig_port, wakeref);
> +
> + drm_WARN_ON(&i915->drm, val == 0xffffffff);
> +
> + return val & MODULAR_FIA_MASK;
> +}
> +
> +static void
> +tc_port_load_fia_params(struct drm_i915_private *i915, struct intel_digital_port *dig_port)
> +{
> + enum port port = dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(i915, port);
> +
> + /*
> + * Each Modular FIA instance houses 2 TC ports. In SOC that has more
> + * than two TC ports, there are multiple instances of Modular FIA.
> + */
> + if (tc_has_modular_fia(i915, dig_port)) {
> + dig_port->tc_phy_fia = tc_port / 2;
> + dig_port->tc_phy_fia_idx = tc_port % 2;
> + } else {
> + dig_port->tc_phy_fia = FIA1;
> + dig_port->tc_phy_fia_idx = tc_port;
> + }
> +}
> +
> void intel_tc_port_init(struct intel_digital_port *dig_port, bool is_legacy)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
^ permalink raw reply
* Re: Linux 4.9.256
From: Avi Kivity @ 2021-02-08 15:50 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel, akpm, torvalds, stable; +Cc: lwn, jslaby
In-Reply-To: <1612535085125226@kroah.com>
On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
> I'm announcing the release of the 4.9.256 kernel.
>
> This, and the 4.4.256 release are a little bit "different" than normal.
>
> This contains only 1 patch, just the version bump from .255 to .256 which ends
> up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
> than normal due to the "overflow".
>
> With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).
I think this is a bad idea. Many kernel features can only be discovered
by checking the kernel version. If a feature was introduced in 4.10,
then an application can be tricked into thinking a 4.9 kernel has it.
IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a
LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel.
> Nothing in the kernel build itself breaks with this change, but given that this
> is a userspace visible change, and some crazy tools (like glibc and gcc) have
> logic that checks the kernel version for different reasons, I wanted to do this
> release as an "empty" release to ensure that everything still works properly.
Even if glibc and gcc work, other programs may not.
I have two such cases. They don't depend on 4.9, but they're examples of
features that are not discoverable by other means.
> So, this is a YOU MUST UPGRADE requirement of a release. If you rely on the
> 4.9.y kernel, please throw this release into your test builds and rebuild the
> world and let us know if anything breaks, or if all is well.
>
> Go forth and do full system rebuilds! Yocto and Gentoo are great for this, as
> will systems that use buildroot.
>
> I'll try to hold off on doing a "real" 4.9.y release for a 9eek to give
> everyone a chance to test this out and get back to me. The pending patches in
> the 4.9.y queue are pretty serious, so I am loath to wait longer than that,
> consider yourself warned...
>
> The updated 4.9.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
> and can be browsed at the normal kernel.org git web browser:
> https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
>
> thanks,
>
> greg k-h
>
> ------------
>
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Greg Kroah-Hartman (1):
> Linux 4.9.256
>
>
^ permalink raw reply
* [PATCH] drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
From: Imre Deak @ 2021-02-08 15:43 UTC (permalink / raw)
To: intel-gfx; +Cc: stable, José Roberto de Souza, Paul Menzel
The TypeC FIA can be powered down if the TC-COLD power state is allowed,
so block the TC-COLD state when initializing the FIA.
Note that this isn't needed on ICL where the FIA is never modular and
which has no generic way to block TC-COLD (except for platforms with a
legacy TypeC port and on those too only via these legacy ports, not via
a DP-alt/TBT port).
Cc: <stable@vger.kernel.org> # v5.10+
Cc: José Roberto de Souza <jose.souza@intel.com>
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3027
Signed-off-by: Imre Deak <imre.deak@intel.com>
---
drivers/gpu/drm/i915/display/intel_tc.c | 67 ++++++++++++++-----------
1 file changed, 37 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c
index 27dc2dad6809c..2cefc13535a0f 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -23,36 +23,6 @@ static const char *tc_port_mode_name(enum tc_port_mode mode)
return names[mode];
}
-static void
-tc_port_load_fia_params(struct drm_i915_private *i915,
- struct intel_digital_port *dig_port)
-{
- enum port port = dig_port->base.port;
- enum tc_port tc_port = intel_port_to_tc(i915, port);
- u32 modular_fia;
-
- if (INTEL_INFO(i915)->display.has_modular_fia) {
- modular_fia = intel_uncore_read(&i915->uncore,
- PORT_TX_DFLEXDPSP(FIA1));
- drm_WARN_ON(&i915->drm, modular_fia == 0xffffffff);
- modular_fia &= MODULAR_FIA_MASK;
- } else {
- modular_fia = 0;
- }
-
- /*
- * Each Modular FIA instance houses 2 TC ports. In SOC that has more
- * than two TC ports, there are multiple instances of Modular FIA.
- */
- if (modular_fia) {
- dig_port->tc_phy_fia = tc_port / 2;
- dig_port->tc_phy_fia_idx = tc_port % 2;
- } else {
- dig_port->tc_phy_fia = FIA1;
- dig_port->tc_phy_fia_idx = tc_port;
- }
-}
-
static enum intel_display_power_domain
tc_cold_get_power_domain(struct intel_digital_port *dig_port)
{
@@ -646,6 +616,43 @@ void intel_tc_port_put_link(struct intel_digital_port *dig_port)
mutex_unlock(&dig_port->tc_lock);
}
+static bool
+tc_has_modular_fia(struct drm_i915_private *i915, struct intel_digital_port *dig_port)
+{
+ intel_wakeref_t wakeref;
+ u32 val;
+
+ if (!INTEL_INFO(i915)->display.has_modular_fia)
+ return false;
+
+ wakeref = tc_cold_block(dig_port);
+ val = intel_uncore_read(&i915->uncore, PORT_TX_DFLEXDPSP(FIA1));
+ tc_cold_unblock(dig_port, wakeref);
+
+ drm_WARN_ON(&i915->drm, val == 0xffffffff);
+
+ return val & MODULAR_FIA_MASK;
+}
+
+static void
+tc_port_load_fia_params(struct drm_i915_private *i915, struct intel_digital_port *dig_port)
+{
+ enum port port = dig_port->base.port;
+ enum tc_port tc_port = intel_port_to_tc(i915, port);
+
+ /*
+ * Each Modular FIA instance houses 2 TC ports. In SOC that has more
+ * than two TC ports, there are multiple instances of Modular FIA.
+ */
+ if (tc_has_modular_fia(i915, dig_port)) {
+ dig_port->tc_phy_fia = tc_port / 2;
+ dig_port->tc_phy_fia_idx = tc_port % 2;
+ } else {
+ dig_port->tc_phy_fia = FIA1;
+ dig_port->tc_phy_fia_idx = tc_port;
+ }
+}
+
void intel_tc_port_init(struct intel_digital_port *dig_port, bool is_legacy)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
--
2.25.1
^ permalink raw reply related
* [PATCH 5.10 100/120] mm: hugetlb: fix a race between isolating and freeing page
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Mike Kravetz,
Michal Hocko, Oscar Salvador, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Muchun Song <songmuchun@bytedance.com>
commit 0eb2df2b5629794020f75e94655e1994af63f0d4 upstream.
There is a race between isolate_huge_page() and __free_huge_page().
CPU0: CPU1:
if (PageHuge(page))
put_page(page)
__free_huge_page(page)
spin_lock(&hugetlb_lock)
update_and_free_page(page)
set_compound_page_dtor(page,
NULL_COMPOUND_DTOR)
spin_unlock(&hugetlb_lock)
isolate_huge_page(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHead(page), page)
spin_lock(&hugetlb_lock)
page_huge_active(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHuge(page), page)
spin_unlock(&hugetlb_lock)
When we isolate a HugeTLB page on CPU0. Meanwhile, we free it to the
buddy allocator on CPU1. Then, we can trigger a BUG_ON on CPU0, because
it is already freed to the buddy allocator.
Link: https://lkml.kernel.org/r/20210115124942.46403-5-songmuchun@bytedance.com
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5595,9 +5595,9 @@ bool isolate_huge_page(struct page *page
{
bool ret = true;
- VM_BUG_ON_PAGE(!PageHead(page), page);
spin_lock(&hugetlb_lock);
- if (!page_huge_active(page) || !get_page_unless_zero(page)) {
+ if (!PageHeadHuge(page) || !page_huge_active(page) ||
+ !get_page_unless_zero(page)) {
ret = false;
goto unlock;
}
^ permalink raw reply
* [PATCH 5.10 095/120] ARM: dts; gta04: SPI panel chip select is active low
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, H. Nikolaus Schaller, Tony Lindgren
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: H. Nikolaus Schaller <hns@goldelico.com>
commit 181739822cf6f8f4e12b173913af2967a28906c0 upstream.
With the arrival of
commit 2fee9583198eb9 ("spi: dt-bindings: clarify CS behavior for spi-cs-high and gpio descriptors")
it was clarified what the proper state for cs-gpios should be, even if the
flag is ignored. The driver code is doing the right thing since
766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
The chip-select of the td028ttec1 panel is active-low, so we must omit spi-cs-high;
attribute (already removed by separate patch) and should now use GPIO_ACTIVE_LOW for
the client device description to be fully consistent.
Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
CC: stable@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 003202d12990..7b8c18e6605e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -114,7 +114,7 @@ spi_lcd: spi_lcd {
gpio-sck = <&gpio1 12 GPIO_ACTIVE_HIGH>;
gpio-miso = <&gpio1 18 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio1 20 GPIO_ACTIVE_HIGH>;
- cs-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
num-chipselects = <1>;
/* lcd panel */
--
2.30.0
^ permalink raw reply related
* [PATCH 5.10 099/120] mm: hugetlb: fix a race between freeing and dissolving the page
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Mike Kravetz,
Oscar Salvador, Michal Hocko, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Muchun Song <songmuchun@bytedance.com>
commit 7ffddd499ba6122b1a07828f023d1d67629aa017 upstream.
There is a race condition between __free_huge_page()
and dissolve_free_huge_page().
CPU0: CPU1:
// page_count(page) == 1
put_page(page)
__free_huge_page(page)
dissolve_free_huge_page(page)
spin_lock(&hugetlb_lock)
// PageHuge(page) && !page_count(page)
update_and_free_page(page)
// page is freed to the buddy
spin_unlock(&hugetlb_lock)
spin_lock(&hugetlb_lock)
clear_page_huge_active(page)
enqueue_huge_page(page)
// It is wrong, the page is already freed
spin_unlock(&hugetlb_lock)
The race window is between put_page() and dissolve_free_huge_page().
We should make sure that the page is already on the free list when it is
dissolved.
As a result __free_huge_page would corrupt page(s) already in the buddy
allocator.
Link: https://lkml.kernel.org/r/20210115124942.46403-4-songmuchun@bytedance.com
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -79,6 +79,21 @@ DEFINE_SPINLOCK(hugetlb_lock);
static int num_fault_mutexes;
struct mutex *hugetlb_fault_mutex_table ____cacheline_aligned_in_smp;
+static inline bool PageHugeFreed(struct page *head)
+{
+ return page_private(head + 4) == -1UL;
+}
+
+static inline void SetPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, -1UL);
+}
+
+static inline void ClearPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, 0);
+}
+
/* Forward declaration */
static int hugetlb_acct_memory(struct hstate *h, long delta);
@@ -1028,6 +1043,7 @@ static void enqueue_huge_page(struct hst
list_move(&page->lru, &h->hugepage_freelists[nid]);
h->free_huge_pages++;
h->free_huge_pages_node[nid]++;
+ SetPageHugeFreed(page);
}
static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
@@ -1044,6 +1060,7 @@ static struct page *dequeue_huge_page_no
list_move(&page->lru, &h->hugepage_activelist);
set_page_refcounted(page);
+ ClearPageHugeFreed(page);
h->free_huge_pages--;
h->free_huge_pages_node[nid]--;
return page;
@@ -1505,6 +1522,7 @@ static void prep_new_huge_page(struct hs
spin_lock(&hugetlb_lock);
h->nr_huge_pages++;
h->nr_huge_pages_node[nid]++;
+ ClearPageHugeFreed(page);
spin_unlock(&hugetlb_lock);
}
@@ -1755,6 +1773,7 @@ int dissolve_free_huge_page(struct page
{
int rc = -EBUSY;
+retry:
/* Not to disrupt normal path by vainly holding hugetlb_lock */
if (!PageHuge(page))
return 0;
@@ -1771,6 +1790,26 @@ int dissolve_free_huge_page(struct page
int nid = page_to_nid(head);
if (h->free_huge_pages - h->resv_huge_pages == 0)
goto out;
+
+ /*
+ * We should make sure that the page is already on the free list
+ * when it is dissolved.
+ */
+ if (unlikely(!PageHugeFreed(head))) {
+ spin_unlock(&hugetlb_lock);
+ cond_resched();
+
+ /*
+ * Theoretically, we should return -EBUSY when we
+ * encounter this race. In fact, we have a chance
+ * to successfully dissolve the page if we do a
+ * retry. Because the race window is quite small.
+ * If we seize this opportunity, it is an optimization
+ * for increasing the success rate of dissolving page.
+ */
+ goto retry;
+ }
+
/*
* Move PageHWPoison flag from head page to the raw error page,
* which makes any subpages rather than the error page reusable.
^ permalink raw reply
* [PATCH 5.10 104/120] mm: thp: fix MADV_REMOVE deadlock on shmem THP
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hugh Dickins, Sergey Senozhatsky,
Andrea Arcangeli, Andrew Morton, Linus Torvalds
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Hugh Dickins <hughd@google.com>
commit 1c2f67308af4c102b4e1e6cd6f69819ae59408e0 upstream.
Sergey reported deadlock between kswapd correctly doing its usual
lock_page(page) followed by down_read(page->mapping->i_mmap_rwsem), and
madvise(MADV_REMOVE) on an madvise(MADV_HUGEPAGE) area doing
down_write(page->mapping->i_mmap_rwsem) followed by lock_page(page).
This happened when shmem_fallocate(punch hole)'s unmap_mapping_range()
reaches zap_pmd_range()'s call to __split_huge_pmd(). The same deadlock
could occur when partially truncating a mapped huge tmpfs file, or using
fallocate(FALLOC_FL_PUNCH_HOLE) on it.
__split_huge_pmd()'s page lock was added in 5.8, to make sure that any
concurrent use of reuse_swap_page() (holding page lock) could not catch
the anon THP's mapcounts and swapcounts while they were being split.
Fortunately, reuse_swap_page() is never applied to a shmem or file THP
(not even by khugepaged, which checks PageSwapCache before calling), and
anonymous THPs are never created in shmem or file areas: so that
__split_huge_pmd()'s page lock can only be necessary for anonymous THPs,
on which there is no risk of deadlock with i_mmap_rwsem.
Link: https://lkml.kernel.org/r/alpine.LSU.2.11.2101161409470.2022@eggly.anvils
Fixes: c444eb564fb1 ("mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/huge_memory.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2188,7 +2188,7 @@ void __split_huge_pmd(struct vm_area_str
{
spinlock_t *ptl;
struct mmu_notifier_range range;
- bool was_locked = false;
+ bool do_unlock_page = false;
pmd_t _pmd;
mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
@@ -2204,7 +2204,6 @@ void __split_huge_pmd(struct vm_area_str
VM_BUG_ON(freeze && !page);
if (page) {
VM_WARN_ON_ONCE(!PageLocked(page));
- was_locked = true;
if (page != pmd_page(*pmd))
goto out;
}
@@ -2213,19 +2212,29 @@ repeat:
if (pmd_trans_huge(*pmd)) {
if (!page) {
page = pmd_page(*pmd);
- if (unlikely(!trylock_page(page))) {
- get_page(page);
- _pmd = *pmd;
- spin_unlock(ptl);
- lock_page(page);
- spin_lock(ptl);
- if (unlikely(!pmd_same(*pmd, _pmd))) {
- unlock_page(page);
+ /*
+ * An anonymous page must be locked, to ensure that a
+ * concurrent reuse_swap_page() sees stable mapcount;
+ * but reuse_swap_page() is not used on shmem or file,
+ * and page lock must not be taken when zap_pmd_range()
+ * calls __split_huge_pmd() while i_mmap_lock is held.
+ */
+ if (PageAnon(page)) {
+ if (unlikely(!trylock_page(page))) {
+ get_page(page);
+ _pmd = *pmd;
+ spin_unlock(ptl);
+ lock_page(page);
+ spin_lock(ptl);
+ if (unlikely(!pmd_same(*pmd, _pmd))) {
+ unlock_page(page);
+ put_page(page);
+ page = NULL;
+ goto repeat;
+ }
put_page(page);
- page = NULL;
- goto repeat;
}
- put_page(page);
+ do_unlock_page = true;
}
}
if (PageMlocked(page))
@@ -2235,7 +2244,7 @@ repeat:
__split_huge_pmd_locked(vma, pmd, range.start, freeze);
out:
spin_unlock(ptl);
- if (!was_locked && page)
+ if (do_unlock_page)
unlock_page(page);
/*
* No need to double call mmu_notifier->invalidate_range() callback.
^ permalink raw reply
* [PATCH 5.10 103/120] mm/vmalloc: separate put pages and flush VM flags
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rick Edgecombe, Matthew Wilcox,
Miaohe Lin, Christoph Hellwig, Daniel Axtens, Andrew Morton,
Linus Torvalds
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
commit 4f6ec8602341e97b364e4e0d41a1ed08148f5e98 upstream.
When VM_MAP_PUT_PAGES was added, it was defined with the same value as
VM_FLUSH_RESET_PERMS. This doesn't seem like it will cause any big
functional problems other than some excess flushing for VM_MAP_PUT_PAGES
allocations.
Redefine VM_MAP_PUT_PAGES to have its own value. Also, rearrange things
so flags are less likely to be missed in the future.
Link: https://lkml.kernel.org/r/20210122233706.9304-1-rick.p.edgecombe@intel.com
Fixes: b944afc9d64d ("mm: add a VM_MAP_PUT_PAGES flag for vmap")
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Daniel Axtens <dja@axtens.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/vmalloc.h | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -24,7 +24,8 @@ struct notifier_block; /* in notifier.h
#define VM_UNINITIALIZED 0x00000020 /* vm_struct is not fully initialized */
#define VM_NO_GUARD 0x00000040 /* don't add guard page */
#define VM_KASAN 0x00000080 /* has allocated kasan shadow memory */
-#define VM_MAP_PUT_PAGES 0x00000100 /* put pages and free array in vfree */
+#define VM_FLUSH_RESET_PERMS 0x00000100 /* reset direct map and flush TLB on unmap, can't be freed in atomic context */
+#define VM_MAP_PUT_PAGES 0x00000200 /* put pages and free array in vfree */
/*
* VM_KASAN is used slighly differently depending on CONFIG_KASAN_VMALLOC.
@@ -37,12 +38,6 @@ struct notifier_block; /* in notifier.h
* determine which allocations need the module shadow freed.
*/
-/*
- * Memory with VM_FLUSH_RESET_PERMS cannot be freed in an interrupt or with
- * vfree_atomic().
- */
-#define VM_FLUSH_RESET_PERMS 0x00000100 /* Reset direct map and flush TLB on unmap */
-
/* bits [20..32] reserved for arch specific ioremap internals */
/*
^ permalink raw reply
* [PATCH 5.10 118/120] udp: ipv4: manipulate network header of NATed UDP GRO fraglist
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dongseok Yi, Steffen Klassert,
Jakub Kicinski
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Dongseok Yi <dseok.yi@samsung.com>
commit c3df39ac9b0e3747bf8233ea9ce4ed5ceb3199d3 upstream.
UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
forwarding. Only the header of head_skb from ip_finish_output_gso ->
skb_gso_segment is updated but following frag_skbs are not updated.
A call path skb_mac_gso_segment -> inet_gso_segment ->
udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
does not try to update UDP/IP header of the segment list but copy
only the MAC header.
Update port, addr and check of each skb of the segment list in
__udp_gso_segment_list. It covers both SNAT and DNAT.
Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
Signed-off-by: Dongseok Yi <dseok.yi@samsung.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Link: https://lore.kernel.org/r/1611962007-80092-1-git-send-email-dseok.yi@samsung.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/udp.h | 2 -
net/ipv4/udp_offload.c | 69 +++++++++++++++++++++++++++++++++++++++++++++----
net/ipv6/udp_offload.c | 2 -
3 files changed, 66 insertions(+), 7 deletions(-)
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -178,7 +178,7 @@ struct sk_buff *udp_gro_receive(struct l
int udp_gro_complete(struct sk_buff *skb, int nhoff, udp_lookup_t lookup);
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features);
+ netdev_features_t features, bool is_ipv6);
static inline struct udphdr *udp_gro_udphdr(struct sk_buff *skb)
{
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -184,8 +184,67 @@ out_unlock:
}
EXPORT_SYMBOL(skb_udp_tunnel_segment);
+static void __udpv4_gso_segment_csum(struct sk_buff *seg,
+ __be32 *oldip, __be32 *newip,
+ __be16 *oldport, __be16 *newport)
+{
+ struct udphdr *uh;
+ struct iphdr *iph;
+
+ if (*oldip == *newip && *oldport == *newport)
+ return;
+
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if (uh->check) {
+ inet_proto_csum_replace4(&uh->check, seg, *oldip, *newip,
+ true);
+ inet_proto_csum_replace2(&uh->check, seg, *oldport, *newport,
+ false);
+ if (!uh->check)
+ uh->check = CSUM_MANGLED_0;
+ }
+ *oldport = *newport;
+
+ csum_replace4(&iph->check, *oldip, *newip);
+ *oldip = *newip;
+}
+
+static struct sk_buff *__udpv4_gso_segment_list_csum(struct sk_buff *segs)
+{
+ struct sk_buff *seg;
+ struct udphdr *uh, *uh2;
+ struct iphdr *iph, *iph2;
+
+ seg = segs;
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if ((udp_hdr(seg)->dest == udp_hdr(seg->next)->dest) &&
+ (udp_hdr(seg)->source == udp_hdr(seg->next)->source) &&
+ (ip_hdr(seg)->daddr == ip_hdr(seg->next)->daddr) &&
+ (ip_hdr(seg)->saddr == ip_hdr(seg->next)->saddr))
+ return segs;
+
+ while ((seg = seg->next)) {
+ uh2 = udp_hdr(seg);
+ iph2 = ip_hdr(seg);
+
+ __udpv4_gso_segment_csum(seg,
+ &iph2->saddr, &iph->saddr,
+ &uh2->source, &uh->source);
+ __udpv4_gso_segment_csum(seg,
+ &iph2->daddr, &iph->daddr,
+ &uh2->dest, &uh->dest);
+ }
+
+ return segs;
+}
+
static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,
- netdev_features_t features)
+ netdev_features_t features,
+ bool is_ipv6)
{
unsigned int mss = skb_shinfo(skb)->gso_size;
@@ -195,11 +254,11 @@ static struct sk_buff *__udp_gso_segment
udp_hdr(skb)->len = htons(sizeof(struct udphdr) + mss);
- return skb;
+ return is_ipv6 ? skb : __udpv4_gso_segment_list_csum(skb);
}
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features)
+ netdev_features_t features, bool is_ipv6)
{
struct sock *sk = gso_skb->sk;
unsigned int sum_truesize = 0;
@@ -211,7 +270,7 @@ struct sk_buff *__udp_gso_segment(struct
__be16 newlen;
if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST)
- return __udp_gso_segment_list(gso_skb, features);
+ return __udp_gso_segment_list(gso_skb, features, is_ipv6);
mss = skb_shinfo(gso_skb)->gso_size;
if (gso_skb->len <= sizeof(*uh) + mss)
@@ -325,7 +384,7 @@ static struct sk_buff *udp4_ufo_fragment
goto out;
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features, false);
mss = skb_shinfo(skb)->gso_size;
if (unlikely(skb->len <= mss))
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -46,7 +46,7 @@ static struct sk_buff *udp6_ufo_fragment
goto out;
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features, true);
/* Do software UFO. Complete and fill in the UDP checksum as HW cannot
* do checksum of UDP packets sent as multiple IP fragments.
^ permalink raw reply
* [PATCH 5.10 102/120] mm, compaction: move high_pfn to the for loop scope
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rokudo Yan, Mel Gorman,
Vlastimil Babka, Andrew Morton, Linus Torvalds
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Rokudo Yan <wu-yan@tcl.com>
commit 74e21484e40bb8ce0f9828bbfe1c9fc9b04249c6 upstream.
In fast_isolate_freepages, high_pfn will be used if a prefered one (ie
PFN >= low_fn) not found.
But the high_pfn is not reset before searching an free area, so when it
was used as freepage, it may from another free area searched before. As
a result move_freelist_head(freelist, freepage) will have unexpected
behavior (eg corrupt the MOVABLE freelist)
Unable to handle kernel paging request at virtual address dead000000000200
Mem abort info:
ESR = 0x96000044
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000044
CM = 0, WnR = 1
[dead000000000200] address between user and kernel address ranges
-000|list_cut_before(inline)
-000|move_freelist_head(inline)
-000|fast_isolate_freepages(inline)
-000|isolate_freepages(inline)
-000|compaction_alloc(?, ?)
-001|unmap_and_move(inline)
-001|migrate_pages([NSD:0xFFFFFF80088CBBD0] from = 0xFFFFFF80088CBD88, [NSD:0xFFFFFF80088CBBC8] get_new_p
-002|__read_once_size(inline)
-002|static_key_count(inline)
-002|static_key_false(inline)
-002|trace_mm_compaction_migratepages(inline)
-002|compact_zone(?, [NSD:0xFFFFFF80088CBCB0] capc = 0x0)
-003|kcompactd_do_work(inline)
-003|kcompactd([X19] p = 0xFFFFFF93227FBC40)
-004|kthread([X20] _create = 0xFFFFFFE1AFB26380)
-005|ret_from_fork(asm)
The issue was reported on an smart phone product with 6GB ram and 3GB
zram as swap device.
This patch fixes the issue by reset high_pfn before searching each free
area, which ensure freepage and freelist match when call
move_freelist_head in fast_isolate_freepages().
Link: http://lkml.kernel.org/r/20190118175136.31341-12-mgorman@techsingularity.net
Link: https://lkml.kernel.org/r/20210112094720.1238444-1-wu-yan@tcl.com
Fixes: 5a811889de10f1eb ("mm, compaction: use free lists to quickly locate a migration target")
Signed-off-by: Rokudo Yan <wu-yan@tcl.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/compaction.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1302,7 +1302,7 @@ fast_isolate_freepages(struct compact_co
{
unsigned int limit = min(1U, freelist_scan_limit(cc) >> 1);
unsigned int nr_scanned = 0;
- unsigned long low_pfn, min_pfn, high_pfn = 0, highest = 0;
+ unsigned long low_pfn, min_pfn, highest = 0;
unsigned long nr_isolated = 0;
unsigned long distance;
struct page *page = NULL;
@@ -1347,6 +1347,7 @@ fast_isolate_freepages(struct compact_co
struct page *freepage;
unsigned long flags;
unsigned int order_scanned = 0;
+ unsigned long high_pfn = 0;
if (!area->nr_free)
continue;
^ permalink raw reply
* [PATCH 5.10 101/120] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Mike Kravetz,
Michal Hocko, Oscar Salvador, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Muchun Song <songmuchun@bytedance.com>
commit ecbf4724e6061b4b01be20f6d797d64d462b2bc8 upstream.
The page_huge_active() can be called from scan_movable_pages() which do
not hold a reference count to the HugeTLB page. So when we call
page_huge_active() from scan_movable_pages(), the HugeTLB page can be
freed parallel. Then we will trigger a BUG_ON which is in the
page_huge_active() when CONFIG_DEBUG_VM is enabled. Just remove the
VM_BUG_ON_PAGE.
Link: https://lkml.kernel.org/r/20210115124942.46403-6-songmuchun@bytedance.com
Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()")
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1361,8 +1361,7 @@ struct hstate *size_to_hstate(unsigned l
*/
bool page_huge_active(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
- return PageHead(page) && PagePrivate(&page[1]);
+ return PageHeadHuge(page) && PagePrivate(&page[1]);
}
/* never called for tail page */
^ permalink raw reply
* [PATCH 5.10 098/120] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Michal Hocko,
Mike Kravetz, Oscar Salvador, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Muchun Song <songmuchun@bytedance.com>
commit 585fc0d2871c9318c949fbf45b1f081edd489e96 upstream.
If a new hugetlb page is allocated during fallocate it will not be
marked as active (set_page_huge_active) which will result in a later
isolate_huge_page failure when the page migration code would like to
move that page. Such a failure would be unexpected and wrong.
Only export set_page_huge_active, just leave clear_page_huge_active as
static. Because there are no external users.
Link: https://lkml.kernel.org/r/20210115124942.46403-3-songmuchun@bytedance.com
Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate())
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/hugetlbfs/inode.c | 3 ++-
include/linux/hugetlb.h | 2 ++
mm/hugetlb.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -735,9 +735,10 @@ static long hugetlbfs_fallocate(struct f
mutex_unlock(&hugetlb_fault_mutex_table[hash]);
+ set_page_huge_active(page);
/*
* unlock_page because locked by add_to_page_cache()
- * page_put due to reference from alloc_huge_page()
+ * put_page() due to reference from alloc_huge_page()
*/
unlock_page(page);
put_page(page);
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -770,6 +770,8 @@ static inline void huge_ptep_modify_prot
}
#endif
+void set_page_huge_active(struct page *page);
+
#else /* CONFIG_HUGETLB_PAGE */
struct hstate {};
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1349,7 +1349,7 @@ bool page_huge_active(struct page *page)
}
/* never called for tail page */
-static void set_page_huge_active(struct page *page)
+void set_page_huge_active(struct page *page)
{
VM_BUG_ON_PAGE(!PageHeadHuge(page), page);
SetPagePrivate(&page[1]);
^ permalink raw reply
* [PATCH 5.10 119/120] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, DENG Qingfang, Vladimir Oltean,
Jakub Kicinski
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: DENG Qingfang <dqfext@gmail.com>
commit f72f2fb8fb6be095b98af5d740ac50cffd0b0cae upstream.
Having multiple destination ports for a unicast address does not make
sense.
Make port_db_load_purge override existent unicast portvec instead of
adding a new port bit.
Fixes: 884729399260 ("net: dsa: mv88e6xxx: handle multiple ports in ATU")
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20210130134334.10243-1-dqfext@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/mv88e6xxx/chip.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1669,7 +1669,11 @@ static int mv88e6xxx_port_db_load_purge(
if (!entry.portvec)
entry.state = 0;
} else {
- entry.portvec |= BIT(port);
+ if (state == MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC)
+ entry.portvec = BIT(port);
+ else
+ entry.portvec |= BIT(port);
+
entry.state = state;
}
^ permalink raw reply
* [PATCH 5.10 120/120] net: sched: replaced invalid qdisc tree flush helper in qdisc_replace
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Ovechkin,
Alexander Kuznetsov, Dmitry Monakhov, Dmitry Yakunin, Cong Wang,
Jakub Kicinski
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Alexander Ovechkin <ovov@yandex-team.ru>
commit 938e0fcd3253efdef8924714158911286d08cfe1 upstream.
Commit e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
introduced qdisc tree flush/purge helpers, but erroneously used flush helper
instead of purge helper in qdisc_replace function.
This issue was found in our CI, that tests various qdisc setups by configuring
qdisc and sending data through it. Call of invalid helper sporadically leads
to corruption of vt_tree/cf_tree of hfsc_class that causes kernel oops:
Oops: 0000 [#1] SMP PTI
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.11.0-8f6859df #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:rb_insert_color+0x18/0x190
Code: c3 31 c0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 07 48 85 c0 0f 84 05 01 00 00 48 8b 10 f6 c2 01 0f 85 34 01 00 00 <48> 8b 4a 08 49 89 d0 48 39 c1 74 7d 48 85 c9 74 32 f6 01 01 75 2d
RSP: 0018:ffffc900000b8bb0 EFLAGS: 00010246
RAX: ffff8881ef4c38b0 RBX: ffff8881d956e400 RCX: ffff8881ef4c38b0
RDX: 0000000000000000 RSI: ffff8881d956f0a8 RDI: ffff8881d956e4b0
RBP: 0000000000000000 R08: 000000d5c4e249da R09: 1600000000000000
R10: ffffc900000b8be0 R11: ffffc900000b8b28 R12: 0000000000000001
R13: 000000000000005a R14: ffff8881f0905000 R15: ffff8881f0387d00
FS: 0000000000000000(0000) GS:ffff8881f8b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000001f4796004 CR4: 0000000000060ee0
Call Trace:
<IRQ>
init_vf.isra.19+0xec/0x250 [sch_hfsc]
hfsc_enqueue+0x245/0x300 [sch_hfsc]
? fib_rules_lookup+0x12a/0x1d0
? __dev_queue_xmit+0x4b6/0x930
? hfsc_delete_class+0x250/0x250 [sch_hfsc]
__dev_queue_xmit+0x4b6/0x930
? ip6_finish_output2+0x24d/0x590
ip6_finish_output2+0x24d/0x590
? ip6_output+0x6c/0x130
ip6_output+0x6c/0x130
? __ip6_finish_output+0x110/0x110
mld_sendpack+0x224/0x230
mld_ifc_timer_expire+0x186/0x2c0
? igmp6_group_dropped+0x200/0x200
call_timer_fn+0x2d/0x150
run_timer_softirq+0x20c/0x480
? tick_sched_do_timer+0x60/0x60
? tick_sched_timer+0x37/0x70
__do_softirq+0xf7/0x2cb
irq_exit+0xa0/0xb0
smp_apic_timer_interrupt+0x74/0x150
apic_timer_interrupt+0xf/0x20
</IRQ>
Fixes: e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
Signed-off-by: Alexander Ovechkin <ovov@yandex-team.ru>
Reported-by: Alexander Kuznetsov <wwfq@yandex-team.ru>
Acked-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Acked-by: Dmitry Yakunin <zeil@yandex-team.ru>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Link: https://lore.kernel.org/r/20210201200049.299153-1-ovov@yandex-team.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/sch_generic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -1155,7 +1155,7 @@ static inline struct Qdisc *qdisc_replac
old = *pold;
*pold = new;
if (old != NULL)
- qdisc_tree_flush_backlog(old);
+ qdisc_purge_queue(old);
sch_tree_unlock(sch);
return old;
^ permalink raw reply
* [PATCH 5.10 115/120] igc: Report speed and duplex as unknown when device is runtime suspended
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Sasha Neftin,
Tony Nguyen
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
commit 2e99dedc73f004f650b197c9b269c15c7e01ad15 upstream.
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime suspended, igc will complain and
stops working:
[ 123.449883] igc 0000:03:00.0 enp3s0: PCIe link lost, device now detached
[ 123.450052] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 123.450056] #PF: supervisor read access in kernel mode
[ 123.450058] #PF: error_code(0x0000) - not-present page
[ 123.450059] PGD 0 P4D 0
[ 123.450064] Oops: 0000 [#1] SMP NOPTI
[ 123.450068] CPU: 0 PID: 2525 Comm: udevadm Tainted: G U W OE 5.10.0-1002-oem #2+rkl2-Ubuntu
[ 123.450078] RIP: 0010:igc_rd32+0x1c/0x90 [igc]
[ 123.450080] Code: c0 5d c3 b8 fd ff ff ff c3 0f 1f 44 00 00 0f 1f 44 00 00 55 89 f0 48 89 e5 41 56 41 55 41 54 49 89 c4 53 48 8b 57 08 48 01 d0 <44> 8b 28 41 83 fd ff 74 0c 5b 44 89 e8 41 5c 41 5d 4
[ 123.450083] RSP: 0018:ffffb0d100d6fcc0 EFLAGS: 00010202
[ 123.450085] RAX: 0000000000000008 RBX: ffffb0d100d6fd30 RCX: 0000000000000000
[ 123.450087] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff945a12716c10
[ 123.450089] RBP: ffffb0d100d6fce0 R08: ffff945a12716550 R09: ffff945a09874000
[ 123.450090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000008
[ 123.450092] R13: ffff945a12716000 R14: ffff945a037da280 R15: ffff945a037da290
[ 123.450094] FS: 00007f3b34c868c0(0000) GS:ffff945b89200000(0000) knlGS:0000000000000000
[ 123.450096] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 123.450098] CR2: 0000000000000008 CR3: 00000001144de006 CR4: 0000000000770ef0
[ 123.450100] PKRU: 55555554
[ 123.450101] Call Trace:
[ 123.450111] igc_ethtool_get_link_ksettings+0xd6/0x1b0 [igc]
[ 123.450118] __ethtool_get_link_ksettings+0x71/0xb0
[ 123.450123] duplex_show+0x74/0xc0
[ 123.450129] dev_attr_show+0x1d/0x40
[ 123.450134] sysfs_kf_seq_show+0xa1/0x100
[ 123.450137] kernfs_seq_show+0x27/0x30
[ 123.450142] seq_read+0xb7/0x400
[ 123.450148] ? common_file_perm+0x72/0x170
[ 123.450151] kernfs_fop_read+0x35/0x1b0
[ 123.450155] vfs_read+0xb5/0x1b0
[ 123.450157] ksys_read+0x67/0xe0
[ 123.450160] __x64_sys_read+0x1a/0x20
[ 123.450164] do_syscall_64+0x38/0x90
[ 123.450168] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 123.450170] RIP: 0033:0x7f3b351fe142
[ 123.450173] Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[ 123.450174] RSP: 002b:00007fffef2ec138 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 123.450177] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3b351fe142
[ 123.450179] RDX: 0000000000001001 RSI: 00005644c047f070 RDI: 0000000000000003
[ 123.450180] RBP: 00007fffef2ec340 R08: 00005644c047f070 R09: 00007f3b352d9320
[ 123.450182] R10: 00005644c047c010 R11: 0000000000000246 R12: 00005644c047cbf0
[ 123.450184] R13: 00005644c047e6d0 R14: 0000000000000003 R15: 00007fffef2ec140
[ 123.450189] Modules linked in: rfcomm ccm cmac algif_hash algif_skcipher af_alg bnep toshiba_acpi industrialio toshiba_haps hp_accel lis3lv02d btusb btrtl btbcm btintel bluetooth ecdh_generic ecc joydev input_leds nls_iso8859_1 snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_hda_codec_hdmi snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation soundwire_cadence snd_hda_codec snd_hda_core ath10k_pci snd_hwdep intel_rapl_msr intel_rapl_common ath10k_core soundwire_bus snd_soc_core x86_pkg_temp_thermal ath intel_powerclamp snd_compress ac97_bus snd_pcm_dmaengine mac80211 snd_pcm coretemp snd_seq_midi snd_seq_midi_event snd_rawmidi kvm_intel cfg80211 snd_seq snd_seq_device snd_timer mei_hdcp kvm libarc4 snd crct10dif_pclmul ghash_clmulni_intel aesni_intel
mei_me dell_wmi
[ 123.450266] dell_smbios soundcore sparse_keymap dcdbas crypto_simd cryptd mei dell_uart_backlight glue_helper ee1004 wmi_bmof intel_wmi_thunderbolt dell_wmi_descriptor mac_hid efi_pstore acpi_pad acpi_tad intel_cstate sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crc32_pclmul rc_core drm intel_lpss_pci i2c_i801 ahci igc intel_lpss i2c_smbus idma64 xhci_pci libahci virt_dma xhci_pci_renesas wmi video pinctrl_tigerlake
[ 123.450335] CR2: 0000000000000008
[ 123.450338] ---[ end trace 9f731e38b53c35cc ]---
The more generic approach will be wrap get_link_ksettings() with begin()
and complete() callbacks, and calls runtime resume and runtime suspend
routine respectively. However, igc is like igb, runtime resume routine
uses rtnl_lock() which upper ethtool layer also uses.
So to prevent a deadlock on rtnl, take a different approach, use
pm_runtime_suspended() to avoid reading register while device is runtime
suspended.
Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Sasha Neftin <sasha.neftin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/igc/igc_ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
+++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
@@ -1714,7 +1714,8 @@ static int igc_ethtool_get_link_ksetting
Asym_Pause);
}
- status = rd32(IGC_STATUS);
+ status = pm_runtime_suspended(&adapter->pdev->dev) ?
+ 0 : rd32(IGC_STATUS);
if (status & IGC_STATUS_LU) {
if (status & IGC_STATUS_SPEED_1000) {
^ permalink raw reply
* [PATCH 5.10 097/120] ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Linus Walleij, Dmitry Osipenko,
Russell King
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Dmitry Osipenko <digetx@gmail.com>
commit 538eea5362a1179dfa7770dd2b6607dc30cc50c6 upstream.
The tegra_uart_config of the DEBUG_LL code is now placed right at the
start of the .text section after commit which enabled debug output in the
decompressor. Tegra devices are not booting anymore if DEBUG_LL is enabled
since tegra_uart_config data is executes as a code. Fix the misplaced
tegra_uart_config storage by embedding it into the code.
Cc: stable@vger.kernel.org
Fixes: 2596a72d3384 ("ARM: 9009/1: uncompress: Enable debug in head.S")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/debug/tegra.S | 54 ++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 27 deletions(-)
--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -149,7 +149,34 @@
.align
99: .word .
+#if defined(ZIMAGE)
+ .word . + 4
+/*
+ * Storage for the state maintained by the macro.
+ *
+ * In the kernel proper, this data is located in arch/arm/mach-tegra/tegra.c.
+ * That's because this header is included from multiple files, and we only
+ * want a single copy of the data. In particular, the UART probing code above
+ * assumes it's running using physical addresses. This is true when this file
+ * is included from head.o, but not when included from debug.o. So we need
+ * to share the probe results between the two copies, rather than having
+ * to re-run the probing again later.
+ *
+ * In the decompressor, we put the storage right here, since common.c
+ * isn't included in the decompressor build. This storage data gets put in
+ * .text even though it's really data, since .data is discarded from the
+ * decompressor. Luckily, .text is writeable in the decompressor, unless
+ * CONFIG_ZBOOT_ROM. That dependency is handled in arch/arm/Kconfig.debug.
+ */
+ /* Debug UART initialization required */
+ .word 1
+ /* Debug UART physical address */
+ .word 0
+ /* Debug UART virtual address */
+ .word 0
+#else
.word tegra_uart_config
+#endif
.ltorg
/* Load previously selected UART address */
@@ -189,30 +216,3 @@
.macro waituarttxrdy,rd,rx
.endm
-
-/*
- * Storage for the state maintained by the macros above.
- *
- * In the kernel proper, this data is located in arch/arm/mach-tegra/tegra.c.
- * That's because this header is included from multiple files, and we only
- * want a single copy of the data. In particular, the UART probing code above
- * assumes it's running using physical addresses. This is true when this file
- * is included from head.o, but not when included from debug.o. So we need
- * to share the probe results between the two copies, rather than having
- * to re-run the probing again later.
- *
- * In the decompressor, we put the symbol/storage right here, since common.c
- * isn't included in the decompressor build. This symbol gets put in .text
- * even though it's really data, since .data is discarded from the
- * decompressor. Luckily, .text is writeable in the decompressor, unless
- * CONFIG_ZBOOT_ROM. That dependency is handled in arch/arm/Kconfig.debug.
- */
-#if defined(ZIMAGE)
-tegra_uart_config:
- /* Debug UART initialization required */
- .word 1
- /* Debug UART physical address */
- .word 0
- /* Debug UART virtual address */
- .word 0
-#endif
^ permalink raw reply
* [PATCH 5.10 117/120] net: ip_tunnel: fix mtu calculation
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Slava Bacherikov, Vadim Fedorenko,
Jakub Kicinski
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Vadim Fedorenko <vfedorenko@novek.ru>
commit 28e104d00281ade30250b24e098bf50887671ea4 upstream.
dev->hard_header_len for tunnel interface is set only when header_ops
are set too and already contains full overhead of any tunnel encapsulation.
That's why there is not need to use this overhead twice in mtu calc.
Fixes: fdafed459998 ("ip_gre: set dev->hard_header_len and dev->needed_headroom properly")
Reported-by: Slava Bacherikov <mail@slava.cc>
Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
Link: https://lore.kernel.org/r/1611959267-20536-1-git-send-email-vfedorenko@novek.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/ip_tunnel.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -317,7 +317,7 @@ static int ip_tunnel_bind_dev(struct net
}
dev->needed_headroom = t_hlen + hlen;
- mtu -= (dev->hard_header_len + t_hlen);
+ mtu -= t_hlen;
if (mtu < IPV4_MIN_MTU)
mtu = IPV4_MIN_MTU;
@@ -347,7 +347,7 @@ static struct ip_tunnel *ip_tunnel_creat
nt = netdev_priv(dev);
t_hlen = nt->hlen + sizeof(struct iphdr);
dev->min_mtu = ETH_MIN_MTU;
- dev->max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
+ dev->max_mtu = IP_MAX_MTU - t_hlen;
ip_tunnel_add(itn, nt);
return nt;
@@ -488,11 +488,10 @@ static int tnl_update_pmtu(struct net_de
int mtu;
tunnel_hlen = md ? tunnel_hlen : tunnel->hlen;
- pkt_size = skb->len - tunnel_hlen - dev->hard_header_len;
+ pkt_size = skb->len - tunnel_hlen;
if (df)
- mtu = dst_mtu(&rt->dst) - dev->hard_header_len
- - sizeof(struct iphdr) - tunnel_hlen;
+ mtu = dst_mtu(&rt->dst) - (sizeof(struct iphdr) + tunnel_hlen);
else
mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
@@ -972,7 +971,7 @@ int __ip_tunnel_change_mtu(struct net_de
{
struct ip_tunnel *tunnel = netdev_priv(dev);
int t_hlen = tunnel->hlen + sizeof(struct iphdr);
- int max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
+ int max_mtu = IP_MAX_MTU - t_hlen;
if (new_mtu < ETH_MIN_MTU)
return -EINVAL;
@@ -1149,10 +1148,9 @@ int ip_tunnel_newlink(struct net_device
mtu = ip_tunnel_bind_dev(dev);
if (tb[IFLA_MTU]) {
- unsigned int max = IP_MAX_MTU - dev->hard_header_len - nt->hlen;
+ unsigned int max = IP_MAX_MTU - (nt->hlen + sizeof(struct iphdr));
- mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU,
- (unsigned int)(max - sizeof(struct iphdr)));
+ mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU, max);
}
err = dev_set_mtu(dev, mtu);
^ permalink raw reply
* [PATCH 5.10 116/120] neighbour: Prevent a dead entry from updating gc_list
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chinmay Agarwal, Cong Wang,
David Ahern, Jakub Kicinski
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Chinmay Agarwal <chinagar@codeaurora.org>
commit eb4e8fac00d1e01ada5e57c05d24739156086677 upstream.
Following race condition was detected:
<CPU A, t0> - neigh_flush_dev() is under execution and calls
neigh_mark_dead(n) marking the neighbour entry 'n' as dead.
<CPU B, t1> - Executing: __netif_receive_skb() ->
__netif_receive_skb_core() -> arp_rcv() -> arp_process().arp_process()
calls __neigh_lookup() which takes a reference on neighbour entry 'n'.
<CPU A, t2> - Moves further along neigh_flush_dev() and calls
neigh_cleanup_and_release(n), but since reference count increased in t2,
'n' couldn't be destroyed.
<CPU B, t3> - Moves further along, arp_process() and calls
neigh_update()-> __neigh_update() -> neigh_update_gc_list(), which adds
the neighbour entry back in gc_list(neigh_mark_dead(), removed it
earlier in t0 from gc_list)
<CPU B, t4> - arp_process() finally calls neigh_release(n), destroying
the neighbour entry.
This leads to 'n' still being part of gc_list, but the actual
neighbour structure has been freed.
The situation can be prevented from happening if we disallow a dead
entry to have any possibility of updating gc_list. This is what the
patch intends to achieve.
Fixes: 9c29a2f55ec0 ("neighbor: Fix locking order for gc_list changes")
Signed-off-by: Chinmay Agarwal <chinagar@codeaurora.org>
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210127165453.GA20514@chinagar-linux.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/neighbour.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1245,13 +1245,14 @@ static int __neigh_update(struct neighbo
old = neigh->nud_state;
err = -EPERM;
- if (!(flags & NEIGH_UPDATE_F_ADMIN) &&
- (old & (NUD_NOARP | NUD_PERMANENT)))
- goto out;
if (neigh->dead) {
NL_SET_ERR_MSG(extack, "Neighbor entry is now dead");
+ new = old;
goto out;
}
+ if (!(flags & NEIGH_UPDATE_F_ADMIN) &&
+ (old & (NUD_NOARP | NUD_PERMANENT)))
+ goto out;
ext_learn_change = neigh_update_ext_learned(neigh, flags, ¬ify);
^ permalink raw reply
* [PATCH 5.10 109/120] x86/debug: Prevent data breakpoints on cpu_dr7
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lai Jiangshan, Thomas Gleixner
In-Reply-To: <20210208145818.395353822@linuxfoundation.org>
From: Lai Jiangshan <laijs@linux.alibaba.com>
commit 3943abf2dbfae9ea4d2da05c1db569a0603f76da upstream.
local_db_save() is called at the start of exc_debug_kernel(), reads DR7 and
disables breakpoints to prevent recursion.
When running in a guest (X86_FEATURE_HYPERVISOR), local_db_save() reads the
per-cpu variable cpu_dr7 to check whether a breakpoint is active or not
before it accesses DR7.
A data breakpoint on cpu_dr7 therefore results in infinite #DB recursion.
Disallow data breakpoints on cpu_dr7 to prevent that.
Fixes: 84b6a3491567a("x86/entry: Optimize local_db_save() for virt")
Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210204152708.21308-2-jiangshanlai@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/hw_breakpoint.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -307,6 +307,14 @@ static inline bool within_cpu_entry(unsi
(unsigned long)&per_cpu(cpu_tlbstate, cpu),
sizeof(struct tlb_state)))
return true;
+
+ /*
+ * When in guest (X86_FEATURE_HYPERVISOR), local_db_save()
+ * will read per-cpu cpu_dr7 before clear dr7 register.
+ */
+ if (within_area(addr, end, (unsigned long)&per_cpu(cpu_dr7, cpu),
+ sizeof(cpu_dr7)))
+ return true;
}
return false;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox