stable inclusion
from stable-5.10.80
commit ab0a06769e69f8ecdf291ee8028a00e7b196aeff
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ab0a06769e69f8ecdf291ee8028a00e7b196aeff

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

commit 16e28abb upstream.

Fujitsu Lifebook T725 laptop requires, like a few other similar
models, the nomux and notimeout options to probe the touchpad
properly.  This patch adds the corresponding quirk entries.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1191980Tested-by: NNeal Gompa <ngompa13@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20211103070019.13374-1-tiwai@suse.deSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.80
commit 8c341d11c8bd366791cacfbf96608de905607fde
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c341d11c8bd366791cacfbf96608de905607fde

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

commit be896bd3 upstream.

Some firmwares occasionally report bogus data from trackpoint, with X or Y
displacement being too large (outside of [-127, 127] range). Let's drop such
packets so that we do not generate jumps.
Signed-off-by: NPhoenix Huang <phoenix@emc.com.tw>
Tested-by: NYufei Du <yufeidu@cs.unc.edu>
Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.80
commit d1eb42de7cf9511702df7751626c21a87f9d0ef9
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d1eb42de7cf9511702df7751626c21a87f9d0ef9

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

commit 744d0090 upstream.

USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.

Fixes: 48735862 ("Input: iforce - use DMA-safe buffer when getting IDs from USB")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Cc: stable@vger.kernel.org      # 5.3
Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.orgSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.80
commit afbec52fbce006a775edb21f87ccae713bc0e7d6
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=afbec52fbce006a775edb21f87ccae713bc0e7d6

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

commit 4d5b5539 upstream.

Use the 'struct cred' saved at binder_open() to lookup
the security ID via security_cred_getsecid(). This
ensures that the security context that opened binder
is the one used to generate the secctx.

Cc: stable@vger.kernel.org # 5.4+
Fixes: ec74136d ("binder: create node flag to request sender's security context")
Signed-off-by: NTodd Kjos <tkjos@google.com>
Suggested-by: NStephen Smalley <stephen.smalley.work@gmail.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Signed-off-by: NPaul Moore <paul@paul-moore.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.80
commit 0d9f4ae7cd6f5283dd0e343265268c695ef592b0
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0d9f4ae7cd6f5283dd0e343265268c695ef592b0

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

commit 52f88693 upstream.

Since binder was integrated with selinux, it has passed
'struct task_struct' associated with the binder_proc
to represent the source and target of transactions.
The conversion of task to SID was then done in the hook
implementations. It turns out that there are race conditions
which can result in an incorrect security context being used.

Fix by using the 'struct cred' saved during binder_open and pass
it to the selinux subsystem.

Cc: stable@vger.kernel.org # 5.14 (need backport for earlier stables)
Fixes: 79af7307 ("Add security hooks to binder and implement the hooks for SELinux.")
Suggested-by: NJann Horn <jannh@google.com>
Signed-off-by: NTodd Kjos <tkjos@google.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Signed-off-by: NPaul Moore <paul@paul-moore.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.80
commit bd9cea41ac6e08f615030dea28b23e12b7a2674f
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bd9cea41ac6e08f615030dea28b23e12b7a2674f

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

commit 29bc22ac upstream.

Save the 'struct cred' associated with a binder process
at initial open to avoid potential race conditions
when converting to an euid.

Set a transaction's sender_euid from the 'struct cred'
saved at binder_open() instead of looking up the euid
from the binder proc's 'struct task'. This ensures
the euid is associated with the security context that
of the task that opened binder.

Cc: stable@vger.kernel.org # 4.4+
Fixes: 457b9a6f ("Staging: android: add binder driver")
Signed-off-by: NTodd Kjos <tkjos@google.com>
Suggested-by: NStephen Smalley <stephen.smalley.work@gmail.com>
Suggested-by: NJann Horn <jannh@google.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Signed-off-by: NPaul Moore <paul@paul-moore.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.80
commit 7f1d5a1a7d80175f9a1af6b00aa7415c5ba08290
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7f1d5a1a7d80175f9a1af6b00aa7415c5ba08290

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

commit 660a92a5 upstream.

AMD's Yellow Carp platform supports runtime power management for
XHCI Controllers, so enable the same by default for all XHCI Controllers.

[ regrouped and aligned the PCI_DEVICE_ID definitions -Mathias]

Cc: stable <stable@vger.kernel.org>
Reviewed-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Reviewed-by: NBasavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: NNehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211014121200.75433-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-5.10.80
commit ff32302687fdb7b6b49393d6feecdbe73607b506
bugzilla: 185821 https://gitee.com/openeuler/kernel/issues/I4L7CG

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ff32302687fdb7b6b49393d6feecdbe73607b506

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

commit e1959faf upstream.

Some USB 3.1 enumeration issues were reported after the hub driver removed
the minimum 100ms limit for the power-on-good delay.

Since commit 90d28fb5 ("usb: core: reduce power-on-good delay time of
root hub") the hub driver sets the power-on-delay based on the
bPwrOn2PwrGood value in the hub descriptor.

xhci driver has a 20ms bPwrOn2PwrGood value for both roothubs based
on xhci spec section 5.4.8, but it's clearly not enough for the
USB 3.1 devices, causing enumeration issues.

Tests indicate full 100ms delay is needed.
Reported-by: NWalt Jr. Brake <mr.yming81@gmail.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Fixes: 90d28fb5 ("usb: core: reduce power-on-good delay time of root hub")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211105160036.549516-1-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4K2D1
CVE: NA

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

When we register kretprobe, data_size used to allocate space
for storing per-instance private data.

If we use a negative values as data_size, It will register
successfully, then cause slab-out-of-bounds which can be
found by KASAN.

The call trace as below :

	=============================================================
	BUG: KASAN: slab-out-of-bounds in trampoline_probe_handler
	+0xb4/0x2f0 at addr ffff8000b732a7a0
	Read of size 8 by task sh/1945
	=============================================================
	BUG kmalloc-64 (Tainted: G    B   W  OE  ):
	kasan: bad access detected
	-------------------------------------------------------------
	INFO: Allocated in register_kretprobe+0x12c/0x350
	age=157 cpu=4 pid=1947
	......
	INFO: Freed in do_one_initcall+0x110/0x260
	age=169 cpu=4 pid=1947
	......
	INFO: Slab 0xffff7bffc2dcca80 objects=21 used=10
	fp=0xffff8000b732aa80 flags=0x7fff00000004080
	INFO: Object 0xffff8000b732a780 @offset=1920 fp=0x     (null)

	CPU: 7 PID: 1945 Comm: sh Tainted: G    B   W  OE   4.1.46 #8
	Hardware name: linux,dummy-virt (DT)
	Call trace:
	[<0008d2a0>] dump_backtrace+0x0/0x220
	[<0008d4e0>] show_stack+0x20/0x30
	[<00ff2278>] dump_stack+0xa8/0xcc
	[<002dc6c8>] print_trailer+0xf8/0x160
	[<002e20d8>] object_err+0x48/0x60
	[<002e48dc>] kasan_report+0x26c/0x5a0
	[<002e39a0>] __asan_load8+0x60/0x80
	[<01000054>] trampoline_probe_handler+0xb4/0x2f0
	[<00ffff38>] kretprobe_trampoline+0x54/0xbc
	Memory state around the buggy address:
 	b732a680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 	b732a700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
	>b732a780: 00 00 00 00 07 fc fc fc fc fc fc fc fc fc fc fc
                               ^

If data_size is invalid, then we should not register it.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reported-by: NKong ZhangHuan <kongzhanghuan@huawei.com>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NMao Wenan <maowenan@huawei.com>
Signed-off-by: NHui Wang <john.wanghui@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>

Conflicts: kernel/kprobes.c
Signed-off-by: NXuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

Conflicts: kernel/kprobes.c

[ hf: cherry-pick from openEuler-1.0-LTS ]
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4L078
CVE: NA

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

We backport the
commit 17f4bad3 ("ima: remove usage of filename parameter") to
support absolute path in ima measurement log,when get absolute path
failed, the pathname with NULL value will be passed to the next
measurement processes. Fix the pathname to relative path when get
absolute path failed.
Signed-off-by: NLi Kun <hw.likun@huawei.com>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NHui Wang <john.wanghui@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

Conflicts:
	security/integrity/ima/ima_main.c
Signed-off-by: NGuo Zihua <guozihua@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JUZZ

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

On ARM64, armv8_pmu_driver_init() is called in do_basic_setup(), it will
fail to create perf event if lockup_detector_init() is moved back. So
revert the patch firstly.

Fixes: 60565144 ("init: only move down lockup_detector_init() when sdei_watchdog is enabled")
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4K05G?from=project-issue
CVE: N/A

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

Add support of port isolation for QLogic HBA cards.
Signed-off-by: NXishi Qiu <qiuxishi@huawei.com>
Signed-off-by: NFang Ying <fangying1@huawei.com>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NHui Wang <john.wanghui@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>

Confilicts:
	drivers/pci/quirks.c
Signed-off-by: NXuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

Confilicts:
        drivers/pci/quirks.c
Reviewed-by: Nwangxiongfeng <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4J9WR

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

Enable the config about SVA feature.
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JA4W

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

In the previous driver, the queue isolation configuration register of
the PF page was mixed with the queue isolation configuration register of
the VF page, which resulted in mismatch and error in the configuration
information during migration. Because the BIT0 of the queue isolation
register of the PF page is consistent with the value of the queue
isolation register of the VF page, Therefore, driver can only read
the registers of the VF page.
Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JA45

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

In the guest reset operation scenario, the driver inside the guest
will not perceive the system restart operation, and the corresponding
accelerator driver cannot modify the drive state. When the target end
of the live migration is restored, the operation of restarting qp cannot
be skipped normally. Caused a page fault exception and the reset
of the accelerator PF,
Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JA4O

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

In the previous method, getting the queue operation will overwrite
the PF queue address, causing calltrace when the PF device driver is
unloaded.
Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-master
commit 183b60e0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4IUAA
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/drivers/crypto/hisilicon?id=183b60e005975d3c84c22199ca64a9221e620fb6

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

As qm should register to uacce in UACCE_DEV_SVA mode,
this patch modifies to checks uacce mode before doing uacce
registration.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-master
commit 6e96dbe7
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4IU8M
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/drivers/crypto/hisilicon?id=6e96dbe7c40a66a1dac3cdc8d29e9172d937a7b1

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

There is a spelling mistake in a literal string. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-master
commit cbbb5f07
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4IU7R
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/drivers/crypto/hisilicon?id=cbbb5f07ab737f868f90d429255d5d644280f6a9

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

The function qm_qos_value_init expects an unsigned integer but
is incorrectly supplying a signed format to sscanf.  This patch
fixes it.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: Bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA

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

Enable COHERENT_DEVICE will degrade performance, Hackbench test
time (Pipe_Process_Number=800) from 0.3 to 1.8. When the cdmmask
was cacheline aligned, it will be improved as same as disabled
COHERENT_DEVICE.
Signed-off-by: NFang Lijun <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KCU2
CVE: NA

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

When I ran Syzkaller testsuite, I got the following call trace.
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>

================================================================================
UBSAN: Undefined behaviour in kernel/time/ntp.c:457:16
signed integer overflow:
9223372036854775807 + 500 cannot be represented in type 'long int'
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.25-dirty #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xca/0x13e lib/dump_stack.c:113
 ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
 handle_overflow+0x193/0x1e2 lib/ubsan.c:190
 second_overflow+0x403/0x540 kernel/time/ntp.c:457
 accumulate_nsecs_to_secs kernel/time/timekeeping.c:2002 [inline]
 logarithmic_accumulation kernel/time/timekeeping.c:2046 [inline]
 timekeeping_advance+0x2bb/0xec0 kernel/time/timekeeping.c:2114
 tick_do_update_jiffies64.part.2+0x1a0/0x350 kernel/time/tick-sched.c:97
 tick_do_update_jiffies64 kernel/time/tick-sched.c:1229 [inline]
 tick_nohz_update_jiffies kernel/time/tick-sched.c:499 [inline]
 tick_nohz_irq_enter kernel/time/tick-sched.c:1232 [inline]
 tick_irq_enter+0x1fd/0x240 kernel/time/tick-sched.c:1249
 irq_enter+0xc4/0x100 kernel/softirq.c:353
 entering_irq arch/x86/include/asm/apic.h:517 [inline]
 entering_ack_irq arch/x86/include/asm/apic.h:523 [inline]
 smp_apic_timer_interrupt+0x20/0x480 arch/x86/kernel/apic/apic.c:1052
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:864
 </IRQ>
RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
Code: 01 f0 0f 82 bc fd ff ff 48 c7 c7 c0 21 b1 83 e8 a1 0a 02 ff e9 ab fd ff ff 4c 89 e7 e8 77 b6 a5 fe e9 6a ff ff ff 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
RSP: 0018:ffff888106307d20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000007 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881062e4f1c
RBP: 0000000000000003 R08: ffffed107c5dc77b R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff848c78a0
R13: 0000000000000003 R14: 1ffff11020c60fae R15: 0000000000000000
 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
 default_idle+0x24/0x2b0 arch/x86/kernel/process.c:561
 cpuidle_idle_call kernel/sched/idle.c:153 [inline]
 do_idle+0x2ca/0x420 kernel/sched/idle.c:262
 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:368
 start_secondary+0x421/0x570 arch/x86/kernel/smpboot.c:271
 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
================================================================================

It is because time_maxerror is set as 0x7FFFFFFFFFFFFFFF by user. It
overflows when we add it with 'MAXFREQ / NSEC_PER_USEC' in
'second_overflow()'.

This patch add a limit check and saturate it when the user set
'time_maxerror'.
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KCU2
CVE: NA

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

We need to clear EOI for the secure timer only when we panic from
sdei_handler. If we clear EOI for the secure timer in normal panic
routiue, it has no bad effect on Hi1620, but it may cause undefine
behavior on Hi1616. So add a check for NMI context before we clear EOI
for the secure timer.

Fixes: dd397d5febc4("sdei_watchdog: clear EOI of the secure timer before
kdump")
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KCU2
CVE: NA

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

Fix following crash that occurs when 'fq_flush_timeout()' access
'fq->lock' while 'iovad->fq' has been cleared. This happens when the
'fq_timer' handler is being executed and we call
'free_iova_flush_queue()'. When the timer handler is being executed,
its pending state is cleared and it is detached. This patch use
'del_timer_sync()' to wait for the timer handler 'fq_flush_timeout()' to
finish before destroying the flush queue.

[ 9052.361840] Unable to handle kernel paging request at virtual address 0000a02fd6c66008
[ 9052.361843] Mem abort info:
[ 9052.361845]   ESR = 0x96000004
[ 9052.361847]   Exception class = DABT (current EL), IL = 32 bits
[ 9052.361849]   SET = 0, FnV = 0
[ 9052.361850]   EA = 0, S1PTW = 0
[ 9052.361852] Data abort info:
[ 9052.361853]   ISV = 0, ISS = 0x00000004
[ 9052.361855]   CM = 0, WnR = 0
[ 9052.361860] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000009b665b91
[ 9052.361863] [0000a02fd6c66008] pgd=0000000000000000
[ 9052.361870] Internal error: Oops: 96000004 [#1] SMP
[ 9052.361873] Process rmmod (pid: 51122, stack limit = 0x000000003f5524f7)
[ 9052.361881] CPU: 69 PID: 51122 Comm: rmmod Kdump: loaded Tainted: G           OE     4.19.36-
[ 9052.361882] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 0.81 07/10/2019
[ 9052.361885] pstate: 80400089 (Nzcv daIf +PAN -UAO)
[ 9052.361902] pc : fq_flush_timeout+0x9c/0x110
[ 9052.361904] lr :           (null)
[ 9052.361906] sp : ffff00000965bd80
[ 9052.361907] x29: ffff00000965bd80 x28: 0000000000000202
[ 9052.361912] x27: 0000000000000000 x26: 0000000000000053
[ 9052.361915] x25: ffffa026ed805008 x24: ffff000009119810
[ 9052.361919] x23: ffff00000911b938 x22: ffff00000911bc04
[ 9052.361922] x21: ffffa026ed804f28 x20: 0000a02fd6c66008
[ 9052.361926] x19: 0000a02fd6c64000 x18: ffff000009117000
[ 9052.361929] x17: 0000000000000008 x16: 0000000000000000
[ 9052.361933] x15: ffff000009119708 x14: 0000000000000115
[ 9052.361936] x13: ffff0000092f09d7 x12: 0000000000000000
[ 9052.361940] x11: 0000000000000001 x10: ffff00000965be98
[ 9052.361943] x9 : 0000000000000000 x8 : 0000000000000007
[ 9052.361947] x7 : 0000000000000010 x6 : 000000d658b784ef
[ 9052.361950] x5 : 00ffffffffffffff x4 : 00000000ffffffff
[ 9052.361954] x3 : 0000000000000013 x2 : 0000000000000001
[ 9052.361957] x1 : 0000000000000000 x0 : 0000a02fd6c66008
[ 9052.361961] Call trace:
[ 9052.361967]  fq_flush_timeout+0x9c/0x110
[ 9052.361976]  call_timer_fn+0x34/0x178
[ 9052.361980]  expire_timers+0xec/0x158
[ 9052.361983]  run_timer_softirq+0xc0/0x1f8
[ 9052.361987]  __do_softirq+0x120/0x324
[ 9052.361995]  irq_exit+0x11c/0x140
[ 9052.362003]  __handle_domain_irq+0x6c/0xc0
[ 9052.362005]  gic_handle_irq+0x6c/0x150
[ 9052.362008]  el1_irq+0xb8/0x140
[ 9052.362010]  vprintk_emit+0x2b4/0x320
[ 9052.362013]  vprintk_default+0x54/0x90
[ 9052.362016]  vprintk_func+0xa0/0x150
[ 9052.362019]  printk+0x74/0x94
[ 9052.362034]  nvme_get_smart+0x200/0x220 [nvme]
[ 9052.362041]  nvme_remove+0x38/0x250 [nvme]
[ 9052.362051]  pci_device_remove+0x48/0xd8
[ 9052.362065]  device_release_driver_internal+0x1b4/0x250
[ 9052.362068]  driver_detach+0x64/0xe8
[ 9052.362072]  bus_remove_driver+0x64/0x118
[ 9052.362074]  driver_unregister+0x34/0x60
[ 9052.362077]  pci_unregister_driver+0x24/0xd8
[ 9052.362083]  nvme_exit+0x24/0x1754 [nvme]
[ 9052.362094]  __arm64_sys_delete_module+0x19c/0x2a0
[ 9052.362102]  el0_svc_common+0x78/0x130
[ 9052.362106]  el0_svc_handler+0x38/0x78
[ 9052.362108]  el0_svc+0x8/0xc
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NYao Hongbo <yaohongbo@huawei.com>
Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KCU2
CVE: NA

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

When I enable CONFIG_ARM64_ILP32 and CONFIG_UBSAN, I got the following
compile error. We need to disable UBSAN for 'vdso-ilp32' like commit
ab2a69eee74d ("Fix compile problem when CONFIG_KASAN and CONFIG_UBSAN were
on")

`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
`.data' referenced in section `.text' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o: defined in discarded section `.data' of arch/arm64/kernel/vdso-ilp32/gettimeofday-ilp32.o
Signed-off-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KCU2
CVE: NA

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

When we set 'nr_cpus=1' in kernel parameter, we get the following error.
It's because 'acpi_map_cpuid()' return -ENODEV in 'acpi_map_cpu()' when
there are not enough logical CPU numbers. So we need to check the
returned logical CPU number and return error if it is negative.

'acpi_map_cpu' when there are not enough logical CPU
[    0.025955] Unable to handle kernel paging request at virtual address ffff00002915b828
[    0.025958] Mem abort info:
[    0.025959]   ESR = 0x96000006
[    0.025961]   Exception class = DABT (current EL), IL = 32 bits
[    0.025963]   SET = 0, FnV = 0
[    0.025965]   EA = 0, S1PTW = 0
[    0.025966] Data abort info:
[    0.025968]   ISV = 0, ISS = 0x00000006
[    0.025970]   CM = 0, WnR = 0
[    0.025972] swapper pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[    0.025974] [ffff00002915b828] pgd=000000013fffe003, pud=000000013fffd003, pmd=0000000000000000
[    0.025979] Internal error: Oops: 96000006 [#1] SMP
[    0.025981] Modules linked in:
[    0.025983] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
[    0.025986] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W         4.19.141+ #37
[    0.025988] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[    0.025991] pstate: a0c00005 (NzCv daif +PAN +UAO)
[    0.025993] pc : acpi_map_cpu+0xe0/0x170
[    0.025996] lr : acpi_map_cpu+0xb8/0x170
[    0.025997] sp : ffff8000fef1fa50
[    0.025999] x29: ffff8000fef1fa50 x28: ffff000008e22058
[    0.026001] x27: ffff0000092a6000 x26: ffff000008d60778
[    0.026004] x25: ffff0000094c3000 x24: 0000000000000001
[    0.026006] x23: ffff8000fe802c18 x22: 00000000ffffffff
[    0.026008] x21: ffff000008a16000 x20: ffff000008a16a20
[    0.026011] x19: 00000000ffffffed x18: ffffffffffffffff
[    0.026013] x17: 0000000087411dcf x16: 00000000b93a5600
[    0.026015] x15: ffff000009159708 x14: 0720072007200720
[    0.026018] x13: 0720072007200720 x12: 0720072007200720
[    0.026020] x11: 072007200720073d x10: 073d073d073d073d
[    0.026022] x9 : 073d073d073d0764 x8 : 0765076607660766
[    0.026024] x7 : 0766076607660778 x6 : 0000000000000130
[    0.026027] x5 : ffff0000085955c8 x4 : 0000000000000000
[    0.026029] x3 : 0000000000000000 x2 : ffff00000915b830
[    0.026031] x1 : ffff00002915b828 x0 : 0000200000000000
[    0.026033] Call trace:
[    0.026035]  acpi_map_cpu+0xe0/0x170
[    0.026038]  acpi_processor_add+0x44c/0x640
[    0.026040]  acpi_bus_attach+0x174/0x218
[    0.026043]  acpi_bus_attach+0xa8/0x218
[    0.026045]  acpi_bus_attach+0xa8/0x218
[    0.026047]  acpi_bus_attach+0xa8/0x218
[    0.026049]  acpi_bus_scan+0x58/0xb8
[    0.026052]  acpi_scan_init+0xf4/0x234
[    0.026054]  acpi_init+0x318/0x384
[    0.026056]  do_one_initcall+0x54/0x250
[    0.026059]  kernel_init_freeable+0x2d4/0x3c0
[    0.026061]  kernel_init+0x18/0x118
[    0.026063]  ret_from_fork+0x10/0x18
[    0.026066] Code: d2800020 9120c042 8b010c41 9ad32000 (f820303f)
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@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: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KCU2
CVE: NA

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

One of the ILP32 patchset rename 'compat_user_mode' and
'compat_thumb_mode' to 'a32_user_mode' and 'a32_user_mode'. But these
two macros are used in some opensource userspace application. To keep
compatibility, we redefine these two macros.

Fixes: 23b2f00 ("arm64: rename functions that reference compat term")
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: Nliwei <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JBSJ
CVE: NA

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

LSE atomic instruction might introduce performance regression on
specific benchmark or business. So add a cmdline option to
disable/enable it.

"lse=off" cmdline option means disable LSE atomic instruction.
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
Tested-by: NQiang Xiaojun <qiangxiaojun@huawei.com>
[liwei: Fix compile warning with CONFIG_ARM64_LSE_ATOMICS=n]
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: feature
bugzilla: 46922
CVE: NA

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

Taishan's L1/L2 cache is inclusive, and the data is consistent.
Any change of L1 does not require DC operation to brush CL in L1 to L2.
It's safe that don't clean data cache by address to point of unification.

Without IDC featrue, kernel needs to flush icache as well as dcache,
causes performance degradation.

The flaw refers to V110/V200 variant 1.
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NDing Tianhong <dingtianhong@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 37631
CVE: NA

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

To support signal monitoring, we need to export the defined tracepoint
signal_generate so that it can be used in kernel modules.
Signed-off-by: NTang Yizhou <tangyizhou@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4K2U5
CVE: NA

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

Export cpu_suspend/cpu_resume/psci_ops for lowpower driver.
Signed-off-by: NBixuan Cui <cuibixuan@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: feature
bugzilla: NA
CVE: NA

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

Export log_buf_addr_get()/log_buf_len_get() for bbox driver.
Signed-off-by: NBixuan Cui <cuibixuan@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: bugfix
Bugzilla: N/A
CVE: N/A

-------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
Acked-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4CMAR
CVE: NA

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

Customization deliver all types error to driver. As the driver
need to process the errors in process context.
Signed-off-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4D63I
CVE: NA

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

Export console_flush_on_panic for bbox to use.
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>
Signed-off-by: NFang Lijun <fanglijun3@huawei.com>
Reviewed-by: NDing Tianhong <dingtianhong@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: bugfix
bugzilla: 9509, https://gitee.com/openeuler/kernel/issues/I4K61K
CVE: NA

Reference: http://openeuler.huawei.com/bugzilla/show_bug.cgi?id=9509

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

Syzkaller hit 'possible deadlock in console_unlock' for several times.
Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&port->lock)->rlock);
                               lock(&port_lock_key);
                               lock(&(&port->lock)->rlock);
  lock(console_owner);

The problem is that call_console_driver->console_driver also can do
this thing

   uart_port->lock
    tty_wakeup
     tty_port->lock

So we can have the following:

tty_write
 tty_port->lock
  printk
   call_console_driver
    console_driver
     uart_port->lock
      tty_wakeup
       tty_port->lock      << deadlock

To solve this problem,  switch to printk_safe mode around that kmalloc(),
this will redirect all printk()-s from kmalloc() to a special per-CPU
buffer, which will be flushed later from a safe context (irq work).
Signed-off-by: NHongbo Yao <yaohongbo@huawei.com>
Signed-off-by: NPeng Wu <wupeng58@huawei.com>
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euler inclusion
category: bugfix
bugzilla: 9509, https://gitee.com/openeuler/kernel/issues/I4K61K
CVE: NA

Reference: https://lore.kernel.org/lkml/20181017044843.GD1068@jagdpanzerIV/T/

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

Make printk_safe_enter_irqsave()/etc macros available to the
rest of the kernel.
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: NHongbo Yao <yaohongbo@huawei.com>
Signed-off-by: NPeng Wu <wupeng58@huawei.com>
Reviewed-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4K6DE
CVE: NA

The non-strict smmu mode has significant performance gains and can
resolve the nvme soft lockup problem. We enable it by default.

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

Currently, many peripherals are faster than before. For example, the top
speed of the older netcard is 10Gb/s, and now it's more than 25Gb/s. But
when iommu page-table mapping enabled, it's hard to reach the top speed
in strict mode, because of frequently map and unmap operations. In order
to keep abreast of the times, I think it's better to set non-strict as
default.

Below it's our iperf performance data of 25Gb netcard:
strict mode: 18-20 Gb/s
non-strict mode: 23.5 Gb/s
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 30859, https://gitee.com/openeuler/kernel/issues/I4K6FB
CVE: NA

Reference: http://openeuler.huawei.com/bugzilla/show_bug.cgi?id=30859

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

There is softlockup under fio pressure test with smmu enabled:
watchdog: BUG: soft lockup - CPU#81 stuck for 22s!  [swapper/81:0]
...
Call trace:
 fq_flush_timeout+0xc0/0x110
 call_timer_fn+0x34/0x178
 expire_timers+0xec/0x158
 run_timer_softirq+0xc0/0x1f8
 __do_softirq+0x120/0x324
 irq_exit+0x11c/0x140
 __handle_domain_irq+0x6c/0xc0
 gic_handle_irq+0x6c/0x170
 el1_irq+0xb8/0x140
 arch_cpu_idle+0x38/0x1c0
 default_idle_call+0x24/0x44
 do_idle+0x1f4/0x2d8
 cpu_startup_entry+0x2c/0x30
 secondary_start_kernel+0x17c/0x1c8

This is because the timer callback fq_flush_timeout may run more than
10ms, and timer may be processed continuously in the softirq so trigger
softlockup. We can use work to deal with fq_ring_free for each cpu which
may take long time, that to avoid triggering softlockup.
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Signed-off-by: NPeng Wu <wupeng58@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMM0
CVE: NA

--------

Enable CONFIG_HISI_SVM by default.
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMM0
CVE: NA

--------

Add ioctl to get pyhs addr for ts core, and put it
in the reserved memory.
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>