mainline inclusion
from mainline-v5.15
de6ee659
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4NVSJ
CVE: NA

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

In the case of SHMEM_HUGE_WITHIN_SIZE, the page index is not rounded up
correctly.  When the page index points to the first page in a huge page,
round_up() cannot bring it to the end of the huge page, but to the end
of the previous one.

An example:

HPAGE_PMD_NR on my machine is 512(2 MB huge page size).  After
allcoating a 3000 KB buffer, I access it at location 2050 KB.  In
shmem_is_huge(), the corresponding index happens to be 512.  After
rounded up by HPAGE_PMD_NR, it will still be 512 which is smaller than
i_size, and shmem_is_huge() will return true.  As a result, my buffer
takes an additional huge page, and that shouldn't happen when
shmem_enabled is set to within_size.

Link: https://lkml.kernel.org/r/20210909032007.18353-1-liuyuntao10@huawei.com
Fixes: f3f0e1d2 ("khugepaged: add support of collapse for tmpfs/shmem pages")
Signed-off-by: NLiu Yuntao <liuyuntao10@huawei.com>
Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: NHugh Dickins <hughd@google.com>
Cc: wuxu.wu <wuxu.wu@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Nzhangyiru <zhangyiru3@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

we get (Unable to handle kernel NULL pointer dereference at virtual
address 000000000000000c) when call drm_property_blob_put().
After analysis, we get the following process:
alloc failed:
drm_atomic_set_mode_for_crtc()
    drm_property_create_blob() // failed
    state->mode_blob = ERR_PTR(-ENOMEM)
free illegal pointer:
__drm_atomic_helper_crtc_destroy_state()
    drm_property_blob_put(state->mode_blob)
	    drm_mode_object_put(&blob->base);   // here blob is ERR_PTR(-ENOMEM)
So do we have to determine if blob is an error code
before calling drm_mode_object_put().

Fixes: 6bcacf51 (drm: Add reference counting to blob properties)
Signed-off-by: Nxuhuijie <xuhuijie2@huawei.com>
Signed-off-by: NLiu Yuntao <liuyuntao10@huawei.com>
Reviewed-by: NLiu Zixian <liuzixian4@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4ETXO
CVE: NA

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

Fix following build warnings of iBMA driver in arm32 builds:

drivers/net/ethernet/huawei/bma/cdev_veth_drv/virtual_cdev_eth_net.c: In function ‘__make_dmalistbd_b2h_H_2’:
drivers/net/ethernet/huawei/bma/cdev_veth_drv/virtual_cdev_eth_net.c:1266:38: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  pdmalbase_v[i].slow = lower_32_bits((u64)prxtx_queue->pdmalbase_p);
                                      ^
./include/linux/kernel.h:191:34: note: in definition of macro ‘lower_32_bits’
 #define lower_32_bits(n) ((u32)((n) & 0xffffffff))
                                  ^
drivers/net/ethernet/huawei/bma/cdev_veth_drv/virtual_cdev_eth_net.c:1267:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  pdmalbase_v[i].shi = upper_32_bits((u64)prxtx_queue->pdmalbase_p);
                                     ^
./include/linux/kernel.h:185:35: note: in definition of macro ‘upper_32_bits’
 #define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
                                   ^
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4O31I

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

Enable legacy pmem register feature for arm64.
Signed-off-by: NZhuling <zhuling8@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4O31I

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

This patch is to support persistent memory(legacy) register on arm64.

Firstly, support memory region marked as protected memory, which
removed from memblock, the ranges for persistent memory are described
by the 'memmap=nn[KMG]!ss[KMG]' kernel parameter", then they will
be passed to the 'pmem' driver so they can be used for persistent
storage. For now, the maximum memory regions supported is 8.

Secondly, add ARM64_PMEM_LEGACY Kconfig to select PMEM_LEGACY and
PMEM_LEGACY_DEVICE to reuse the nvdimm resource discovery and pmem
device registering mechanism provided by pmem_legacy.c and e820.c.

Note, the functions in those file should not only used by x86, but
the file and function naming is x86 specific, will update after this
feature upstreamed.

Here are steps to show how to use this feature on arm64,
1. setup the memmap kernel parameter, memmap=nn[KMG]!ss[KMG],
   eg, memmap=100K!0x1a0000000.
2. load nd_e820.ko driver, modprobe nd_e820.
3. check pmem device in /dev, eg, /dev/pmem0
Signed-off-by: NZhuling <zhuling8@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4O31I

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

Move x86's pmem.c into nvdimm, and rename X86_PMEM_LEGACY_DEVICE to
PMEM_LEGACY_DEVICE, also add PMEM_LEGACY to control the built of
nd_e820.o, then the code could be reused by other architectures.

Note，this patch fixs the nd_e820.c build introduced by commit 2499317e
("arm64: Revert feature: Add memmap parameter and register pmem").
Signed-off-by: NZhuling <zhuling8@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Enable CONFIG_VENDOR_HOOKS for x86 and arm64 by default.
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

Reference: https://android.googlesource.com/kernel/common/

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

Make android vendor hooks feature generic.
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aosp inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

Reference: https://android.googlesource.com/kernel/common/+/51681321c0ef

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

In upstream commit d9a1be1b ("tracepoints: Do not punish non
static call users"), tracepoint macros were refactored to optimize
for static_call() cases. Since the Android-specific restricted
vendor hook mechanism leverages tracehooks, this required
equivalent refactoring in include/trace/hooks/vendor_hooks.h

Fixes: d9a1be1b ("tracepoints: Do not punish non static call users")
Signed-off-by: NTodd Kjos <tkjos@google.com>
Change-Id: I2e01b34606e6ff0e577b76b57c47f601c32f626b
Signed-off-by: NGreg Kroah-Hartman <gregkh@google.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.12-rc1
commit d9a1be1b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

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

With static calls, a tracepoint can call the callback directly if there is
only one callback registered to that tracepoint. When there is more than
one, the static call will call the tracepoint's "iterator" function, which
needs to reload the tracepoint's "funcs" array again, as it could have
changed since the first time it was loaded.

But an arch without static calls is punished by having to load the
tracepoint's "funcs" array twice. Once in the DO_TRACE macro, and once
again in the iterator macro.

For archs without static calls, there's no reason to load the array macro
in the first place, since the iterator function will do it anyway.

Change the __DO_TRACE_CALL() macro to do the load and call of the
tracepoints funcs array only for architectures with static calls, and just
call the iterator function directly for architectures without static calls.

Link: https://lkml.kernel.org/r/20210208201050.909329787@goodmis.orgAcked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.12-rc1
commit 1746fd44
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

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

While working on a clean up that would restructure the difference between
architectures that have static calls vs those that do not, I was stumbling
over the "data_args" parameter that includes "__data" in the arguments. The
issue was that one version didn't even need it, while the other one did.
Instead of injecting a "__data = NULL;" into the macro for the unneeded
version, just remove it completely.

The original idea behind data_args is that there may be a case of a
tracepoint with no arguments. But this is considered bad practice, and all
tracepoints should pass something to that location (that's what tracepoints
were created for).

Link: https://lkml.kernel.org/r/20210208201050.768074128@goodmis.orgAcked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aosp inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

Reference: https://android.googlesource.com/kernel/common/+/943c3b3124d2

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

Vendor hooks required explicitly defining macros or inline functions
to handle the non-GKI build case (!CONFIG_ANDROID_VENDOR_HOOKS). Added
support for generating them automatically so the macros are no longer
required.

Both models are now supported so we can transition.

Bug: 177416721
Signed-off-by: NTodd Kjos <tkjos@google.com>
Change-Id: I01acc389d315a5d509b0c48116854342a42e1058
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aosp inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

Reference: https://android.googlesource.com/kernel/common/+/4cc2f83c77aa

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

After upstream 33def849 ("treewide: Convert macro and uses of
__section(foo) to __section("foo")"), the preprocessor macro __section
now requires the section name to be double quoted.

This patch resolves breakage that results from merging down from
mainline in this out of tree header.

Fixes: 33def849 ("treewide: Convert macro and uses of __section(foo) to __section("foo")")
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie6a701251e6420e63187a466b43ec2c834e0ec2e
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aosp inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

Reference: https://android.googlesource.com/kernel/common/+/5e767aa07eea

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

commit d25e37d8 ("tracepoint: Optimize using static_call()")
refactored tracepoints to use static_call(). Add the same
optimization for restricted vendor hooks.

Fixes: d25e37d8 ("tracepoint: Optimize using static_call()")
Signed-off-by: NTodd Kjos <tkjos@google.com>
Change-Id: I336db7e90b733ac4098ce342001cc31fd215d137
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aosp inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

Reference: https://android.googlesource.com/kernel/common/+/e706f27c765b

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

Because of the multi-inclusion oddities of tracepoints, the
multi-inclusion protection in vendor_hooks.h caused issues
if more than 1 vendor hook header file with restricted vendor
hooks defined were included with "CREATE_TRACE_POINTS"
defined (redefinition of symbol errors).

The problem is fixed by removing the multiple-inclusion
protection as is done for regular tracepoints.

Fixes: 7f62740112ef ("ANDROID: add support for vendor hooks")
Bug: 163076069
Signed-off-by: NTodd Kjos <tkjos@google.com>
Change-Id: Ic177db1693a6a2db58f08917e9115c7e6c2971b6
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aosp inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCS8
CVE: NA

Reference: https://android.googlesource.com/kernel/common/+/7f62740112ef

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

Add support for vendor hooks. Adds include/trace/hooks
directory for trace definition headers where hooks
can be defined and vendor_hook.c for instantiating
and exporting them for vendor modules.

There are two variants of vendor hooks, both based
on tracepoints:

Normal: this uses the DECLARE_HOOK macro
to create a tracepoint function with the name trace_<name>
where <name> is the unique identifier for the trace.

Restricted: restricted hooks are needed for cases like
scheduler hooks where the attached function must be
called even if the cpu is offline or requires a
non-atomic context. Restricted vendor hooks cannot
be detached, so modules that attach to a restricted
hook can never unload. Also, only 1 attachment is
allowed (any other attempts to attach will fail with
-EBUSY).

For either case, modules attach to the hook by using
register_trace_<name>(func_ptr, NULL).

New hooks should be defined in headers in the
include/trace/hooks/ directory using the
DECLARE_HOOK() or DECLARE_RESTRICTED_HOOK()
macros.

New files added to include/trace/hooks should
be #include'd from drivers/android/vendor_hooks.c.
The EXPORT_TRACEPOINT_SYMBOL_GPL() should be
also added to drivers/android/vendor_hooks.c.

For example, if a new hook, 'android_vh_foo(int &ret)'
is added in do_exit() in exit.c, these changes are
needed:

1. create a new header file include/trace/hooks/foo.h
which contains:
	#include <trace/hooks/vendor_hooks.h>
	...
 	DECLARE_HOOK(android_vh_foo,
		     TP_PROTO(int *retp),
		     TP_ARGS(retp);

2. in exit.c, add
	#include <trace/hooks/foo.h>
	...
  	int ret = 0;
	...
  	android_vh_foo(&ret);
  	if (ret)
    		return ret;
	...

3. in drivers/android/vendor_hooks.c, add
	#include <trace/hooks/foo.h>
	...
	EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_foo);

The hook can then be attached by adding the registration code
to the module:

	#include <trace/hooks/sched.h>
	...
	static void my_foo(int *retp)
	{
		*retp = 0;
	}
	...
	rc = register_trace_android_vh_sched_exit(my_foo, NULL);

Bug: 156285741
Signed-off-by: NTodd Kjos <tkjos@google.com>
Change-Id: I6a7d1c8919dae91c965e2a0450df50eac2d282db
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Export PG_pool page flag in /proc/kpageflags.

	27. KPF_POOL		page is allocated from hpool.

By using this tool, we can easily count the number of pages allocated from
dynamic hugetlb pool by a process or a file.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc1
commit 380a0091
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RP94?from=project-issue
CVE: NA

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

We got issue as follows when run syzkaller:
[  167.936972] EXT4-fs error (device loop0): __ext4_remount:6314: comm rep: Abort forced by user
[  167.938306] EXT4-fs (loop0): Remounting filesystem read-only
[  167.981637] Assertion failure in ext4_getblk() at fs/ext4/inode.c:847: '(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY) || handle != NULL || create == 0'
[  167.983601] ------------[ cut here ]------------
[  167.984245] kernel BUG at fs/ext4/inode.c:847!
[  167.984882] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
[  167.985624] CPU: 7 PID: 2290 Comm: rep Tainted: G    B             5.16.0-rc5-next-20211217+ #123
[  167.986823] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[  167.988590] RIP: 0010:ext4_getblk+0x17e/0x504
[  167.989189] Code: c6 01 74 28 49 c7 c0 a0 a3 5c 9b b9 4f 03 00 00 48 c7 c2 80 9c 5c 9b 48 c7 c6 40 b6 5c 9b 48 c7 c7 20 a4 5c 9b e8 77 e3 fd ff <0f> 0b 8b 04 244
[  167.991679] RSP: 0018:ffff8881736f7398 EFLAGS: 00010282
[  167.992385] RAX: 0000000000000094 RBX: 1ffff1102e6dee75 RCX: 0000000000000000
[  167.993337] RDX: 0000000000000001 RSI: ffffffff9b6e29e0 RDI: ffffed102e6dee66
[  167.994292] RBP: ffff88816a076210 R08: 0000000000000094 R09: ffffed107363fa09
[  167.995252] R10: ffff88839b1fd047 R11: ffffed107363fa08 R12: ffff88816a0761e8
[  167.996205] R13: 0000000000000000 R14: 0000000000000021 R15: 0000000000000001
[  167.997158] FS:  00007f6a1428c740(0000) GS:ffff88839b000000(0000) knlGS:0000000000000000
[  167.998238] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  167.999025] CR2: 00007f6a140716c8 CR3: 0000000133216000 CR4: 00000000000006e0
[  167.999987] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  168.000944] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  168.001899] Call Trace:
[  168.002235]  <TASK>
[  168.007167]  ext4_bread+0xd/0x53
[  168.007612]  ext4_quota_write+0x20c/0x5c0
[  168.010457]  write_blk+0x100/0x220
[  168.010944]  remove_free_dqentry+0x1c6/0x440
[  168.011525]  free_dqentry.isra.0+0x565/0x830
[  168.012133]  remove_tree+0x318/0x6d0
[  168.014744]  remove_tree+0x1eb/0x6d0
[  168.017346]  remove_tree+0x1eb/0x6d0
[  168.019969]  remove_tree+0x1eb/0x6d0
[  168.022128]  qtree_release_dquot+0x291/0x340
[  168.023297]  v2_release_dquot+0xce/0x120
[  168.023847]  dquot_release+0x197/0x3e0
[  168.024358]  ext4_release_dquot+0x22a/0x2d0
[  168.024932]  dqput.part.0+0x1c9/0x900
[  168.025430]  __dquot_drop+0x120/0x190
[  168.025942]  ext4_clear_inode+0x86/0x220
[  168.026472]  ext4_evict_inode+0x9e8/0xa22
[  168.028200]  evict+0x29e/0x4f0
[  168.028625]  dispose_list+0x102/0x1f0
[  168.029148]  evict_inodes+0x2c1/0x3e0
[  168.030188]  generic_shutdown_super+0xa4/0x3b0
[  168.030817]  kill_block_super+0x95/0xd0
[  168.031360]  deactivate_locked_super+0x85/0xd0
[  168.031977]  cleanup_mnt+0x2bc/0x480
[  168.033062]  task_work_run+0xd1/0x170
[  168.033565]  do_exit+0xa4f/0x2b50
[  168.037155]  do_group_exit+0xef/0x2d0
[  168.037666]  __x64_sys_exit_group+0x3a/0x50
[  168.038237]  do_syscall_64+0x3b/0x90
[  168.038751]  entry_SYSCALL_64_after_hwframe+0x44/0xae

In order to reproduce this problem, the following conditions need to be met:
1. Ext4 filesystem with no journal;
2. Filesystem image with incorrect quota data;
3. Abort filesystem forced by user;
4. umount filesystem;

As in ext4_quota_write:
...
         if (EXT4_SB(sb)->s_journal && !handle) {
                 ext4_msg(sb, KERN_WARNING, "Quota write (off=%llu, len=%llu)"
                         " cancelled because transaction is not started",
                         (unsigned long long)off, (unsigned long long)len);
                 return -EIO;
         }
...
We only check handle if NULL when filesystem has journal. There is need
check handle if NULL even when filesystem has no journal.
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20211223015506.297766-1-yebin10@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc1
commit 298b5c52
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RPAD?from=project-issue
CVE: NA

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

We got issue as follows when run syzkaller test:
[ 1901.130043] EXT4-fs error (device vda): ext4_remount:5624: comm syz-executor.5: Abort forced by user
[ 1901.130901] Aborting journal on device vda-8.
[ 1901.131437] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.16: Detected aborted journal
[ 1901.131566] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.11: Detected aborted journal
[ 1901.132586] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.18: Detected aborted journal
[ 1901.132751] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.9: Detected aborted journal
[ 1901.136149] EXT4-fs error (device vda) in ext4_reserve_inode_write:6035: Journal has aborted
[ 1901.136837] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-fuzzer: Detected aborted journal
[ 1901.136915] ==================================================================
[ 1901.138175] BUG: KASAN: null-ptr-deref in __ext4_journal_ensure_credits+0x74/0x140 [ext4]
[ 1901.138343] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.13: Detected aborted journal
[ 1901.138398] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.1: Detected aborted journal
[ 1901.138808] Read of size 8 at addr 0000000000000000 by task syz-executor.17/968
[ 1901.138817]
[ 1901.138852] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.30: Detected aborted journal
[ 1901.144779] CPU: 1 PID: 968 Comm: syz-executor.17 Not tainted 4.19.90-vhulk2111.1.0.h893.eulerosv2r10.aarch64+ #1
[ 1901.146479] Hardware name: linux,dummy-virt (DT)
[ 1901.147317] Call trace:
[ 1901.147552]  dump_backtrace+0x0/0x2d8
[ 1901.147898]  show_stack+0x28/0x38
[ 1901.148215]  dump_stack+0xec/0x15c
[ 1901.148746]  kasan_report+0x108/0x338
[ 1901.149207]  __asan_load8+0x58/0xb0
[ 1901.149753]  __ext4_journal_ensure_credits+0x74/0x140 [ext4]
[ 1901.150579]  ext4_xattr_delete_inode+0xe4/0x700 [ext4]
[ 1901.151316]  ext4_evict_inode+0x524/0xba8 [ext4]
[ 1901.151985]  evict+0x1a4/0x378
[ 1901.152353]  iput+0x310/0x428
[ 1901.152733]  do_unlinkat+0x260/0x428
[ 1901.153056]  __arm64_sys_unlinkat+0x6c/0xc0
[ 1901.153455]  el0_svc_common+0xc8/0x320
[ 1901.153799]  el0_svc_handler+0xf8/0x160
[ 1901.154265]  el0_svc+0x10/0x218
[ 1901.154682] ==================================================================

This issue may happens like this:
	Process1                               Process2
ext4_evict_inode
  ext4_journal_start
   ext4_truncate
     ext4_ind_truncate
       ext4_free_branches
         ext4_ind_truncate_ensure_credits
	   ext4_journal_ensure_credits_fn
	     ext4_journal_restart
	       handle->h_transaction = NULL;
                                           mount -o remount,abort  /mnt
					   -> trigger JBD abort
               start_this_handle -> will return failed
  ext4_xattr_delete_inode
    ext4_journal_ensure_credits
      ext4_journal_ensure_credits_fn
        __ext4_journal_ensure_credits
	  jbd2_handle_buffer_credits
	    journal = handle->h_transaction->t_journal; ->null-ptr-deref

Now, indirect truncate process didn't handle error. To solve this issue
maybe simply add check handle is abort in '__ext4_journal_ensure_credits'
is enough, and i also think this is necessary.

Cc: stable@kernel.org
Signed-off-by: NYe Bin <yebin10@huawei.com>
Link: https://lore.kernel.org/r/20211224100341.3299128-1-yebin10@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.15-rc2
commit 2f1aaf3e
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RL0T
CVE: NA

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

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

Currently the bpf selftest "get_stack_raw_tp" triggered the warning:

  [ 1411.304463] WARNING: CPU: 3 PID: 140 at include/linux/mmap_lock.h:164 find_vma+0x47/0xa0
  [ 1411.304469] Modules linked in: bpf_testmod(O) [last unloaded: bpf_testmod]
  [ 1411.304476] CPU: 3 PID: 140 Comm: systemd-journal Tainted: G        W  O      5.14.0+ #53
  [ 1411.304479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
  [ 1411.304481] RIP: 0010:find_vma+0x47/0xa0
  [ 1411.304484] Code: de 48 89 ef e8 ba f5 fe ff 48 85 c0 74 2e 48 83 c4 08 5b 5d c3 48 8d bf 28 01 00 00 be ff ff ff ff e8 2d 9f d8 00 85 c0 75 d4 <0f> 0b 48 89 de 48 8
  [ 1411.304487] RSP: 0018:ffffabd440403db8 EFLAGS: 00010246
  [ 1411.304490] RAX: 0000000000000000 RBX: 00007f00ad80a0e0 RCX: 0000000000000000
  [ 1411.304492] RDX: 0000000000000001 RSI: ffffffff9776b144 RDI: ffffffff977e1b0e
  [ 1411.304494] RBP: ffff9cf5c2f50000 R08: ffff9cf5c3eb25d8 R09: 00000000fffffffe
  [ 1411.304496] R10: 0000000000000001 R11: 00000000ef974e19 R12: ffff9cf5c39ae0e0
  [ 1411.304498] R13: 0000000000000000 R14: 0000000000000000 R15: ffff9cf5c39ae0e0
  [ 1411.304501] FS:  00007f00ae754780(0000) GS:ffff9cf5fba00000(0000) knlGS:0000000000000000
  [ 1411.304504] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [ 1411.304506] CR2: 000000003e34343c CR3: 0000000103a98005 CR4: 0000000000370ee0
  [ 1411.304508] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [ 1411.304510] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  [ 1411.304512] Call Trace:
  [ 1411.304517]  stack_map_get_build_id_offset+0x17c/0x260
  [ 1411.304528]  __bpf_get_stack+0x18f/0x230
  [ 1411.304541]  bpf_get_stack_raw_tp+0x5a/0x70
  [ 1411.305752] RAX: 0000000000000000 RBX: 5541f689495641d7 RCX: 0000000000000000
  [ 1411.305756] RDX: 0000000000000001 RSI: ffffffff9776b144 RDI: ffffffff977e1b0e
  [ 1411.305758] RBP: ffff9cf5c02b2f40 R08: ffff9cf5ca7606c0 R09: ffffcbd43ee02c04
  [ 1411.306978]  bpf_prog_32007c34f7726d29_bpf_prog1+0xaf/0xd9c
  [ 1411.307861] R10: 0000000000000001 R11: 0000000000000044 R12: ffff9cf5c2ef60e0
  [ 1411.307865] R13: 0000000000000005 R14: 0000000000000000 R15: ffff9cf5c2ef6108
  [ 1411.309074]  bpf_trace_run2+0x8f/0x1a0
  [ 1411.309891] FS:  00007ff485141700(0000) GS:ffff9cf5fae00000(0000) knlGS:0000000000000000
  [ 1411.309896] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [ 1411.311221]  syscall_trace_enter.isra.20+0x161/0x1f0
  [ 1411.311600] CR2: 00007ff48514d90e CR3: 0000000107114001 CR4: 0000000000370ef0
  [ 1411.312291]  do_syscall_64+0x15/0x80
  [ 1411.312941] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [ 1411.313803]  entry_SYSCALL_64_after_hwframe+0x44/0xae
  [ 1411.314223] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  [ 1411.315082] RIP: 0033:0x7f00ad80a0e0
  [ 1411.315626] Call Trace:
  [ 1411.315632]  stack_map_get_build_id_offset+0x17c/0x260

To reproduce, first build `test_progs` binary:

  make -C tools/testing/selftests/bpf -j60

and then run the binary at tools/testing/selftests/bpf directory:

  ./test_progs -t get_stack_raw_tp

The warning is due to commit 5b78ed24 ("mm/pagemap: add mmap_assert_locked()
annotations to find_vma*()") which added mmap_assert_locked() in find_vma()
function. The mmap_assert_locked() function asserts that mm->mmap_lock needs
to be held. But this is not the case for bpf_get_stack() or bpf_get_stackid()
helper (kernel/bpf/stackmap.c), which uses mmap_read_trylock_non_owner()
instead. Since mm->mmap_lock is not held in bpf_get_stack[id]() use case,
the above warning is emitted during test run.

This patch fixed the issue by (1). using mmap_read_trylock() instead of
mmap_read_trylock_non_owner() to satisfy lockdep checking in find_vma(), and
(2). droping lockdep for mmap_lock right before the irq_work_queue(). The
function mmap_read_trylock_non_owner() is also removed since after this
patch nobody calls it any more.

Fixes: 5b78ed24 ("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()")
Suggested-by: NJason Gunthorpe <jgg@ziepe.ca>
Signed-off-by: NYonghong Song <yhs@fb.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Reviewed-by: NLiam R. Howlett <Liam.Howlett@oracle.com>
Cc: Luigi Rizzo <lrizzo@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-mm@kvack.org
Link: https://lore.kernel.org/bpf/20210909155000.1610299-1-yhs@fb.com
(cherry picked from commit 2f1aaf3e)
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.15-rc1
commit 10994316
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RL0T
CVE: NA

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

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

Print to the trace log before releasing the lock to avoid racing with
other trace log printers of the same lock type.

Link: https://lkml.kernel.org/r/20210903022041.1843024-1-Liam.Howlett@oracle.comSigned-off-by: NLiam R. Howlett <Liam.Howlett@oracle.com>
Suggested-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: NMatthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michel Lespinasse <walken.cr@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 10994316)
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.14-rc3
commit e904c2cc
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RL0T
CVE: NA

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

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

Commit 832b5072 ("mm: mmap_lock: use local locks instead of
disabling preemption") fixed a bug by using local locks.

But commit d01079f3 ("mm/mmap_lock: remove dead code for
!CONFIG_TRACING configurations") changed those lines back to the
original version.

I guess it was introduced by fixing conflicts.

Link: https://lkml.kernel.org/r/20210720074228.76342-1-songmuchun@bytedance.com
Fixes: d01079f3 ("mm/mmap_lock: remove dead code for !CONFIG_TRACING configurations")
Signed-off-by: NMuchun Song <songmuchun@bytedance.com>
Acked-by: NMel Gorman <mgorman@techsingularity.net>
Reviewed-by: NYang Shi <shy828301@gmail.com>
Reviewed-by: NPankaj Gupta <pankaj.gupta@ionos.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit e904c2cc)
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.14-rc1
commit d01079f3
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RL0T
CVE: NA

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

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

make W=1 generates the following warning in mmap_lock.c for allnoconfig

  mm/mmap_lock.c:213:6: warning: no previous prototype for `__mmap_lock_do_trace_start_locking' [-Wmissing-prototypes]
   void __mmap_lock_do_trace_start_locking(struct mm_struct *mm, bool write)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  mm/mmap_lock.c:219:6: warning: no previous prototype for `__mmap_lock_do_trace_acquire_returned' [-Wmissing-prototypes]
   void __mmap_lock_do_trace_acquire_returned(struct mm_struct *mm, bool write,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  mm/mmap_lock.c:226:6: warning: no previous prototype for `__mmap_lock_do_trace_released' [-Wmissing-prototypes]
   void __mmap_lock_do_trace_released(struct mm_struct *mm, bool write)

On !CONFIG_TRACING configurations, the code is dead so put it behind an
#ifdef.

[cuibixuan@huawei.com: fix warning when CONFIG_TRACING is not defined]
  Link: https://lkml.kernel.org/r/20210531033426.74031-1-cuibixuan@huawei.com

Link: https://lkml.kernel.org/r/20210520084809.8576-13-mgorman@techsingularity.netSigned-off-by: NMel Gorman <mgorman@techsingularity.net>
Signed-off-by: NBixuan Cui <cuibixuan@huawei.com>
Reviewed-by: NYang Shi <shy828301@gmail.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d01079f3)
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.14-rc1
commit 832b5072
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RL0T
CVE: NA

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

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

mmap_lock will explicitly disable/enable preemption upon manipulating its
local CPU variables.  This is to be expected, but in this case, it doesn't
play well with PREEMPT_RT.  The preemption disabled code section also
takes a spin-lock.  Spin-locks in RT systems will try to schedule, which
is exactly what we're trying to avoid.

To mitigate this, convert the explicit preemption handling to local_locks.
Which are RT aware, and will disable migration instead of preemption when
PREEMPT_RT=y.

The faulty call trace looks like the following:
    __mmap_lock_do_trace_*()
      preempt_disable()
      get_mm_memcg_path()
        cgroup_path()
          kernfs_path_from_node()
            spin_lock_irqsave() /* Scheduling while atomic! */

Link: https://lkml.kernel.org/r/20210604163506.2103900-1-nsaenzju@redhat.com
Fixes: 2b5067a8 ("mm: mmap_lock: add tracepoints around lock acquisition ")
Signed-off-by: NNicolas Saenz Julienne <nsaenzju@redhat.com>
Tested-by: NAxel Rasmussen <axelrasmussen@google.com>
Reviewed-by: NAxel Rasmussen <axelrasmussen@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 832b5072)
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.11-rc1
commit 2b5067a8
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RL0T
CVE: NA

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

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

The goal of these tracepoints is to be able to debug lock contention
issues.  This lock is acquired on most (all?) mmap / munmap / page fault
operations, so a multi-threaded process which does a lot of these can
experience significant contention.

We trace just before we start acquisition, when the acquisition returns
(whether it succeeded or not), and when the lock is released (or
downgraded).  The events are broken out by lock type (read / write).

The events are also broken out by memcg path.  For container-based
workloads, users often think of several processes in a memcg as a single
logical "task", so collecting statistics at this level is useful.

The end goal is to get latency information.  This isn't directly included
in the trace events.  Instead, users are expected to compute the time
between "start locking" and "acquire returned", using e.g.  synthetic
events or BPF.  The benefit we get from this is simpler code.

Because we use tracepoint_enabled() to decide whether or not to trace,
this patch has effectively no overhead unless tracepoints are enabled at
runtime.  If tracepoints are enabled, there is a performance impact, but
how much depends on exactly what e.g.  the BPF program does.

[axelrasmussen@google.com: fix use-after-free race and css ref leak in tracepoints]
  Link: https://lkml.kernel.org/r/20201130233504.3725241-1-axelrasmussen@google.com
[axelrasmussen@google.com: v3]
  Link: https://lkml.kernel.org/r/20201207213358.573750-1-axelrasmussen@google.com
[rostedt@goodmis.org: in-depth examples of tracepoint_enabled() usage, and per-cpu-per-context buffer design]

Link: https://lkml.kernel.org/r/20201105211739.568279-2-axelrasmussen@google.comSigned-off-by: NAxel Rasmussen <axelrasmussen@google.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Jann Horn <jannh@google.com>
Cc: Chinwen Chang <chinwen.chang@mediatek.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 2b5067a8)
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.17-rc1
commit 5c48a7df
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RN96
CVE: NA

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

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

Our syzkaller report an use-after-free issue that accessing the freed
buffer_head on the writeback page in __ext4_journalled_writepage(). The
problem is that if there was a truncate racing with the data=journalled
writeback procedure, the writeback length could become zero and
bget_one() refuse to get buffer_head's refcount, then the truncate
procedure release buffer once we drop page lock, finally, the last
ext4_walk_page_buffers() trigger the use-after-free problem.

sync                               truncate
ext4_sync_file()
 file_write_and_wait_range()
                                   ext4_setattr(0)
                                    inode->i_size = 0
  ext4_writepage()
   len = 0
   __ext4_journalled_writepage()
    page_bufs = page_buffers(page)
    ext4_walk_page_buffers(bget_one) <- does not get refcount
                                    do_invalidatepage()
                                      free_buffer_head()
    ext4_walk_page_buffers(page_bufs) <- trigger use-after-free

After commit bdf96838 ("ext4: fix race between truncate and
__ext4_journalled_writepage()"), we have already handled the racing
case, so the bget_one() and bput_one() are not needed. So this patch
simply remove these hunk, and recheck the i_size to make it safe.

Fixes: bdf96838 ("ext4: fix race between truncate and __ext4_journalled_writepage()")
Signed-off-by: NZhang Yi <yi.zhang@huawei.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211225090937.712867-1-yi.zhang@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>

Conflict:
	fs/ext4/inode.c
Signed-off-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NYe bin <yebin10@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euleros inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4QPBH
CVE: NA

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

1. Improve pin mem pages rmap:
Add Hotreplace flag for pin mem pages to avoid spilting.
When the Hotreplace flag is set, the page will not be
added to deferred_split page list during rmap.
If the pin mem pages added to the deferred_split page list,
deferred_split_scan ops will spilt the pages which has been pinned.
If the pin mem page is spilted, we can't remap the page to the recover
process with the recorded pin mem mapping rule.
Moreover, the deferred_split page list node can be corrupted while the
deferred_split_scan function and pin pages remapping executing at the
same time.

2. Improve free method for pin mem pages:
Use the put_page method instead of free_pages directly.
Signed-off-by: NJingxian He <hejingxian@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euleros inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4QPBH
CVE: NA

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

Use PG_hotreplace flag to mark pin pages which need to be hotreplaced
to the recover process.
Signed-off-by: NJingxian He <hejingxian@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euleros inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4REE5
CVE: NA

------------
1.Refactor pin memory mem reserve:
Move the memory reserve functions to pin_mem.c,
and avoid using unnecessary macros.

2.Refactor pid reserve code:
In oder to avoid using unnecessary compile macros in pid.c,
add stub functions for free_reserved_pid and reserve_pids.
Signed-off-by: NJingxian He <hejingxian@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 186133 https://gitee.com/openeuler/kernel/issues/I4RGWS?from=project-issue
CVE: NA

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

When we add "audit=1" to the cmdline, if we keep the audit_hold_queue
non-empty, flush the hold queue will fall into an infinite loop. So we
need to fix it by stoping flush the hold queue when netlink abnormal.

Fixes: bd8698d8 ("audit: improve robustness of the audit queue handling")
Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com>
Reviewed-by: Nweiyang wang <wangweiyang2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://e.gitee.com/open_euler/issues/list?issue=I4QSVV
CVE: NA

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

The commit 587e6c10 ("iommu/arm-smmu-v3: Add and use static helper
function arm_smmu_cmdq_issue_cmd_with_sync()") is backported from RFC
version. Some minor changes are made to the patch when it is merged into
the mainline, see the following link:
Link: https://www.spinics.net/lists/arm-kernel/msg914548.html

In addition, there are two patches based on earlier mainline that still
incorrectly use arm_smmu_cmdq_issue_sync(), fix them.

Fixes: 3e630336 ("iommu/arm-smmu-v3: Seize private ASID")
Fixes: 04039cc9 ("iommu/smmuv3: Implement cache_invalidate")
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Ipvlan l2e mode will cache skbuff for local xmit in
ipvlan_xmit_mode_l2e. But when tso/gso is disabled,
this would result in performance loss.

So we should stop caching the skbuff when tso/gso is
disabled.
Signed-off-by: NMiaohe Lin <linmiaohe@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NKeefe Liu <liuqifa@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NYuehaibing <yuehaibing@huawei.com>
Reviewed-by: NWenan Mao <maowenan@huawei.com>
Signed-off-by: NChen Zhou <chenzhou10@huawei.com>
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

In '6ab91856 ("watchdog: Fix check_preemption_disabled() error")', we
tried to fix check_preemption_disabled() error by disabling preemption in
hardlockup_detector_perf_init(), but missed that function
perf_event_create_kernel_counter() may sleep.

To fix the issue fully, reimplement hardlockup_detector_perf_init()
through smp_call_on_cpu() instead of disabling preemption.

Fixes: 6ab91856 ("watchdog: Fix check_preemption_disabled() error")
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-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/I48H9Z?from=project-issue
CVE: NA

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

The compressed data and decompressed data is separated. There is no need to save
the uncompressed data to remaining_data buffer, can directly read data from the
uncompressed skb.
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I48H9Z?from=project-issue
CVE: NA

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

In order to separate the compressed data and decompressed data, this patch adds
dpkt to tcp_comp_context_rx, dpkt is used to save decompressed skb.
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I48H9Z?from=project-issue
CVE: NA

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

This patch fixes possible ZSTD_decompressStream failures. When decompressing
skb->data, should skip the previous rxm->offset data.
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I47SV5?from=project-issue
CVE: NA

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

In comp_read_size rxm->offset should be subtracted from skb->len. And use
strp_done to release resoureces when destroy sock.
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I45UYC?from=project-issue
CVE: NA

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

In comp_stream_read ctx might be null, add null check to avoid oops. And delete
unnecessary tcp_comp_err_abort.
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Open configs for tcp compression
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

This patch implement software level compression for
receiving tcp messages. The compressed TCP payload will be
decompressed after receive.
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>