Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 6月, 2023 1 次提交
  3. 27 6月, 2023 3 次提交
  5. 26 6月, 2023 5 次提交
  7. 25 6月, 2023 2 次提交
  9. 21 6月, 2023 5 次提交
  11. 20 6月, 2023 5 次提交
  13. 19 6月, 2023 3 次提交
    • K
      mm: oom: move memcg_print_bad_task() out of mem_cgroup_scan_tasks() · 2dcb2c2a
      由 Kang Chen 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NYW4
CVE: NA

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

raw call flow:

oom_kill_process
  -> mem_cgroup_scan_tasks(.., .., message)
    -> memcg_print_bad_task(message, ..)

message is "const char*" type, and incorrectly cast to
"oom_control*" type in memcg_print_bad_task.

Fix it by moving memcg_print_bad_task out of mem_cgroup_scan_tasks
and call it in select_bad_process and dump_tasks. Furthermore,
use struct oom_control* directly and remove the useless parm `ret`.
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NKang Chen <void0red@hust.edu.cn>
Conflicts:
	include/linux/memcontrol.h
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
      2dcb2c2a
    • S
      fbcon: Check font dimension limits · 2a585b33
      由 Samuel Thibault 提交于 
      mainline inclusion
from mainline-v6.2-rc7
commit 2b09d5d3
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7C2TM
CVE: CVE-2023-3161

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

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

blit_x and blit_y are u32, so fbcon currently cannot support fonts
larger than 32x32.

The 32x32 case also needs shifting an unsigned int, to properly set bit
31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
as reported on:

http://lore.kernel.org/all/IA1PR07MB98308653E259A6F2CE94A4AFABCE9@IA1PR07MB9830.namprd07.prod.outlook.com
Kernel Branch: 6.2.0-rc5-next-20230124
Kernel config: https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
Reproducer: https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharingReported-by: NSanan Hasanov <sanan.hasanov@Knights.ucf.edu>
Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
Fixes: 2d2699d9 ("fbcon: font setting should check limitation of driver")
Cc: stable@vger.kernel.org
Tested-by: NMiko Larsson <mikoxyzzz@gmail.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>
(cherry picked from commit aa4e4b8d)
      2a585b33
    • S
      proc: allow pid_revalidate() during LOOKUP_RCU · bc65c71a
      由 Stephen Brennan 提交于 
      mainline inclusion
from mainline-v5.16-rc1
commit da4d6b9c
category: bugfix
bugzilla: 188892, https://gitee.com/openeuler/kernel/issues/I7CWJ7
CVE: NA

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

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

Problem Description:

When running running ~128 parallel instances of

  TZ=/etc/localtime ps -fe >/dev/null

on a 128CPU machine, the %sys utilization reaches 97%, and perf shows
the following code path as being responsible for heavy contention on the
d_lockref spinlock:

      walk_component()
        lookup_fast()
          d_revalidate()
            pid_revalidate() // returns -ECHILD
          unlazy_child()
            lockref_get_not_dead(&nd->path.dentry->d_lockref) <-- contention

The reason is that pid_revalidate() is triggering a drop from RCU to ref
path walk mode.  All concurrent path lookups thus try to grab a
reference to the dentry for /proc/, before re-executing pid_revalidate()
and then stepping into the /proc/$pid directory.  Thus there is huge
spinlock contention.

This patch allows pid_revalidate() to execute in RCU mode, meaning that
the path lookup can successfully enter the /proc/$pid directory while
still in RCU mode.  Later on, the path lookup may still drop into ref
mode, but the contention will be much reduced at this point.

By applying this patch, %sys utilization falls to around 85% under the
same workload, and the number of ps processes executed per unit time
increases by 3x-4x.  Although this particular workload is a bit
contrived, we have seen some large collections of eager monitoring
scripts which produced similarly high %sys time due to contention in the
/proc directory.

As a result this patch, Al noted that several procfs methods which were
only called in ref-walk mode could now be called from RCU mode.  To
ensure that this patch is safe, I audited all the inode get_link and
permission() implementations, as well as dentry d_revalidate()
implementations, in fs/proc.  The purpose here is to ensure that they
either are safe to call in RCU (i.e.  don't sleep) or correctly bail out
of RCU mode if they don't support it.  My analysis shows that all
at-risk procfs methods are safe to call under RCU, and thus this patch
is safe.

Procfs RCU-walk Analysis:

This analysis is up-to-date with 5.15-rc3.  When called under RCU mode,
these functions have arguments as follows:

* get_link() receives a NULL dentry pointer when called in RCU mode.
* permission() receives MAY_NOT_BLOCK in the mode parameter when called
  from RCU.
* d_revalidate() receives LOOKUP_RCU in flags.

For the following functions, either they are trivially RCU safe, or they
explicitly bail at the beginning of the function when they run:

proc_ns_get_link       (bails out)
proc_get_link          (RCU safe)
proc_pid_get_link      (bails out)
map_files_d_revalidate (bails out)
map_misc_d_revalidate  (bails out)
proc_net_d_revalidate  (RCU safe)
proc_sys_revalidate    (bails out, also not under /proc/$pid)
tid_fd_revalidate      (bails out)
proc_sys_permission    (not under /proc/$pid)

The remainder of the functions require a bit more detail:

* proc_fd_permission: RCU safe. All of the body of this function is
  under rcu_read_lock(), except generic_permission() which declares
  itself RCU safe in its documentation string.
* proc_self_get_link uses GFP_ATOMIC in the RCU case, so it is RCU aware
  and otherwise looks safe. The same is true of proc_thread_self_get_link.
* proc_map_files_get_link: calls ns_capable, which calls capable(), and
  thus calls into the audit code (see note #1 below). The remainder is
  just a call to the trivially safe proc_pid_get_link().
* proc_pid_permission: calls ptrace_may_access(), which appears RCU
  safe, although it does call into the "security_ptrace_access_check()"
  hook, which looks safe under smack and selinux. Just the audit code is
  of concern. Also uses get_task_struct() and put_task_struct(), see
  note #2 below.
* proc_tid_comm_permission: Appears safe, though calls put_task_struct
  (see note #2 below).

Note #1:
  Most of the concern of RCU safety has centered around the audit code.
  However, since b17ec22f ("selinux: slow_avc_audit has become
  non-blocking"), it's safe to call this code under RCU. So all of the
  above are safe by my estimation.

Note #2: get_task_struct() and put_task_struct():
  The majority of get_task_struct() is under RCU read lock, and in any
  case it is a simple increment. But put_task_struct() is complex, given
  that it could at some point free the task struct, and this process has
  many steps which I couldn't manually verify. However, several other
  places call put_task_struct() under RCU, so it appears safe to use
  here too (see kernel/hung_task.c:165 or rcu/tree-stall.h:296)

Patch description:

pid_revalidate() drops from RCU into REF lookup mode.  When many threads
are resolving paths within /proc in parallel, this can result in heavy
spinlock contention on d_lockref as each thread tries to grab a
reference to the /proc dentry (and drop it shortly thereafter).

Investigation indicates that it is not necessary to drop RCU in
pid_revalidate(), as no RCU data is modified and the function never
sleeps.  So, remove the LOOKUP_RCU check.

Link: https://lkml.kernel.org/r/20211004175629.292270-2-stephen.s.brennan@oracle.comSigned-off-by: NStephen Brennan <stephen.s.brennan@oracle.com>
Cc: Konrad Wilk <konrad.wilk@oracle.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NLi Nan <linan122@huawei.com>
(cherry picked from commit f2924f34)
      bc65c71a
  15. 16 6月, 2023 2 次提交
  17. 14 6月, 2023 3 次提交
    • O
      !1024 [sync] PR-947: locking/rwsem: Prevent potential lock starvation · d2565173
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/947 
 
PR sync from:  Yang Yingliang <yangyingliang@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/YNL7N26QMD5Q6UDTPNELYGIOXBXP4EWZ/ 
Prevent potential lock starvation by read lock.

Peter Zijlstra (1):
  locking/rwsem: Better collate rwsem_read_trylock()

Waiman Long (2):
  locking/rwsem: Pass the current atomic count to
    rwsem_down_read_slowpath()
  locking/rwsem: Prevent potential lock starvation


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1024 

Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      d2565173
    • O
      !1073 [sync] PR-1042: xfrm: Reinject transport-mode packets through workqueue · 87e3e378
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1042 
 
PR sync from:  Liu Jian <liujian56@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/XZRFZY2DDUQG3YGA4NRUPJDCHSZ77ENA/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1073 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      87e3e378
    • W
      drm/qxl: Fix missing free_irq · f05e3679
      由 Wei Li 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q4S3

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

When doing "cat /proc/interrupts" after qxl.ko is unloaded, an oops occurs:

BUG: unable to handle page fault for address: ffffffffc0274769
PGD 2a0d067 P4D 2a0d067 PUD 2a0f067 PMD 103f39067 PTE 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 6 PID: 246 Comm: cat Not tainted 6.1.0-rc2 #24
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:string_nocheck+0x34/0x50
Code: 66 85 c0 74 3c 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7
RSP: 0018:ffffc90000893bb8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffffc90000893c50 RCX: ffff0a00ffffff04
RDX: ffffffffc0274769 RSI: ffff888102812000 RDI: ffff88810281133e
RBP: ffff888102812000 R08: ffffffff823fa5e6 R09: 0000000000000007
R10: ffff888102812000 R11: ffff88820281133d R12: ffffffffc0274769
R13: ffff0a00ffffff04 R14: 0000000000000cc4 R15: ffffffff823276b4
FS:  000000000214f8c0(0000) GS:ffff88842fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc0274769 CR3: 00000001025c4005 CR4: 0000000000770ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 <TASK>
 string+0x46/0x60
 vsnprintf+0x27a/0x4f0
 seq_vprintf+0x34/0x50
 seq_printf+0x53/0x70
 ? seq_read_iter+0x365/0x450
 show_interrupts+0x259/0x330
 seq_read_iter+0x2a3/0x450
 proc_reg_read_iter+0x47/0x70
 generic_file_splice_read+0x94/0x160
 splice_direct_to_actor+0xb0/0x230
 ? do_splice_direct+0xd0/0xd0
 do_splice_direct+0x8b/0xd0
 do_sendfile+0x345/0x4f0
 __x64_sys_sendfile64+0xa1/0xc0
 do_syscall_64+0x38/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x4bb0ce
Code: c3 0f 1f 00 4c 89 d2 4c 89 c6 e9 bd fd ff ff 0f 1f 44 00 00 31 c0 c3 0f 1f 44 00 00
RSP: 002b:00007ffd99dc3fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 0000000001000000 RCX: 00000000004bb0ce
RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001
RBP: 0000000000000001 R08: 000000000068f240 R09: 0000000001000000
R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
 </TASK>

It seems that qxl doesn't free the interrupt it requests during unload,
fix this by adding the missing free_irq().

Fixes: f64122c1 ("drm: add new QXL driver. (v1.4)")
Signed-off-by: NWei Li <liwei391@huawei.com>
(cherry picked from commit ed64582f)
      f05e3679
  19. 13 6月, 2023 8 次提交
  21. 09 6月, 2023 3 次提交