- 22 1月, 2022 3 次提交
-
-
由 Wang Yufen 提交于
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>
-
由 Wang Yufen 提交于
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>
-
由 Wei Yongjun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4PNEK CVE: NA ------------------------------------------------- This patch implement software level compression for sending tcp messages. All of the TCP payload will be compressed before xmit. Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> 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: NWang Yufen <wangyufen@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 20 1月, 2022 22 次提交
-
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 44483ea0. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 8b45f57c. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit bfa5c4c1. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit d668f5ea. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 37870264. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 33adabdd. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 1bbe05d2. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit ad7ae387. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 6d7dd529. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 189fa7a4. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 247b8dd6. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit fe426fa7. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Jiahua 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QU5Z?from=project-issue CVE: NA -------------------------------- This patch revert ias feature from open-euler kernel. This reverts commit 17b31a72. Signed-off-by: NYu Jiahua <Yujiahua1@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4R7RE CVE: NA ----------------------------------------------- blkio subsytem is not under default hierarchy in cgroup v1 by default, which means configurations will only be effective on current cgroup for io throttle. This patch introduces a new feature that enable default hierarchy for io throttle, which means configurations will be effective on child cgroups. Such feature is disabled by default, and can be enabled by adding "blkcg_global_limit=1" or "blkcg_global_limit=Y" or "blkcg_global_limit=y" in boot cmd. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NTao Hou <houtao1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 zhangwensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4QXS1?from=project-issue CVE: NA -------------------------------- UBSAN reports this problem: [ 5984.281385] UBSAN: Undefined behaviour in drivers/md/md.c:8175:15 [ 5984.281390] signed integer overflow: [ 5984.281393] -2147483291 - 2072033152 cannot be represented in type 'int' [ 5984.281400] CPU: 25 PID: 1854 Comm: md101_resync Kdump: loaded Not tainted 4.19.90 [ 5984.281404] Hardware name: Huawei TaiShan 200 (Model 5280)/BC82AMDDA [ 5984.281406] Call trace: [ 5984.281415] dump_backtrace+0x0/0x310 [ 5984.281418] show_stack+0x28/0x38 [ 5984.281425] dump_stack+0xec/0x15c [ 5984.281430] ubsan_epilogue+0x18/0x84 [ 5984.281434] handle_overflow+0x14c/0x19c [ 5984.281439] __ubsan_handle_sub_overflow+0x34/0x44 [ 5984.281445] is_mddev_idle+0x338/0x3d8 [ 5984.281449] md_do_sync+0x1bb8/0x1cf8 [ 5984.281452] md_thread+0x220/0x288 [ 5984.281457] kthread+0x1d8/0x1e0 [ 5984.281461] ret_from_fork+0x10/0x18 When the stat aacum of the disk is greater than INT_MAX, its value becomes negative after casting to 'int', which may lead to overflow after subtracting a positive number. In the same way, when the value of sync_io is greater than INT_MAX,overflow may also occur. These situations will lead to undefined behavior. Otherwise, if the stat accum of the disk is close to INT_MAX when creating raid arrays, the initial value of last_events would be set close to INT_MAX when mddev initializes IO event counters. 'curr_events - rdev->last_events > 64' will always false during synchronization. If all the disks of mddev are in this case, is_mddev_idle() will always return 1, which may cause non-sync IO is very slow. To address these problems, need to use 64bit signed integer type for sync_io,last_events, and curr_events. Signed-off-by: Nzhangwensheng <zhangwensheng5@huawei.com> Reviewed-by: NTao Hou <houtao1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lu Jialin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4IMAK?from=project-issue CVE: NA -------- when CONFIG_MEMCG = n, compile error occurs mm/vmscan.c: In function ‘is_memcg_kswapd_stopped’: mm/vmscan.c:2849:11: error: dereferencing pointer to incomplete type ‘struct mem_cgroup’ if (memcg->memory.max == PAGE_COUNTER_MAX) Fix the error by modify is_memcg_kswapd_stopped function return false when CONFIG_MEMCG = n v2: add compile error message in commit msg Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: Nweiyang wang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Darrick J. Wong 提交于
mainline inclusion from mainline-v5.16-rc5 commit 983d8e60 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCES CVE: CVE-2021-4155 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=983d8e60f50806f90534cc5373d0ce867e5aaf79 -------------------------------- The old ALLOCSP/FREESP ioctls in XFS can be used to preallocate space at the end of files, just like fallocate and RESVSP. Make the behavior consistent with the other ioctls. Reported-by: NKirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com> Reviewed-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NEric Sandeen <sandeen@redhat.com> Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Feng Tiantian 提交于
euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4RA6U CVE: NA ------------------------------------------------- While using "top" on a CentOS guest's VNC-client, then continuously press "Shift+PgUp", the guest kernel will get panic! Backtrace is attached below. We tested it on 5.2.0, and the issue remains. [ 66.946362] Unable to handle kernel paging request at virtual address ffff00000e240840 [ 66.946363] Mem abort info: [ 66.946364] Exception class = DABT (current EL), IL = 32 bits [ 66.946365] SET = 0, FnV = 0 [ 66.946366] EA = 0, S1PTW = 0 [ 66.946367] Data abort info: [ 66.946368] ISV = 0, ISS = 0x00000047 [ 66.946368] CM = 0, WnR = 1 [ 66.946370] swapper pgtable: 64k pages, 48-bit VAs, pgd = ffff000009660000 [ 66.946372] [ffff00000e240840] *pgd=000000023ffe0003, *pud=000000023ffe0003, *pmd=000000023ffd0003, *pte=0000000000000000 [ 66.946378] Internal error: Oops: 96000047 [#1] SMP [ 66.946379] Modules linked in: vfat fat crc32_ce ghash_ce sg sha2_ce sha256_arm64 virtio_balloon virtio_net sha1_ce ip_tables ext4 mbcache jbd2 virtio_gpu drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm i2c_core virtio_scsi virtio_pci virtio_mmio virtio_ring virtio [ 66.946403] CPU: 0 PID: 1035 Comm: top Not tainted 4.14.0-49.el7a.aarch64 #1 [ 66.946404] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 66.946405] task: ffff8001c18fdc00 task.stack: ffff00000d4e0000 [ 66.946409] PC is at sys_imageblit+0x40c/0x10000 [sysimgblt] [ 66.946431] LR is at drm_fb_helper_sys_imageblit+0x28/0x4c [drm_kms_helper] [ 66.946433] pc : [<ffff0000020a040c>] lr : [<ffff000002202e74>] pstate: 00000005 [ 66.946433] sp : ffff00000d4ef7f0 [ 66.946434] x29: ffff00000d4ef7f0 x28: 00000000000001ff [ 66.946436] x27: ffff8001c1c88100 x26: 0000000000000001 [ 66.946438] x25: 00000000000001f0 x24: 0000000000000018 [ 66.946440] x23: 0000000000000000 x22: ffff00000d4ef978 [ 66.946442] x21: ffff00000e240840 x20: 0000000000000000 [ 66.946444] x19: ffff8001c98c9000 x18: 0000fffff9d56670 [ 66.946445] x17: 0000000000000000 x16: 0000000000000000 [ 66.946447] x15: 0000000000000008 x14: 1b20202020202020 [ 66.946449] x13: 00000000000001f0 x12: 000000000000003e [ 66.946450] x11: 000000000000000f x10: ffff8001c8400000 [ 66.946452] x9 : 0000000000aaaaaa x8 : 0000000000000001 [ 66.946454] x7 : ffff0000020b0090 x6 : 0000000000000001 [ 66.946456] x5 : 0000000000000000 x4 : 0000000000000000 [ 66.946457] x3 : ffff8001c8400000 x2 : ffff00000e240840 [ 66.946459] x1 : 00000000000001ef x0 : 0000000000000007 [ 66.946461] Process top (pid: 1035, stack limit = 0xffff00000d4e0000) [ 66.946462] Call trace: [ 66.946464] Exception stack(0xffff00000d4ef6b0 to 0xffff00000d4ef7f0) [ 66.946465] f6a0: 0000000000000007 00000000000001ef [ 66.946467] f6c0: ffff00000e240840 ffff8001c8400000 0000000000000000 0000000000000000 [ 66.946468] f6e0: 0000000000000001 ffff0000020b0090 0000000000000001 0000000000aaaaaa [ 66.946470] f700: ffff8001c8400000 000000000000000f 000000000000003e 00000000000001f0 [ 66.946471] f720: 1b20202020202020 0000000000000008 0000000000000000 0000000000000000 [ 66.946472] f740: 0000fffff9d56670 ffff8001c98c9000 0000000000000000 ffff00000e240840 [ 66.946474] f760: ffff00000d4ef978 0000000000000000 0000000000000018 00000000000001f0 [ 66.946475] f780: 0000000000000001 ffff8001c1c88100 00000000000001ff ffff00000d4ef7f0 [ 66.946476] f7a0: ffff000002202e74 ffff00000d4ef7f0 ffff0000020a040c 0000000000000005 [ 66.946478] f7c0: ffff00000d4ef7e0 ffff0000080ea614 0001000000000000 ffff000008152f08 [ 66.946479] f7e0: ffff00000d4ef7f0 ffff0000020a040c [ 66.946481] [<ffff0000020a040c>] sys_imageblit+0x40c/0x10000 [sysimgblt] [ 66.946501] [<ffff000002202e74>] drm_fb_helper_sys_imageblit+0x28/0x4c [drm_kms_helper] [ 66.946510] [<ffff0000022a12dc>] virtio_gpu_3d_imageblit+0x2c/0x78 [virtio_gpu] [ 66.946515] [<ffff00000847f458>] bit_putcs+0x288/0x49c [ 66.946517] [<ffff00000847ad24>] fbcon_putcs+0x114/0x148 [ 66.946519] [<ffff0000084fe92c>] do_update_region+0x118/0x19c [ 66.946521] [<ffff00000850413c>] do_con_trol+0x114c/0x1314 [ 66.946523] [<ffff0000085044dc>] do_con_write.part.22+0x1d8/0x890 [ 66.946525] [<ffff000008504c88>] con_write+0x84/0x8c [ 66.946527] [<ffff0000084ec7f0>] n_tty_write+0x19c/0x408 [ 66.946529] [<ffff0000084e9120>] tty_write+0x150/0x270 [ 66.946532] [<ffff00000829d558>] __vfs_write+0x58/0x180 [ 66.946534] [<ffff00000829d880>] vfs_write+0xa8/0x1a0 [ 66.946536] [<ffff00000829db40>] SyS_write+0x60/0xc0 [ 66.946537] Exception stack(0xffff00000d4efec0 to 0xffff00000d4f0000) [ 66.946539] fec0: 0000000000000001 0000000000457958 0000000000000800 0000000000000000 [ 66.946540] fee0: 00000000fbad2885 0000000000000bd0 0000ffff8556add4 0000000000000000 [ 66.946541] ff00: 0000000000000040 0000000000000000 0000000000434a88 0000000000000012 [ 66.946543] ff20: 0000000100000000 0000fffff9d564f0 0000fffff9d564a0 0000000000000008 [ 66.946544] ff40: 0000000000000000 0000ffff85593b1c 0000fffff9d56670 0000000000000800 [ 66.946546] ff60: 0000000000457958 0000ffff856a1158 0000000000000800 0000ffff85720000 [ 66.946547] ff80: 0000000000000000 0000ffff856f604c 0000000000000000 0000000000436000 [ 66.946548] ffa0: 000000001c90a160 0000fffff9d56f20 0000ffff855965f4 0000fffff9d56f20 [ 66.946549] ffc0: 0000ffff855f12c8 0000000020000000 0000000000000001 0000000000000040 [ 66.946551] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 66.946554] [<ffff00000808359c>] __sys_trace_return+0x0/0x4 [ 66.946556] Code: 0a080084 b86478e4 0a040124 4a050084 (b9000044) [ 66.946561] ---[ end trace 32d49c68b19c4796 ]--- [ 66.946562] Kernel panic - not syncing: Fatal exception [ 66.946564] SMP: stopping secondary CPUs [ 66.946596] Kernel Offset: disabled [ 66.946598] CPU features: 0x1802008 [ 66.946598] Memory Limit: none [ 67.092353] ---[ end Kernel panic - not syncing: Fatal exception From our non-expert analysis, fbcon ypos will sometimes over boundary and then fbcon_putcs() access invalid VGA framebuffer address. We modify the real_y() to make sure fbcon ypos is always less than rows. Reported-by: NZengruan Ye <yezengruan@huawei.com> Signed-off-by: NFeng Tiantian <fengtiantian@huawei.com> Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Link: https://gitee.com/openeuler/kernel/commit/45aa9689e6d2Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Barry Song 提交于
mainline inclusion from mainline-v5.11 commit 1ec3b5fe category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QEIH CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/zswap.c?id=1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161 ---------------------------------------------------------------------- Right now, all new ZIP drivers are adapted to crypto_acomp APIs rather than legacy crypto_comp APIs. Tradiontal ZIP drivers like lz4,lzo etc have been also wrapped into acomp via scomp backend. But zswap.c is still using the old APIs. That means zswap won't be able to work on any new ZIP drivers in kernel. This patch moves to use cryto_acomp APIs to fix the disconnected bridge between new ZIP drivers and zswap. It is probably the first real user to use acomp but perhaps not a good example to demonstrate how multiple acomp requests can be executed in parallel in one acomp instance. frontswap is doing page load and store page by page synchronously. swap_writepage() depends on the completion of frontswap_store() to decide if it should call __swap_writepage() to swap to disk. However this patch creates multiple acomp instances, so multiple threads running on multiple different cpus can actually do (de)compression parallelly, leveraging the power of multiple ZIP hardware queues. This is also consistent with frontswap's page management model. The old zswap code uses atomic context and avoids the race conditions while shared resources like zswap_dstmem are accessed. Here since acomp can sleep, per-cpu mutex is used to replace preemption-disable. While it is possible to make mm/page_io.c and mm/frontswap.c support async (de)compression in some way, the entire design requires careful thinking and performance evaluation. For the first step, the base with fixed connection between ZIP drivers and zswap should be built. Link: https://lkml.kernel.org/r/20201107065332.26992-1-song.bao.hua@hisilicon.comSigned-off-by: NBarry Song <song.bao.hua@hisilicon.com> Acked-by: NVitaly Wool <vitalywool@gmail.com> Cc: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: David S. Miller <davem@davemloft.net> Cc: Mahipal Challa <mahipalreddy2006@gmail.com> Cc: Seth Jennings <sjenning@redhat.com> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Zhou Wang <wangzhou1@hisilicon.com> Cc: Colin Ian King <colin.king@canonical.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Reviewed-by: NHao Fang <fanghao11@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Di Zhu 提交于
mainline inclusion from mainline-v5.13-rc1 commit c1102e9d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I4RJ4X CVE: NA ---------------------------- We encountered a crash: in the packet receiving process, we got an illegal VLAN device address, but the VLAN device address saved in vmcore is correct. After checking the code, we found a possible data competition: CPU 0: CPU 1: (RCU read lock) (RTNL lock) vlan_do_receive() register_vlan_dev() vlan_find_dev() ->__vlan_group_get_device() ->vlan_group_prealloc_vid() In vlan_group_prealloc_vid(), We need to make sure that memset() in kzalloc() is executed before assigning value to vlan devices array: ================================= kzalloc() ->memset(object, 0, size) smp_wmb() vg->vlan_devices_arrays[pidx][vidx] = array; ================================== Because __vlan_group_get_device() function depends on this order. otherwise we may get a wrong address from the hardware cache on another cpu. So fix it by adding memory barrier instruction to ensure the order of memory operations. Signed-off-by: NDi Zhu <zhudi21@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 gaoxingwang 提交于
mainline inclusion from mainline-v5.16-rc5 category: bugfix commit 57fb346c bugzilla: https://gitee.com/openeuler/kernel/issues/I4NDLN CVE: NA ---------------------- When an ipvlan device is created on a bond device, the link state of the ipvlan device may be abnormal. This is because bonding device allows to add physical network card device in the down state and so NETDEV_CHANGE event will not be notified to other listeners, so ipvlan has no chance to update its link status. The following steps can cause such problems: 1) bond0 is down 2) ip link add link bond0 name ipvlan type ipvlan mode l2 3) echo +enp2s7 >/sys/class/net/bond0/bonding/slaves 4) ip link set bond0 up After these steps, use ip link command, we found ipvlan has NO-CARRIER: ipvlan@bond0: <NO-CARRIER, BROADCAST,MULTICAST,UP,M-DOWN> mtu ...> We can deal with this problem like VLAN: Add handling of NETDEV_UP events. If we receive NETDEV_UP event, we will update the link status of the ipvlan. Signed-off-by: Ngaoxingwang <gaoxingwang@huawei.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Signed-off-by: Ngaoxingwang <gaoxingwang@huawei.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Smita Koralahalli 提交于
mainline inclusion from mainline-v5.13-rc1 commit da666586 category: feature feature: milan cpu bugzilla: https://gitee.com/openeuler/kernel/issues/I4OBEH?from=project-issue CVE: NA -------------------------------- Add PMU events for AMD Zen3 processors as documented in the AMD Processor Programming Reference for Family 19h and Model 01h [1]. Below are the events which are new on Zen3: PMCx041 ls_mab_alloc.{all_allocations|hardware_prefetcher_allocations|load_store_allocations} PMCx043 ls_dmnd_fills_from_sys.ext_cache_local PMCx044 ls_any_fills_from_sys.{mem_io_remote|ext_cache_remote|mem_io_local|ext_cache_local|int_cache|lcl_l2} PMCx047 ls_misal_loads.{ma4k|ma64} PMCx059 ls_sw_pf_dc_fills.ext_cache_local PMCx05a ls_hw_pf_dc_fills.ext_cache_local PMCx05f ls_alloc_mab_count PMCx085 bp_l1_tlb_miss_l2_tlb_miss.coalesced_4k PMCx0ab de_dis_cops_from_decoder.disp_op_type.{any_integer_dispatch|any_fp_dispatch} PMCx0cc ex_ret_ind_brch_instr PMCx18e ic_tag_hit_miss.{all_instruction_cache_accesses|instruction_cache_miss|instruction_cache_hit} PMCx1c7 ex_ret_msprd_brnch_instr_dir_msmtch PMCx28f op_cache_hit_miss.{all_op_cache_accesses|op_cache_miss|op_cache_hit} Section 2.1.17.2 "Performance Measurement" of "PPR for AMD Family 19h, Model 01h, Revision B1 Processors - 55898 Rev 0.35 - Feb 5, 2021." lists new metrics. Add them. Preserve the events for Zen3 if they are measurable and non-zero as taken from Zen2 directory even if the PPR of Zen3 [1] omits them. Those events are the following: PMCx000 fpu_pipe_assignment.{total|total0|total1|total2|total3} PMCx004 fp_num_mov_elim_scal_op.{optimized|opt_potential|sse_mov_ops_elim|sse_mov_ops} PMCx02D ls_rdtsc PMCx040 ls_dc_accesses PMCx046 ls_tablewalker.{iside|ic_type1|ic_type0|dside|dc_type1|dc_type0} PMCx061 l2_request_g2.{group1|ls_rd_sized|ls_rd_sized_nc|ic_rd_sized|ic_rd_sized_nc|smc_inval|bus_lock_originator|bus_locks_responses} PMCx062 l2_latency.l2_cycles_waiting_on_fills PMCx063 l2_wcb_req.{wcb_write|wcb_close|zero_byte_store|cl_zero} PMCx06d l2_fill_pending.l2_fill_busy PMCx080 ic_fw32 PMCx081 ic_fw32_miss PMCx086 bp_snp_re_sync PMCx087 ic_fetch_stall.{ic_stall_any|ic_stall_dq_empty|ic_stall_back_pressure} PMCx08a bp_l1_btb_correct PMCx08c ic_cache_inval.{l2_invalidating_probe|fill_invalidated} PMCx099 bp_tlb_rel PMCx0a9 de_dis_uop_queue_empty_di0 PMCx0c7 ex_ret_brn_resync PMCx28a ic_oc_mode_switch.{oc_ic_mode_switch|ic_oc_mode_switch} L3PMCx01 l3_request_g1.caching_l3_cache_accesses L3PMCx06 l3_comb_clstr_state.{other_l3_miss_typs|request_miss} [1] Processor Programming Reference (PPR) for AMD Family 19h, Model 01h, Revision B1 Processors - 55898 Rev 0.35 - Feb 5, 2021. [2] Processor Programming Reference (PPR) for AMD Family 17h Model 71h, Revision B0 Processors, 56176 Rev 3.06 - Jul 17, 2019. [3] Processor Programming Reference (PPR) for AMD Family 17h Models 01h,08h, Revision B2 Processors, 54945 Rev 3.03 - Jun 14, 2019. All of the PPRs can be found at: https://bugzilla.kernel.org/show_bug.cgi?id=206537Reviewed-by: NRobert Richter <rrichter@amd.com> Signed-off-by: NSmita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kim Phillips <kim.phillips@amd.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Martin Liška <mliska@suse.cz> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vijay Thakkar <vijaythakkar@me.com> Cc: linux-perf-users@vger.kernel.org Link: https://lore.kernel.org/r/20210406215944.113332-5-Smita.KoralahalliChannabasappa@amd.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 19 1月, 2022 15 次提交
-
-
由 nifujia 提交于
mainline inclusion from mainline-v5.16-rc1 commit 21c7e972 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QKP3 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/scsi/hisi_sas?id=21c7e972475e6a975fbe97f8974c96fe4713077c ---------------------------------------------------------------------------------- If the softreset fails in the I_T reset, libsas will then continue to issue a controller reset to try to recover. However a faulty disk may cause the softreset to fail, and resetting the controller will not help this scenario. Indeed, we will just continue the cycle of error handle handling to try to recover. So if the softreset fails upon certain conditions, just disable the phy associated with the disk. The user needs to handle this problem. Link: https://lore.kernel.org/r/1634041588-74824-5-git-send-email-john.garry@huawei.comSigned-off-by: NLuo Jiaxing <luojiaxing@huawei.com> Signed-off-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NOuyangdelong <ouyangdelong@huawei.com> Signed-off-by: NNifujia <nifujia1@hisilicon.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 nifujia 提交于
mainline inclusion from mainline-v5.16-rc1 commit 00aeaf32 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4QKP3 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/scsi/libsas/sas_init.c?id=00aeaf329a3a1ea3d3606fefa1d29f69f828bd21 ----------------------------------------------------------------------------------- Export sas_phy_enable() so LLDDs can directly use it to control remote phys. We already do this for companion function sas_phy_reset(). Link: https://lore.kernel.org/r/1634041588-74824-4-git-send-email-john.garry@huawei.comSigned-off-by: NLuo Jiaxing <luojiaxing@huawei.com> Signed-off-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NOuyangdelong <ouyangdelong@huawei.com> Signed-off-by: NNifujia <nifujia1@hisilicon.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Di Zhu 提交于
mainline-inclusion from mainline-v5.16-rc7 commit 4d293fe1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4RADY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4d293fe1c69c157c15ac06918a805e5fef036682 ------------------------------------------------- The commit 3c9ef511 ("bonding: avoid adding slave device with IFF_MASTER flag") fix a crash when add slave device with IFF_MASTER, but it rejects the scenario of nested bonding device. As Eric Dumazet described: since there indeed is a usage scenario about nesting bonding, we should not break it. So we add a new judgment condition to allow nesting of bonding device. Fixes: 3c9ef511 ("bonding: avoid adding slave device with IFF_MASTER flag") Suggested-by: NJay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: NDi Zhu <zhudi21@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NAichun Li <liaichun@huawei.com> Signed-off-by: NAichun Li <liaichun@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Di Zhu 提交于
mainline-inclusion from mainline-v5.16-rc7 commit 3c9ef511 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4RADY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c9ef511b9fa128a4c62e3aa0aac4c6b190f0d55 ------------------------------------------------- The following steps will definitely cause the kernel to crash: ip link add vrf1 type vrf table 1 modprobe bonding.ko max_bonds=1 echo "+vrf1" >/sys/class/net/bond0/bonding/slaves rmmod bonding The root cause is that: When the VRF is added to the slave device, it will fail, and some cleaning work will be done. because VRF device has IFF_MASTER flag, cleanup process will not clear the IFF_BONDING flag. Then, when we unload the bonding module, unregister_netdevice_notifier() will treat the VRF device as a bond master device and treat netdev_priv() as struct bonding{} which actually is struct net_vrf{}. By analyzing the processing logic of bond_enslave(), it seems that it is not allowed to add the slave device with the IFF_MASTER flag, so we need to add a code check for this situation. Signed-off-by: NDi Zhu <zhudi21@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NAichun Li <liaichun@huawei.com> Signed-off-by: NAichun Li <liaichun@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 jinyiting 提交于
mainline-inclusion from mainline-v5.16-rc7 commit 83d686a6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4RADY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83d686a6822322c4981b745dc1d7185f1f40811b ------------------------------------------------- The bond works in mode 4, and performs down/up operations on the bond that is normally negotiated. The probability of bond-> slave_arr is NULL Test commands: ifconfig bond1 down ifconfig bond1 up The conflict occurs in the following process： __dev_open (CPU A) --bond_open --queue_delayed_work(bond->wq,&bond->ad_work,0); --bond_update_slave_arr --bond_3ad_get_active_agg_info ad_work(CPU B) --bond_3ad_state_machine_handler --ad_agg_selection_logic ad_work runs on cpu B. In the function ad_agg_selection_logic, all agg->is_active will be cleared. Before the new active aggregator is selected on CPU B, bond_3ad_get_active_agg_info failed on CPU A, bond->slave_arr will be set to NULL. The best aggregator in ad_agg_selection_logic has not changed, no need to update slave arr. The conflict occurred in that ad_agg_selection_logic clears agg->is_active under mode_lock, but bond_open -> bond_update_slave_arr is inspecting agg->is_active outside the lock. Also, bond_update_slave_arr is normal for potential sleep when allocating memory, so replace the WARN_ON with a call to might_sleep. Signed-off-by: Njinyiting <jinyiting@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NAichun Li <liaichun@huawei.com> Signed-off-by: NAichun Li <liaichun@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- Enable CONFIG_DYNAMIC_HUGETLB for x86 by default. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- Add a Document to describe dynamic hugetlb feature, including the conflict description, usage description and interface description. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- The dynamic_hugetlb feature need to split and merge pages frequently. hugetlb_vmemmap will affects the perforemance of page split and merge. If want to use dynamic hugetlb, please disable hugetlb_vmemmap. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- When THP is enabled, the allocation of a page(order=0) may be converted to an allocation of pages(order>0). In this case, the allocation will skip the dhugetlb_pool. When we want to use dynamic hugetlb feature, we have to disable THP for now. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- Add tracepoints for dynamic_hugetlb to track the process of page split, page merge, page migration, page allocation and page free. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- Add function to free huge page to dhugetlb_pool. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- Add function to alloc huge page from dhugetlb_pool. When process is bound to a mem_cgroup configured with dhugetlb_pool, only allowed to alloc huge page from dhugetlb_pool. If there is no huge pages in dhugetlb_pool, the mmap() will failed due to the reserve count introduced in previous patch. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- The dynamic hugetlb feature is based on hugetlb. There is a reserve count in hugetlb to determine if there were enough free huge pages to satisfy the requirement while mmap() to avoid SIGBUS at the next page fault time. Add similar count for dhugetlb_pool to avoid same problem. References: Documentation/vm/hugetlbfs_reserv.rst Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- Add new interface "dhugetlb.disable_normal_pages" to disable the allocation of normal pages from a hpool. This makes dynamic hugetlb more flexible. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: feature bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4QSHG CVE: NA -------------------------------- Add function to free page to dhugetlb_pool. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-