hulk inclusion
category: feature
bugzilla: 49592
CVE: NA

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

This feature is based on "arm64: perf: add nmi support for pmu" patch
series. It can be enabled by passing the kernel cmdline parameter
"hardlockup_enable=on", or the perf NMI watchdog will be disabled
defaultly.
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: config
bugzilla: 47727
CVE: NA

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

We enable haltpoll by default for the improvement of performance.
X86 has been supported. Now, we will provide it on ARM.
Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com>
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 47727
CVE: NA

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

Add support for cpuidle-haltpoll driver for ARM.
Allow arm to use the couidle-haltpoll driver.
Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com>
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 47727
CVE: NA

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

boot_option_idle_override is defined only in x86/ia64.  Since haltpoll
supports x86 and arm64, let's check boot_option_idle_override only in
x86.
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 47727
CVE: NA

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

Currently, ARM does not support kvm_para* of KVM_GUEST. We provide
some definitions of kvm_para* functions, although it is only a
simple return.
Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 47727
CVE: NA

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

Use arch_cpu_idle() to replace default_idle() in default_enter_idle().
default_idle() is defined only in x86.
Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 47727
CVE: NA

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

When it is to wake up a task in a remote cpu shared LLC , we can
simply set need_resched flag, waking up a cpu that is in polling
idle. This wakeup action does not require an IPI.

But the premise is that it need to support _TIF_POLLING_NRFLAG
Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com>
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 48052
CVE: NA

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

Add KVM_CAP_ARM_CPU_FEATURE extension for userpace to check whether KVM
supports to set CPU features in AArch64.
Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 48052
CVE: NA

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

Since 23711a5e ("KVM: arm64: Allow setting of ID_AA64PFR0_EL1.CSV2
from userspace"), ID_AA64PFR0_EL1 uses a separate set_user callback.  We
should remove some check in the callback to make ID_AA64PFR0_EL1
configurable.
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 48052
CVE: NA

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

It's time to make ID registers configurable.  When userspace (but not
guest) want to set the values of ID registers, save the value in
kvm_arch_vcpu so that guest can read the modified values.
Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 48052
CVE: NA

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

To emulate the ID registers, we need a place to storage the values of
the ID regsiters.  Maybe putting in kvm_arch_vcpu is a good idea.

This commit has no functional changes but only code refactor.  When
initializing a vcpu, get the values of the ID registers from
arm64_ftr_regs and storage them in kvm_arch_vcpu.  And we just read
the value from kvm_arch_vcpu when getting/setting the value of the ID
regs.
Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 48052
CVE: NA

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

If we want to emulate ID registers, we need to initialize ID registers
firstly.  This commit is to add a helper function to traverse
arm64_ftr_regs so that we can initialize ID registers from
arm64_ftr_regs.
Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NPeng Liang <liangpeng10@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

Add tracepoints for PV qspinlock
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

Linux kernel builds were run in KVM guest on HiSilicon Kunpeng920 system.
VM guests were set up with 32, 48 and 64 vCPUs on the 32 physical CPUs.
The kernel build (make -j<n>) was done in a VM with unpinned vCPUs 3
times with the best time selected and <n> is the number of vCPUs
available. The build times of the original linux 4.19.87, pvqspinlock
with various number of vCPUs are as follows:

  Kernel        32 vCPUs    48 vCPUs    60 vCPUs
  ----------    --------    --------    --------
  4.19.87       342.336s    602.048s    950.340s
  pvqsinlock    341.366s    376.135s    437.037s
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

As kernel has used this interface, so lets support it.
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

Implement the service call for waking up a WFI state vCPU.
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

A new hypercall interface function is provided for the guest to kick WFI
state vCPU.
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

Support the vcpu_is_preempted() functionality under KVM/arm64. This will
enhance lock performance on overcommitted hosts (more runnable vCPUs
than physical CPUs in the system) as doing busy waits for preempted
vCPUs will hurt system performance far worse than early yielding.

unix benchmark result:
  host:  kernel 4.19.87, HiSilicon Kunpeng920, 8 CPUs
  guest: kernel 4.19.87, 16 vCPUs

               test-case                |    after-patch    |   before-patch
----------------------------------------+-------------------+------------------
 Dhrystone 2 using register variables   | 338955728.5 lps   | 339266319.5 lps
 Double-Precision Whetstone             |     30634.9 MWIPS |     30884.4 MWIPS
 Execl Throughput                       |      6753.2 lps   |      3580.1 lps
 File Copy 1024 bufsize 2000 maxblocks  |    490048.0 KBps  |    313282.3 KBps
 File Copy 256 bufsize 500 maxblocks    |    129662.5 KBps  |     83550.7 KBps
 File Copy 4096 bufsize 8000 maxblocks  |   1552551.5 KBps  |    814327.0 KBps
 Pipe Throughput                        |   8976422.5 lps   |   9048628.4 lps
 Pipe-based Context Switching           |    258641.7 lps   |    252925.9 lps
 Process Creation                       |      5312.2 lps   |      4507.9 lps
 Shell Scripts (1 concurrent)           |      8704.2 lpm   |      6720.9 lpm
 Shell Scripts (8 concurrent)           |      1708.8 lpm   |       607.2 lpm
 System Call Overhead                   |   3714444.7 lps   |   3746386.8 lps
----------------------------------------+-------------------+------------------
 System Benchmarks Index Score          |      2270.6       |      1679.2
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

This is to fix some lock holder preemption issues. Some other locks
implementation do a spin loop before acquiring the lock itself.
Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It
takes the CPU as parameter and return true if the CPU is preempted.
Then kernel can break the spin loops upon the retval of vcpu_is_preempted.

As kernel has used this interface, So lets support it.
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

Implement the service call for configuring a shared structure between a
vCPU and the hypervisor in which the hypervisor can tell the vCPU that is
running or not.
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

This provides a mechanism for querying which paravirtualized sched
features are available in this hypervisor.

Add some SMCCC compatible hypercalls for PV sched features:
  PV_SCHED_FEATURES:       0xC5000090
  PV_SCHED_IPA_INIT:       0xC5000091
  PV_SCHED_IPA_RELEASE:    0xC5000092

Also add the header file which defines the ABI for the paravirtualized
sched features we're about to add.
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: feature
bugzilla: 47624
CVE: NA

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

Introduce a paravirtualization interface for KVM/arm64 to PV-sched.

A hypercall interface is provided for the guest to interrogate the
hypervisor's support for this interface and the location of the shared
memory structures.
Signed-off-by: NZengruan Ye <yezengruan@huawei.com>
Reviewed-by: NZhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 47994
CVE: NA

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

Fix the following compile error when CONFIG_NUMA is disabled.

arch/arm64/kernel/acpi.c: In function ‘acpi_map_cpu’:
arch/arm64/kernel/acpi.c:415:3: error: implicit declaration of function ‘numa_add_cpu’; did you mean ‘be64_add_cpu’? [-Werror=implicit-function-declaration]
   numa_add_cpu(cpu);
   ^~~~~~~~~~~~
   be64_add_cpu
arch/arm64/kernel/acpi.c: In function ‘acpi_unmap_cpu’:
arch/arm64/kernel/acpi.c:428:2: error: implicit declaration of function ‘numa_clear_node’; did you mean ‘pmd_clear_huge’? [-Werror=implicit-function-declaration]
  numa_clear_node(cpu);
  ^~~~~~~~~~~~~~~
  pmd_clear_huge
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 47994
CVE: NA

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

To support CPU hotplug, we need to implement 'acpi_(un)map_cpu()' and
'arch_(un)register_cpu()' for ARM64. These functions are called in
'acpi_processor_hotadd_init()/acpi_processor_remove()' when the CPU is hot
added into or hot removed from the system.

Note: This patch only support core hotplug and does not support socket
hotplug because we don't support live configuration of GIC.
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Acked-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 47994
CVE: NA

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

We set 'cpu_possible_mask' based on the enabled GICC node in MADT. If
the GICC node is disabled, we will skip initializing the kernel data
structure for that CPU.

To support CPU hotplug, we need to initialize some CPU related data
structure in advance. This patch mark all the GICC nodes as possible CPU
and only these enabled GICC nodes as present CPU.
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Acked-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.12-rc1
commit 4ceddce5
category: bugfix
bugzilla: 51406
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ceddce55eb35d15b0f87f5dcf6f0058fd15d3a4

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

There's an I/O error on fsync() in a detached loop device
if it has been previously attached.

The issue is write cache is enabled in the attach path in
loop_configure() but it isn't disabled in the detach path;
thus it remains enabled in the block device regardless of
whether it is attached or not.

Now fsync() can get an I/O request that will just be failed
later in loop_queue_rq() as device's state is not 'Lo_bound'.

So, disable write cache in the detach path.

Do so based on the queue flag, not the loop device flag for
read-only (used to enable) as the queue flag can be changed
via sysfs even on read-only loop devices (e.g., losetup -r.)

Test-case:

    # DEV=/dev/loop7

    # IMG=/tmp/image
    # truncate --size 1M $IMG

    # losetup $DEV $IMG
    # losetup -d $DEV

Before:

    # strace -e fsync parted -s $DEV print 2>&1 | grep fsync
    fsync(3)                                = -1 EIO (Input/output error)
    Warning: Error fsyncing/closing /dev/loop7: Input/output error
    [  982.529929] blk_update_request: I/O error, dev loop7, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0

After:

    # strace -e fsync parted -s $DEV print 2>&1 | grep fsync
    fsync(3)                                = 0
Co-developed-by: NEric Desrochers <eric.desrochers@canonical.com>
Signed-off-by: NEric Desrochers <eric.desrochers@canonical.com>
Signed-off-by: NMauricio Faria de Oliveira <mfo@canonical.com>
Tested-by: NGabriel Krisman Bertazi <krisman@collabora.com>
Reviewed-by: NMing Lei <ming.lei@redhat.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NYufen Yu <yuyufen@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 50623
CVE: NA

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

When we print system information by echo 't' into 'sysrq-trigger' on
several cores at the same time, we got the following calltrace.

[ 1352.854632] NMI watchdog: Watchdog detected hard LOCKUP on cpu 6
[ 1352.854633] Modules linked in: nf_log_arp nf_log_ipv6 nf_log_ipv4 nf_log_common binfmt_misc salsa20_generic camellia_generic cast6_generic cast_common rfkill serpent_generic twofish_generic twofish_common xts lrw tgr192 wp512 rmd320 rmd256 rmd160 rmd128 md4 sha512_generic loop jprob(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter vfat fat hns_roce_hw_v2 hns_roce ib_core aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce sha2_ce ipmi_ssif ofpart sha256_arm64 sha1_ce cmdlinepart
[ 1352.854649]  hi_sfc ses enclosure mtd sg sbsa_gwdt ipmi_si ipmi_devintf ipmi_msghandler spi_dw_mmio sch_fq_codel ip_tables ext4 mbcache jbd2 sr_mod cdrom sd_mod realtek hclge hisi_sas_v3_hw hisi_sas_main ahci libsas libahci hns3 hinic libata usb_storage hnae3 megaraid_sas scsi_transport_sas i2c_designware_platform i2c_designware_core dm_multipath dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_vs]
[ 1352.854658] CPU: 6 PID: 220569 Comm: sh Kdump: loaded Tainted: G           OEL    4.19.90-vhulk2001.1.0.0026.aarch64 #1
[ 1352.854659] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 1.06 10/29/2019
[ 1352.854659] pstate: 80400089 (Nzcv daIf +PAN -UAO)
[ 1352.854660] pc : queued_spin_lock_slowpath+0x1d8/0x2e0
[ 1352.854660] lr : print_cpu+0x414/0x690
[ 1352.854660] sp : ffff0001743afb80
[ 1352.854661] x29: ffff0001743afb80 x28: ffff805fcef6e880
[ 1352.854662] x27: 0000000000000000 x26: 0000000000000000
[ 1352.854662] x25: ffff000008cab000 x24: ffff000008cab000
[ 1352.854663] x23: 0000000000000000 x22: 0000000000000000
[ 1352.854664] x21: ffff000009478000 x20: 0000000000900001
[ 1352.854664] x19: ffff000009478d20 x18: ffffffffffffffff
[ 1352.854665] x17: 0000000000000000 x16: 0000000000000000
[ 1352.854666] x15: ffff000009273708 x14: ffff00000947af60
[ 1352.854667] x13: ffff00000947abab x12: ffff00000929d000
[ 1352.854668] x11: 0000000000006fc8 x10: ffff00000947a1c0
[ 1352.854668] x9 : 0000000000000001 x8 : 0000000000000000
[ 1352.854669] x7 : ffff0000092737c8 x6 : ffff803fffc9e1c0
[ 1352.854670] x5 : 0000000000000000 x4 : ffff803fffc9e1c0
[ 1352.854671] x3 : ffff000008f5e000 x2 : 00000000001c0000
[ 1352.854671] x1 : 0000000000000000 x0 : ffff803fffc9e1c8
[ 1352.854672] Call trace:
[ 1352.854673]  queued_spin_lock_slowpath+0x1d8/0x2e0
[ 1352.854673]  print_cpu+0x414/0x690
[ 1352.854673]  sysrq_sched_debug_show+0x50/0x80
[ 1352.854674]  show_state_filter+0xc0/0xd0
[ 1352.854674]  sysrq_handle_showstate+0x18/0x28
[ 1352.854674]  __handle_sysrq+0xa0/0x190
[ 1352.854675]  write_sysrq_trigger+0x70/0x88
[ 1352.854675]  proc_reg_write+0x80/0xd8
[ 1352.854675]  __vfs_write+0x60/0x190
[ 1352.854676]  vfs_write+0xac/0x1c0
[ 1352.854676]  ksys_write+0x74/0xf0
[ 1352.854676]  __arm64_sys_write+0x24/0x30
[ 1352.854677]  el0_svc_common+0x78/0x130
[ 1352.854677]  el0_svc_handler+0x38/0x78
[ 1352.854677]  el0_svc+0x8/0xc
[ 1352.854678] Kernel panic - not syncing: Hard LOCKUP
[ 1352.854679] CPU: 6 PID: 220569 Comm: sh Kdump: loaded Tainted: G           OEL    4.19.90-vhulk2001.1.0.0026.aarch64 #1
[ 1352.854679] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 1.06 10/29/2019
[ 1352.854679] Call trace:
[ 1352.854680]  dump_backtrace+0x0/0x198
[ 1352.854680]  show_stack+0x24/0x30
[ 1352.854681]  dump_stack+0xa4/0xc4
[ 1352.854681]  panic+0x130/0x304
[ 1352.854681]  __stack_chk_fail+0x0/0x28
[ 1352.854682]  watchdog_hardlockup_check+0x138/0x140
[ 1352.854682]  sdei_watchdog_callback+0x20/0x30
[ 1352.854682]  sdei_event_handler+0x50/0xf0
[ 1352.854683]  __sdei_handler+0xd8/0x228
[ 1352.854683]  __sdei_asm_handler+0xbc/0x134
[ 1352.854683]  queued_spin_lock_slowpath+0x1d8/0x2e0
[ 1352.854684]  print_cpu+0x414/0x690
[ 1352.854684]  sysrq_sched_debug_show+0x50/0x80
[ 1352.854684]  show_state_filter+0xc0/0xd0
[ 1352.854685]  sysrq_handle_showstate+0x18/0x28
[ 1352.854685]  __handle_sysrq+0xa0/0x190
[ 1352.854685]  write_sysrq_trigger+0x70/0x88
[ 1352.854686]  proc_reg_write+0x80/0xd8
[ 1352.854686]  __vfs_write+0x60/0x190
[ 1352.854686]  vfs_write+0xac/0x1c0
[ 1352.854687]  ksys_write+0x74/0xf0
[ 1352.854687]  __arm64_sys_write+0x24/0x30
[ 1352.854687]  el0_svc_common+0x78/0x130
[ 1352.854688]  el0_svc_handler+0x38/0x78
[ 1352.854688]  el0_svc+0x8/0xc

It is because there are many processes in the system. 'print_cpu()'
aquires 'sched_debug_lock', print some information, and releases
'sched_debug_lock'. This procedure takes about 4 seconds in our
testcase. When four cores concurrently print system info by sysrq, it
will takes the last core 12 seconds to get the spinlock. This will
cause a hardlockup.
Signed-off-by: NKai Shen <shenkai8@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.12-rc1
commit 90ada91f
category: bugfix
bugzilla: 51358
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90ada91f4610c5ef11bc52576516d96c496fc3f1

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

KASAN reports a BUG when download file in jffs2 filesystem.It is
because when dstlen == 1, cpage_out will write array out of bounds.
Actually, data will not be compressed in jffs2_zlib_compress() if
data's length less than 4.

[  393.799778] BUG: KASAN: slab-out-of-bounds in jffs2_rtime_compress+0x214/0x2f0 at addr ffff800062e3b281
[  393.809166] Write of size 1 by task tftp/2918
[  393.813526] CPU: 3 PID: 2918 Comm: tftp Tainted: G    B           4.9.115-rt93-EMBSYS-CGEL-6.1.R6-dirty #1
[  393.823173] Hardware name: LS1043A RDB Board (DT)
[  393.827870] Call trace:
[  393.830322] [<ffff20000808c700>] dump_backtrace+0x0/0x2f0
[  393.835721] [<ffff20000808ca04>] show_stack+0x14/0x20
[  393.840774] [<ffff2000086ef700>] dump_stack+0x90/0xb0
[  393.845829] [<ffff20000827b19c>] kasan_object_err+0x24/0x80
[  393.851402] [<ffff20000827b404>] kasan_report_error+0x1b4/0x4d8
[  393.857323] [<ffff20000827bae8>] kasan_report+0x38/0x40
[  393.862548] [<ffff200008279d44>] __asan_store1+0x4c/0x58
[  393.867859] [<ffff2000084ce2ec>] jffs2_rtime_compress+0x214/0x2f0
[  393.873955] [<ffff2000084bb3b0>] jffs2_selected_compress+0x178/0x2a0
[  393.880308] [<ffff2000084bb530>] jffs2_compress+0x58/0x478
[  393.885796] [<ffff2000084c5b34>] jffs2_write_inode_range+0x13c/0x450
[  393.892150] [<ffff2000084be0b8>] jffs2_write_end+0x2a8/0x4a0
[  393.897811] [<ffff2000081f3008>] generic_perform_write+0x1c0/0x280
[  393.903990] [<ffff2000081f5074>] __generic_file_write_iter+0x1c4/0x228
[  393.910517] [<ffff2000081f5210>] generic_file_write_iter+0x138/0x288
[  393.916870] [<ffff20000829ec1c>] __vfs_write+0x1b4/0x238
[  393.922181] [<ffff20000829ff00>] vfs_write+0xd0/0x238
[  393.927232] [<ffff2000082a1ba8>] SyS_write+0xa0/0x110
[  393.932283] [<ffff20000808429c>] __sys_trace_return+0x0/0x4
[  393.937851] Object at ffff800062e3b280, in cache kmalloc-64 size: 64
[  393.944197] Allocated:
[  393.946552] PID = 2918
[  393.948913]  save_stack_trace_tsk+0x0/0x220
[  393.953096]  save_stack_trace+0x18/0x20
[  393.956932]  kasan_kmalloc+0xd8/0x188
[  393.960594]  __kmalloc+0x144/0x238
[  393.963994]  jffs2_selected_compress+0x48/0x2a0
[  393.968524]  jffs2_compress+0x58/0x478
[  393.972273]  jffs2_write_inode_range+0x13c/0x450
[  393.976889]  jffs2_write_end+0x2a8/0x4a0
[  393.980810]  generic_perform_write+0x1c0/0x280
[  393.985251]  __generic_file_write_iter+0x1c4/0x228
[  393.990040]  generic_file_write_iter+0x138/0x288
[  393.994655]  __vfs_write+0x1b4/0x238
[  393.998228]  vfs_write+0xd0/0x238
[  394.001543]  SyS_write+0xa0/0x110
[  394.004856]  __sys_trace_return+0x0/0x4
[  394.008684] Freed:
[  394.010691] PID = 2918
[  394.013051]  save_stack_trace_tsk+0x0/0x220
[  394.017233]  save_stack_trace+0x18/0x20
[  394.021069]  kasan_slab_free+0x88/0x188
[  394.024902]  kfree+0x6c/0x1d8
[  394.027868]  jffs2_sum_write_sumnode+0x2c4/0x880
[  394.032486]  jffs2_do_reserve_space+0x198/0x598
[  394.037016]  jffs2_reserve_space+0x3f8/0x4d8
[  394.041286]  jffs2_write_inode_range+0xf0/0x450
[  394.045816]  jffs2_write_end+0x2a8/0x4a0
[  394.049737]  generic_perform_write+0x1c0/0x280
[  394.054179]  __generic_file_write_iter+0x1c4/0x228
[  394.058968]  generic_file_write_iter+0x138/0x288
[  394.063583]  __vfs_write+0x1b4/0x238
[  394.067157]  vfs_write+0xd0/0x238
[  394.070470]  SyS_write+0xa0/0x110
[  394.073783]  __sys_trace_return+0x0/0x4
[  394.077612] Memory state around the buggy address:
[  394.082404]  ffff800062e3b180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[  394.089623]  ffff800062e3b200: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[  394.096842] >ffff800062e3b280: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  394.104056]                    ^
[  394.107283]  ffff800062e3b300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[  394.114502]  ffff800062e3b380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[  394.121718] ==================================================================
Signed-off-by: NYang Yang <yang.yang29@zte.com.cn>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NLuo Meng <luomeng12@huawei.com>
Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit de1126ea44bb259afa9b74a25fed0255ecdaa756
bugzilla: 51363

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

commit 05946d4b upstream.

smb311_update_preauth_hash() uses the shash in server->secmech without
appropriate locking, and this can lead to sessions corrupting each
other's preauth hashes.

The following script can easily trigger the problem:

	#!/bin/sh -e

	NMOUNTS=10
	for i in $(seq $NMOUNTS);
		mkdir -p /tmp/mnt$i
		umount /tmp/mnt$i 2>/dev/null || :
	done
	while :; do
		for i in $(seq $NMOUNTS); do
			mount -t cifs //192.168.0.1/test /tmp/mnt$i -o ... &
		done
		wait
		for i in $(seq $NMOUNTS); do
			umount /tmp/mnt$i
		done
	done

Usually within seconds this leads to one or more of the mounts failing
with the following errors, and a "Bad SMB2 signature for message" is
seen in the server logs:

 CIFS: VFS: \\192.168.0.1 failed to connect to IPC (rc=-13)
 CIFS: VFS: cifs_mount failed w/return code = -13

Fix it by holding the server mutex just like in the other places where
the shashes are used.

Fixes: 8bd68c6e ("CIFS: implement v3.11 preauth integrity")
Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
CC: <stable@vger.kernel.org>
Reviewed-by: NAurelien Aptel <aaptel@suse.com>
Signed-off-by: NSteve French <stfrench@microsoft.com>
[aaptel: backport to kernel without CIFS_SESS_OP]
Signed-off-by: NAurelien Aptel <aaptel@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 21536d7b7e6f58a2a7b3af3909c5150fe1fceb8c
bugzilla: 51363

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

commit dd926880 upstream.

Architectures that describe the CPU topology in devicetree and do not have
an identity mapping between physical and logical CPU ids must override the
default implementation of arch_match_cpu_phys_id().

Failing to do so breaks CPU devicetree-node lookups using of_get_cpu_node()
and of_cpu_device_node_get() which several drivers rely on. It also causes
the CPU struct devices exported through sysfs to point to the wrong
devicetree nodes.

On x86, CPUs are described in devicetree using their APIC ids and those
do not generally coincide with the logical ids, even if CPU0 typically
uses APIC id 0.

Add the missing implementation of arch_match_cpu_phys_id() so that CPU-node
lookups work also with SMP.

Apart from fixing the broken sysfs devicetree-node links this likely does
not affect current users of mainline kernels on x86.

Fixes: 4e07db9c ("x86/devicetree: Use CPU description from Device Tree")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210312092033.26317-1-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 95247d24c4d4973146a9e7175ec0803f734cf50e
bugzilla: 51363

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

commit 81e2073c upstream.

With interrupt force threading all device interrupt handlers are invoked
from kernel threads. Contrary to hard interrupt context the invocation only
disables bottom halfs, but not interrupts. This was an oversight back then
because any code like this will have an issue:

thread(irq_A)
  irq_handler(A)
    spin_lock(&foo->lock);

interrupt(irq_B)
  irq_handler(B)
    spin_lock(&foo->lock);

This has been triggered with networking (NAPI vs. hrtimers) and console
drivers where printk() happens from an interrupt which interrupted the
force threaded handler.

Now people noticed and started to change the spin_lock() in the handler to
spin_lock_irqsave() which affects performance or add IRQF_NOTHREAD to the
interrupt request which in turn breaks RT.

Fix the root cause and not the symptom and disable interrupts before
invoking the force threaded handler which preserves the regular semantics
and the usefulness of the interrupt force threading as a general debugging
tool.

For not RT this is not changing much, except that during the execution of
the threaded handler interrupts are delayed until the handler
returns. Vs. scheduling and softirq processing there is no difference.

For RT kernels there is no issue.

Fixes: 8d32a307 ("genirq: Provide forced interrupt threading")
Reported-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NJohan Hovold <johan@kernel.org>
Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 80b2787789afef0a98e64eb9a1a9203f4a83ff99
bugzilla: 51363

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

commit 9ceee7d0 upstream.

In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next
use the unmapped rsv. Use the unmapped pages will cause segment
fault.

Fixes: 18df7577 ("efi/memreserve: deal with memreserve entries in unmapped memory")
Signed-off-by: NLv Yunlong <lyl2019@mail.ustc.edu.cn>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 47ba0d4d2afb476e2a67f781166186e24b1e3bc1
bugzilla: 51363

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

commit fb98cc0b upstream.

Commit 494c704f ("efi: Use 32-bit alignment for efi_guid_t") updated
the type definition of efi_guid_t to ensure that it always appears
sufficiently aligned (the UEFI spec is ambiguous about this, but given
the fact that its EFI_GUID type is defined in terms of a struct carrying
a uint32_t, the natural alignment is definitely >= 32 bits).

However, we missed the EFI_GUID() macro which is used to instantiate
efi_guid_t literals: that macro is still based on the guid_t type,
which does not have a minimum alignment at all. This results in warnings
such as

  In file included from drivers/firmware/efi/mokvar-table.c:35:
  include/linux/efi.h:1093:34: warning: passing 1-byte aligned argument to
      4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
      access [-Walign-mismatch]
          status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size,
                                          ^
  include/linux/efi.h:1101:24: warning: passing 1-byte aligned argument to
      4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer
      access [-Walign-mismatch]
          get_var(L"SetupMode", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, &setupmode);

The distinction only matters on CPUs that do not support misaligned loads
fully, but 32-bit ARM's load-multiple instructions fall into that category,
and these are likely to be emitted by the compiler that built the firmware
for loading word-aligned 128-bit GUIDs from memory

So re-implement the initializer in terms of our own efi_guid_t type, so that
the alignment becomes a property of the literal's type.

Fixes: 494c704f ("efi: Use 32-bit alignment for efi_guid_t")
Reported-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Tested-by: NNathan Chancellor <nathan@kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/1327Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit e5154ea8e48fccde1b2fbd30a1616b002e47f3c6
bugzilla: 51363

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

commit 38c93587 upstream.

Sites that match init_section_contains() get marked as INIT. For
built-in code init_sections contains both __init and __exit text. OTOH
kernel_text_address() only explicitly includes __init text (and there
are no __exit text markers).

Match what jump_label already does and ignore the warning for INIT
sites. Also see the excellent changelog for commit: 8f35eaa5
("jump_label: Don't warn on __exit jump entries")

Fixes: 9183c3f9 ("static_call: Add inline static call infrastructure")
Reported-by: NSumit Garg <sumit.garg@linaro.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: NJarkko Sakkinen <jarkko@kernel.org>
Tested-by: NSumit Garg <sumit.garg@linaro.org>
Link: https://lkml.kernel.org/r/20210318113610.739542434@infradead.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 51ccdd25d7e57260aca5f8cf7aeb03416121e992
bugzilla: 51363

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

commit e06da9ea upstream.

The drivers/staging/ tree has a new mailing list,
linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
it so that we get patches sent to the proper place.

There was no need to specify a list for the hikey9xx driver, the tools
pick up the "base" list for drivers/staging/* so remove that line to
make the file simpler.

Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 4c9a74798ef1aaa85073d349807cc91f5d592e32
bugzilla: 51363

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

commit f8d70fd6 upstream.

The VME and Android drivers still have their MAINTAINERS entries
pointing to the "driverdevel" mailing list, due to them having their
codebase move out of the drivers/staging/ directory, but no one
remembered to change the mailing list entries.

Move them both to linux-kernel for lack of a more specific place at the
moment.  These are both low-volume areas of the kernel, so this
shouldn't be an issue.

Cc: Martyn Welch <martyn@welchs.me.uk>
Cc: Manohar Vanga <manohar.vanga@gmail.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Christian Brauner <christian@brauner.io>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Reported-by: NKonstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/YEzE6u6U1jkBatmr@kroah.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 35ecf664fd6c14b679586bd5a7ccc8a725b043aa
bugzilla: 51363

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

commit 8210bb29 upstream.

This patch adds rename whiteout support in fast commits. Note that the
whiteout object that gets created is actually char device. Which
imples, the function ext4_inode_journal_mode(struct inode *inode)
would return "JOURNAL_DATA" for this inode. This has a consequence in
fast commit code that it will make creation of the whiteout object a
fast-commit ineligible behavior and thus will fall back to full
commits. With this patch, this can be observed by running fast commits
with rename whiteout and seeing the stats generated by ext4_fc_stats
tracepoint as follows:

ext4_fc_stats: dev 254:32 fc ineligible reasons:
XATTR:0, CROSS_RENAME:0, JOURNAL_FLAG_CHANGE:0, NO_MEM:0, SWAP_BOOT:0,
RESIZE:0, RENAME_DIR:0, FALLOC_RANGE:0, INODE_JOURNAL_DATA:16;
num_commits:6, ineligible: 6, numblks: 3

So in short, this patch guarantees that in case of rename whiteout, we
fall back to full commits.

Amir mentioned that instead of creating a new whiteout object for
every rename, we can create a static whiteout object with irrelevant
nlink. That will make fast commits to not fall back to full
commit. But until this happens, this patch will ensure correctness by
falling back to full commits.

Fixes: 8016e29f ("ext4: fast commit recovery path")
Cc: stable@kernel.org
Signed-off-by: NHarshad Shirwadkar <harshadshirwadkar@gmail.com>
Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit e8fa569465e5d45e322ce61759d06b4629384bda
bugzilla: 51363

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

commit 7d8bd3c7 upstream.

If set_large_file = 1 and errors occur in ext4_handle_dirty_metadata(),
the error code will be overridden, go to out_brelse to avoid this
situation.
Signed-off-by: NShijie Luo <luoshijie1@huawei.com>
Link: https://lore.kernel.org/r/20210312065051.36314-1-luoshijie1@huawei.com
Cc: stable@kernel.org
Reviewed-by: NJan Kara <jack@suse.cz>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit 6163a0662b794598f4853e62904a26f5f85ca9b4
bugzilla: 51363

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

commit 6b224899 upstream.

Syzbot report a warning that ext4 may create an empty ea_inode if set
an empty extent attribute to a file on the file system which is no free
blocks left.

  WARNING: CPU: 6 PID: 10667 at fs/ext4/xattr.c:1640 ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640
  ...
  Call trace:
   ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640
   ext4_xattr_block_set+0x1d0/0x1b1c fs/ext4/xattr.c:1942
   ext4_xattr_set_handle+0x8a0/0xf1c fs/ext4/xattr.c:2390
   ext4_xattr_set+0x120/0x1f0 fs/ext4/xattr.c:2491
   ext4_xattr_trusted_set+0x48/0x5c fs/ext4/xattr_trusted.c:37
   __vfs_setxattr+0x208/0x23c fs/xattr.c:177
  ...

Now, ext4 try to store extent attribute into an external inode if
ext4_xattr_block_set() return -ENOSPC, but for the case of store an
empty extent attribute, store the extent entry into the extent
attribute block is enough. A simple reproduce below.

  fallocate test.img -l 1M
  mkfs.ext4 -F -b 2048 -O ea_inode test.img
  mount test.img /mnt
  dd if=/dev/zero of=/mnt/foo bs=2048 count=500
  setfattr -n "user.test" /mnt/foo

Reported-by: syzbot+98b881fdd8ebf45ab4ae@syzkaller.appspotmail.com
Fixes: 9c6e7853 ("ext4: reserve space for xattr entries/names")
Cc: stable@kernel.org
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Link: https://lore.kernel.org/r/20210305120508.298465-1-yi.zhang@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.26
commit d130b802f98a80c43c13607003911a7bb03b0cc7
bugzilla: 51363

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

commit 512c15ef upstream.

The inode update should be stopped before returing the error code.
Signed-off-by: NPan Bian <bianpan2016@163.com>
Link: https://lore.kernel.org/r/20210117085732.93788-1-bianpan2016@163.com
Fixes: 8016e29f ("ext4: fast commit recovery path")
Cc: stable@kernel.org
Reviewed-by: NHarshad Shirwadkar <harshadshirwadkar@gmail.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>