Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 27 1月, 2022 1 次提交
  3. 26 1月, 2022 3 次提交
    • L
      etmem: Add a scan flag to support specified page swap-out · 353db299
      由 liubo 提交于 
      euleros inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4QVXW
CVE: NA

-------------------------------------------------
etmem, the memory vertical expansion technology,

The existing memory expansion tool etmem swaps out all pages that can be
swapped out for the process by default, unless the page is marked with
lock flag.

The function of swapping out specified pages is added. The process adds
VM_SWAPFLAG flags for pages to be swapped out. The etmem adds filters to
the scanning module and swaps out only these pages.
Signed-off-by: Nliubo <liubo254@huawei.com>
Reviewed-by: NMiaohe Lin <linmiaohe@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      353db299
    • L
      etmem: add swapcache reclaim to etmem · d2869c60
      由 liubo 提交于 
      euleros inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4QVXW
CVE: NA

-------------------------------------------------
etmem, the memory vertical expansion technology,

In the current etmem process, memory page swapping is implemented by
invoking shrink_page_list. When this interface is invoked for the first
time, pages are added to the swap cache and written to disks.The swap
cache page is reclaimed only when this interface is invoked for the
second time and no process accesses the page.However, in the etmem
process, the user mode scans pages that have been accessed, and the
migration is not delivered to pages that are not accessed by processes.
Therefore, the swap cache may always be occupied.
To solve the preceding problem, add the logic for actively reclaiming
the swap cache.When the swap cache occupies a large amount of memory,
the system proactively scans the LRU linked list and reclaims the
swap cache to save memory within the specified range.
Signed-off-by: Nliubo <liubo254@huawei.com>
Reviewed-by: NMiaohe Lin <linmiaohe@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      d2869c60
    • L
      etmem: add original kernel swap enabled options · 44983705
      由 liubo 提交于 
      euleros inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4QVXW
CVE: NA

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

etmem, the memory vertical expansion technology,
uses DRAM and high-performance storage new media to form multi-level
memory storage.
By grading the stored data, etmem migrates the classified cold
storage data from the storage medium to the high-performance
storage medium,
so as to achieve the purpose of memory capacity expansion and
memory cost reduction.

When the memory expansion function etmem is running, the native
swap function of the kernel needs to be disabled in certain
scenarios to avoid the impact of kernel swap.

This feature provides the preceding functions.

The /sys/kernel/mm/swap/ directory provides the kernel_swap_enable
sys interface to enable or disable the native swap function
of the kernel.

The default value of /sys/kernel/mm/swap/kernel_swap_enable is true,
that is, kernel swap is enabled by default.

Turn on kernel swap:
	echo true > /sys/kernel/mm/swap/kernel_swap_enable

Turn off kernel swap:
	echo false > /sys/kernel/mm/swap/kernel_swap_enable
Signed-off-by: Nliubo <liubo254@huawei.com>
Reviewed-by: NMiaohe Lin <linmiaohe@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      44983705
  5. 25 1月, 2022 1 次提交
  7. 20 1月, 2022 1 次提交
  9. 19 1月, 2022 2 次提交
  11. 18 1月, 2022 1 次提交
  13. 17 1月, 2022 20 次提交
  15. 13 1月, 2022 3 次提交
    • Y
      ext4: Fix BUG_ON in ext4_bread when write quota data · c113ae0d
      由 Ye Bin 提交于 
      mainline inclusion
from mainline-v5.17
commit ce85548ab4295234b4f8e63a0eea0c157d2f6b25
category: bugfix
bugzilla: 185930
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: NYang Yingliang <yangyingliang@huawei.com>
      c113ae0d
    • T
      PM: hibernate: use correct mode for swsusp_close() · 2ae13e7a
      由 Thomas Zeitlhofer 提交于 
      stable inclusion
from linux-v4.19.219
commit 68945e943519df1532e598fafab16ac54488933f

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

[ Upstream commit cefcf24b ]

Commit 39fbef4b ("PM: hibernate: Get block device exclusively in
swsusp_check()") changed the opening mode of the block device to
(FMODE_READ | FMODE_EXCL).

In the corresponding calls to swsusp_close(), the mode is still just
FMODE_READ which triggers the warning in blkdev_flush_mapping() on
resume from hibernate.

So, use the mode (FMODE_READ | FMODE_EXCL) also when closing the
device.

Fixes: 39fbef4b ("PM: hibernate: Get block device exclusively in swsusp_check()")
Signed-off-by: NThomas Zeitlhofer <thomas.zeitlhofer+lkml@ze-it.at>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      2ae13e7a
    • Y
      Revert "watchdog: Fix check_preemption_disabled() error" · c8f15bf5
      由 Yang Yingliang 提交于 
      hulk inclusion
category: bugfix
bugzilla: 173968, https://gitee.com/openeuler/kernel/issues/I3J87Y
CVE: NA

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

This reverts commit b2e484e9.

When CONFIG_LOCKDEP and CONFIG_DEBUG_LOCKDEP are enabled, it detects the following error:

[   10.145007] BUG: sleeping function called from invalid context at mm/slab.h:418
[   10.145394] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
[   10.145765] Preemption disabled at:
[   10.145978] [<ffff000008f8e7b4>] hardlockup_detector_perf_init+0x20/0x100
[   10.146770] CPU: 6 PID: 1 Comm: swapper/0 Not tainted 4.19.90+ #3
[   10.148242] Hardware name: linux,dummy-virt (DT)
[   10.148572] Call trace:
[   10.148667]  dump_backtrace+0x0/0x190
[   10.148765]  show_stack+0x24/0x30
[   10.148875]  dump_stack+0xa4/0xf8
[   10.148964]  ___might_sleep+0x150/0x180
[   10.149065]  __might_sleep+0x58/0x90
[   10.149199]  kmem_cache_alloc_trace+0x244/0x2b0
[   10.149308]  perf_event_alloc+0x74/0x680
[   10.149402]  perf_event_create_kernel_counter+0x2c/0x190
[   10.149516]  arch_probe_cpu_freq+0x84/0x1ac
[   10.149611]  hw_nmi_get_sample_period+0xb8/0x180
[   10.149713]  hardlockup_detector_event_create+0x28/0xfc
[   10.149827]  hardlockup_detector_perf_init+0x24/0x100
[   10.149943]  watchdog_nmi_probe+0x14/0x1c
[   10.150037]  lockup_detector_init+0x58/0x98
[   10.150173]  kernel_init_freeable+0x10c/0x1c4
[   10.150298]  kernel_init+0x18/0x110
[   10.150422]  ret_from_fork+0x10/0x18

In 'b2e484e9 ("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.

The preemption is always disabled, the problem that wanted be fixed is not
existed, so just revert this commit.

Fixes: b2e484e9 ("watchdog: Fix check_preemption_disabled() error")
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      c8f15bf5
  17. 06 1月, 2022 2 次提交
    • X
      arm64/mpam: fix mpam dts init arm_mpam_of_device_ids error · 7ea0c3fe
      由 Xingang Wang 提交于 
      ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I49RB2
CVE: NA

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

[    0.596145] BUG: KASAN: global-out-of-bounds in __of_match_node.part.0+0xe0/0x110
[    0.596731] Read of size 1 at addr ffff2000099a8288 by task swapper/0/1
[    0.597247]
[    0.597372] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.90+ #34
[    0.597858] Hardware name: linux,dummy-virt (DT)
[    0.598243] Call trace:
[    0.598443]  dump_backtrace+0x0/0x360
[    0.598734]  show_stack+0x24/0x30
[    0.599004]  dump_stack+0xdc/0x128
[    0.599323]  print_address_description+0x184/0x278
[    0.599771]  kasan_report+0x204/0x330
[    0.600117]  __asan_report_load1_noabort+0x30/0x40
[    0.600566]  __of_match_node.part.0+0xe0/0x110
[    0.600980]  of_match_node+0x6c/0xa8
[    0.601316]  of_match_device+0x48/0x70
[    0.601669]  platform_match+0xa4/0x260
[    0.602037]  __driver_attach+0x68/0x128
[    0.602397]  bus_for_each_dev+0x118/0x198
[    0.602773]  driver_attach+0x48/0x60
[    0.603112]  bus_add_driver+0x330/0x658
[    0.603472]  driver_register+0x148/0x398
[    0.603839]  __platform_driver_register+0xd4/0x108
[    0.604288]  arm_mpam_driver_init+0x64/0x78
[    0.604680]  do_one_initcall+0xbc/0x488
[    0.605039]  kernel_init_freeable+0x604/0x6f8
[    0.605447]  kernel_init+0x18/0x130
[    0.605775]  ret_from_fork+0x10/0x18
[    0.606130]
[    0.606274] The buggy address belongs to the variable:
[    0.606754]  arm_mpam_of_device_ids+0xc8/0x380
[    0.607168]
[    0.607314] Memory state around the buggy address:
[    0.607762]  ffff2000099a8180: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 00
[    0.608429]  ffff2000099a8200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.609095] >ffff2000099a8280: 00 fa fa fa fa fa fa fa 05 fa fa fa fa fa fa fa
[    0.609760]                       ^
[    0.610101]  ffff2000099a8300: 00 00 07 fa fa fa fa fa 00 04 fa fa fa fa fa fa
[    0.610771]  ffff2000099a8380: 00 00 00 06 fa fa fa fa 00 01 fa fa fa fa fa fa

The arm_mpam_of_device_ids array has no end item, so the array access
might be out of bounds. When enable the KASAN config, the out of bounds
call trace occured. The add empty end item for arm_mpam_of_device_ids
array to fix this issue.

Fixes: b45bdb5a ("arm64/mpam: add device tree support for mpam initialization")
Signed-off-by: NXingang Wang <wangxingang5@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      7ea0c3fe
    • X
      arm64/mpam: fix mpam probe error for wrong init order · 82e2f45f
      由 Xingang Wang 提交于 
      ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I49RB2
CVE: NA

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

The mpam init procedure failed when probe with ACPI:
[    1.148657 ] ACPI MPAM: No CPU has cache with PPTT reference 0x72
[    1.148658 ] ACPI MPAM: All CPUs must be online to probe mpam.
[    1.148660 ] ACPI MPAM: discovery failed: -19

This is because mpam need to be probed after all cpus be online, the
arm_mpam_driver_init must be called after cacheinfo_sysfs_init, so the
device_initcall should be replaced with device_initcall_sync.
Fixes: b45bdb5a ("arm64/mpam: add device tree support for mpam initialization")
Signed-off-by: NXingang Wang <wangxingang5@huawei.com>
Reviewed-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      82e2f45f
  19. 31 12月, 2021 6 次提交