2021-03-19 12:22:54

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 0/8] 4.19.182-rc1 review

This is the start of the stable review cycle for the 4.19.182 release.
There are 8 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Mar 2021 12:17:37 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.182-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.19.182-rc1

Florian Fainelli <[email protected]>
net: dsa: b53: Support setting learning on port

DENG Qingfang <[email protected]>
net: dsa: tag_mtk: fix 802.1ad VLAN egress

Piotr Krysiuk <[email protected]>
bpf: Add sanity check for upper ptr_limit

Piotr Krysiuk <[email protected]>
bpf: Simplify alu_limit masking for pointer arithmetic

Piotr Krysiuk <[email protected]>
bpf: Fix off-by-one for area size in creating mask to left

Piotr Krysiuk <[email protected]>
bpf: Prohibit alu ops for pointer types not defining ptr_limit

Suzuki K Poulose <[email protected]>
KVM: arm64: nvhe: Save the SPE context early

Jan Kara <[email protected]>
ext4: check journal inode extents more carefully


-------------

Diffstat:

Makefile | 4 ++--
arch/arm64/include/asm/kvm_hyp.h | 3 +++
arch/arm64/kvm/hyp/debug-sr.c | 24 +++++++++++++---------
arch/arm64/kvm/hyp/switch.c | 4 +++-
drivers/net/dsa/b53/b53_common.c | 19 ++++++++++++++++++
drivers/net/dsa/b53/b53_regs.h | 1 +
drivers/net/dsa/bcm_sf2.c | 5 -----
fs/ext4/block_validity.c | 43 ++++++++++++++++++++--------------------
fs/ext4/ext4.h | 6 +++---
fs/ext4/extents.c | 16 ++++++---------
fs/ext4/indirect.c | 6 ++----
fs/ext4/inode.c | 5 ++---
fs/ext4/mballoc.c | 4 ++--
kernel/bpf/verifier.c | 33 +++++++++++++++++++-----------
net/dsa/tag_mtk.c | 19 ++++++++++++------
15 files changed, 114 insertions(+), 78 deletions(-)



2021-03-19 12:23:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 2/8] KVM: arm64: nvhe: Save the SPE context early

From: Suzuki K Poulose <[email protected]>

commit b96b0c5de685df82019e16826a282d53d86d112c upstream

The nVHE KVM hyp drains and disables the SPE buffer, before
entering the guest, as the EL1&0 translation regime
is going to be loaded with that of the guest.

But this operation is performed way too late, because :
- The owning translation regime of the SPE buffer
is transferred to EL2. (MDCR_EL2_E2PB == 0)
- The guest Stage1 is loaded.

Thus the flush could use the host EL1 virtual address,
but use the EL2 translations instead of host EL1, for writing
out any cached data.

Fix this by moving the SPE buffer handling early enough.
The restore path is doing the right thing.

Cc: [email protected] # v4.19
Cc: Christoffer Dall <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Alexandru Elisei <[email protected]>
Signed-off-by: Suzuki K Poulose <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm64/include/asm/kvm_hyp.h | 3 +++
arch/arm64/kvm/hyp/debug-sr.c | 24 +++++++++++++++---------
arch/arm64/kvm/hyp/switch.c | 4 +++-
3 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 384c34397619..5f52d6d670e9 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -144,6 +144,9 @@ void __sysreg32_restore_state(struct kvm_vcpu *vcpu);

void __debug_switch_to_guest(struct kvm_vcpu *vcpu);
void __debug_switch_to_host(struct kvm_vcpu *vcpu);
+void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu);
+void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu);
+

void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
index 50009766e5e5..3c5414633bb7 100644
--- a/arch/arm64/kvm/hyp/debug-sr.c
+++ b/arch/arm64/kvm/hyp/debug-sr.c
@@ -149,6 +149,21 @@ static void __hyp_text __debug_restore_state(struct kvm_vcpu *vcpu,
write_sysreg(ctxt->sys_regs[MDCCINT_EL1], mdccint_el1);
}

+void __hyp_text __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
+{
+ /*
+ * Non-VHE: Disable and flush SPE data generation
+ * VHE: The vcpu can run, but it can't hide.
+ */
+ __debug_save_spe_nvhe(&vcpu->arch.host_debug_state.pmscr_el1);
+
+}
+
+void __hyp_text __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
+{
+ __debug_restore_spe_nvhe(vcpu->arch.host_debug_state.pmscr_el1);
+}
+
void __hyp_text __debug_switch_to_guest(struct kvm_vcpu *vcpu)
{
struct kvm_cpu_context *host_ctxt;
@@ -156,13 +171,6 @@ void __hyp_text __debug_switch_to_guest(struct kvm_vcpu *vcpu)
struct kvm_guest_debug_arch *host_dbg;
struct kvm_guest_debug_arch *guest_dbg;

- /*
- * Non-VHE: Disable and flush SPE data generation
- * VHE: The vcpu can run, but it can't hide.
- */
- if (!has_vhe())
- __debug_save_spe_nvhe(&vcpu->arch.host_debug_state.pmscr_el1);
-
if (!(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY))
return;

@@ -182,8 +190,6 @@ void __hyp_text __debug_switch_to_host(struct kvm_vcpu *vcpu)
struct kvm_guest_debug_arch *host_dbg;
struct kvm_guest_debug_arch *guest_dbg;

- if (!has_vhe())
- __debug_restore_spe_nvhe(vcpu->arch.host_debug_state.pmscr_el1);

if (!(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY))
return;
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 15312e429b7d..1d16ce0b7e0d 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -560,6 +560,7 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
guest_ctxt = &vcpu->arch.ctxt;

__sysreg_save_state_nvhe(host_ctxt);
+ __debug_save_host_buffers_nvhe(vcpu);

__activate_traps(vcpu);
__activate_vm(kern_hyp_va(vcpu->kvm));
@@ -599,11 +600,12 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED)
__fpsimd_save_fpexc32(vcpu);

+ __debug_switch_to_host(vcpu);
/*
* This must come after restoring the host sysregs, since a non-VHE
* system may enable SPE here and make use of the TTBRs.
*/
- __debug_switch_to_host(vcpu);
+ __debug_restore_host_buffers_nvhe(vcpu);

return exit_code;
}
--
2.30.1



2021-03-19 19:20:42

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 0/8] 4.19.182-rc1 review

Hi!

> This is the start of the stable review cycle for the 4.19.182 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (660.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-03-19 21:24:01

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 0/8] 4.19.182-rc1 review

On Fri, Mar 19, 2021 at 01:18:19PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.182 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Mar 2021 12:17:37 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 155 pass: 154 fail: 1
Failed builds:
x86_64:tools/perf
Qemu test results:
total: 420 pass: 420 fail: 0

jvmti/jvmti_agent.c:48:21: error: static declaration of ‘gettid’ follows non-static declaration
48 | static inline pid_t gettid(void)
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from jvmti/jvmti_agent.c:33:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here

The tools/perf error is not new. It is seen because I started updating
my servers to Ubuntu 20.0. The following patches would be needed to fix the
problem in v4.19.y.

8feb8efef97a tools build feature: Check if get_current_dir_name() is available
11c6cbe706f2 tools build feature: Check if eventfd() is available
4541a8bb13a8 tools build: Check if gettid() is available before providing helper
fc8c0a992233 perf tools: Use %define api.pure full instead of %pure-parser

The first two patches prevent a conflict with the third patch, and the
last patch fixes an unrelated build warning.

Older kernels are also affected. The list of patches needed for v4.14.y is:

0ada120c883d perf: Make perf able to build with latest libbfd
(this patch is in v4.9.y but not in v4.14.y)
25ab5abf5b14 tools build feature: Check if pthread_barrier_t is available
8feb8efef97a tools build feature: Check if get_current_dir_name() is available
11c6cbe706f2 tools build feature: Check if eventfd() is available
4541a8bb13a8 tools build: Check if gettid() is available before providing helper
fc8c0a992233 perf tools: Use %define api.pure full instead of %pure-parser

I tried to fix the problem in v4.9.y and v4.4.y as well, but that is pretty
much hopeless. I'll have to stop testing perf builds for those kernels.

Anyway,

Tested-by: Guenter Roeck <[email protected]>

Guenter

2021-03-20 11:17:42

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 0/8] 4.19.182-rc1 review

On Fri, 19 Mar 2021 at 17:48, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.182 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Mar 2021 12:17:37 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.182-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

Summary
------------------------------------------------------------------------

kernel: 4.19.182-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 7281e11121f6fb47ea1e757b7781c5c15e3781fe
git describe: v4.19.181-9-g7281e11121f6
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.181-9-g7281e11121f6

No regressions (compared to build v4.19.181)

No fixes (compared to build v4.19.181)


Ran 58666 total tests in the following environments and test suites.

Environments
--------------
- arm
- arm64
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- nxp-ls2088-64k_page_size
- powerpc
- qemu-arm-debug
- qemu-arm64-clang
- qemu-arm64-debug
- qemu-arm64-kasan
- qemu-i386-debug
- qemu-x86_64-clang
- qemu-x86_64-debug
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- s390
- sparc
- x15 - arm
- x86_64
- x86-kasan
- x86_64

Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kselftest-
* kselftest-android
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* perf
* v4l2-compliance
* fwts
* kselftest-bpf
* libhugetlbfs
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* kselftest-kexec
* kselftest-vm
* kselftest-x86
* ltp-containers-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-open-posix-tests
* kvm-unit-tests
* rcutorture
* kselftest-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* ssuite

--
Linaro LKFT
https://lkft.linaro.org

2021-03-20 11:50:49

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 0/8] 4.19.182-rc1 review

On Fri, Mar 19, 2021 at 08:17:22PM +0100, Pavel Machek wrote:
> Hi!
>
> > This is the start of the stable review cycle for the 4.19.182 release.
> > There are 8 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
>
> CIP testing did not find any problems here:
>
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y
>
> Tested-by: Pavel Machek (CIP) <[email protected]>

Thanks for testing!

2021-03-20 11:57:21

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 0/8] 4.19.182-rc1 review

On Fri, Mar 19, 2021 at 02:21:46PM -0700, Guenter Roeck wrote:
> On Fri, Mar 19, 2021 at 01:18:19PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.182 release.
> > There are 8 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun, 21 Mar 2021 12:17:37 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 155 pass: 154 fail: 1
> Failed builds:
> x86_64:tools/perf
> Qemu test results:
> total: 420 pass: 420 fail: 0
>
> jvmti/jvmti_agent.c:48:21: error: static declaration of ‘gettid’ follows non-static declaration
> 48 | static inline pid_t gettid(void)
> | ^~~~~~
> In file included from /usr/include/unistd.h:1170,
> from jvmti/jvmti_agent.c:33:
> /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here
>
> The tools/perf error is not new. It is seen because I started updating
> my servers to Ubuntu 20.0. The following patches would be needed to fix the
> problem in v4.19.y.
>
> 8feb8efef97a tools build feature: Check if get_current_dir_name() is available
> 11c6cbe706f2 tools build feature: Check if eventfd() is available
> 4541a8bb13a8 tools build: Check if gettid() is available before providing helper
> fc8c0a992233 perf tools: Use %define api.pure full instead of %pure-parser
>
> The first two patches prevent a conflict with the third patch, and the
> last patch fixes an unrelated build warning.
>
> Older kernels are also affected. The list of patches needed for v4.14.y is:
>
> 0ada120c883d perf: Make perf able to build with latest libbfd
> (this patch is in v4.9.y but not in v4.14.y)
> 25ab5abf5b14 tools build feature: Check if pthread_barrier_t is available
> 8feb8efef97a tools build feature: Check if get_current_dir_name() is available
> 11c6cbe706f2 tools build feature: Check if eventfd() is available
> 4541a8bb13a8 tools build: Check if gettid() is available before providing helper
> fc8c0a992233 perf tools: Use %define api.pure full instead of %pure-parser
>
> I tried to fix the problem in v4.9.y and v4.4.y as well, but that is pretty
> much hopeless. I'll have to stop testing perf builds for those kernels.

I'll suck these in for the next round of releases, thanks.

and thanks for testing.

greg k-h

2021-03-21 02:27:41

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 4.19 0/8] 4.19.182-rc1 review



On 2021/3/19 20:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.182 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Mar 2021 12:17:37 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.182-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Tested on arm64 and x86 for 4.19.182-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.19.y
Version: 4.19.182-rc1
Commit: 7281e11121f6fb47ea1e757b7781c5c15e3781fe
Compiler: gcc version 7.3.0 (GCC)

arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 4688
passed: 4688
failed: 0
timeout: 0
--------------------------------------------------------------------

x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 4688
passed: 4688
failed: 0
timeout: 0
--------------------------------------------------------------------

Tested-by: Hulk Robot <[email protected]>