Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 3月, 2022 7 次提交
  3. 25 1月, 2022 1 次提交
  5. 16 12月, 2021 1 次提交
  7. 14 12月, 2021 4 次提交
    • E
      exit: Rename complete_and_exit to kthread_complete_and_exit · cead1855
      由 Eric W. Biederman 提交于 
      Update complete_and_exit to call kthread_exit instead of do_exit.

Change the name to reflect this change in functionality.  All of the
users of complete_and_exit are causing the current kthread to exit so
this change makes it clear what is happening.

Move the implementation of kthread_complete_and_exit from
kernel/exit.c to to kernel/kthread.c.  As this function is kthread
specific it makes most sense to live with the kthread functions.

There are no functional change.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      cead1855
    • E
      exit: Rename module_put_and_exit to module_put_and_kthread_exit · ca3574bd
      由 Eric W. Biederman 提交于 
      Update module_put_and_exit to call kthread_exit instead of do_exit.

Change the name to reflect this change in functionality.  All of the
users of module_put_and_exit are causing the current kthread to exit
so this change makes it clear what is happening.  There is no
functional change.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      ca3574bd
    • E
      exit: Implement kthread_exit · bbda86e9
      由 Eric W. Biederman 提交于 
      The way the per task_struct exit_code is used by kernel threads is not
quite compatible how it is used by userspace applications.  The low
byte of the userspace exit_code value encodes the exit signal.  While
kthreads just use the value as an int holding ordinary kernel function
exit status like -EPERM.

Add kthread_exit to clearly separate the two kinds of uses.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      bbda86e9
    • E
      exit: Add and use make_task_dead. · 0e25498f
      由 Eric W. Biederman 提交于 
      There are two big uses of do_exit.  The first is it's design use to be
the guts of the exit(2) system call.  The second use is to terminate
a task after something catastrophic has happened like a NULL pointer
in kernel code.

Add a function make_task_dead that is initialy exactly the same as
do_exit to cover the cases where do_exit is called to handle
catastrophic failure.  In time this can probably be reduced to just a
light wrapper around do_task_dead. For now keep it exactly the same so
that there will be no behavioral differences introducing this new
concept.

Replace all of the uses of do_exit that use it for catastraphic
task cleanup with make_task_dead to make it clear what the code
is doing.

As part of this rename rewind_stack_do_exit
rewind_stack_and_make_dead.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      0e25498f
  9. 11 12月, 2021 1 次提交
  11. 10 12月, 2021 2 次提交
  13. 09 12月, 2021 1 次提交
  15. 03 12月, 2021 1 次提交
  17. 11 11月, 2021 1 次提交
  19. 29 10月, 2021 4 次提交
  21. 07 10月, 2021 2 次提交
  23. 06 10月, 2021 3 次提交
  25. 04 10月, 2021 1 次提交
    • L
      objtool: print out the symbol type when complaining about it · 7fab1c12
      由 Linus Torvalds 提交于 
      The objtool warning that the kvm instruction emulation code triggered
wasn't very useful:

    arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception

in that it helpfully tells you which symbol name it had trouble figuring
out the relocation for, but it doesn't actually say what the unknown
symbol type was that triggered it all.

In this case it was because of missing type information (type 0, aka
STT_NOTYPE), but on the whole it really should just have printed that
out as part of the message.

Because if this warning triggers, that's very much the first thing you
want to know - why did reloc2sec_off() return failure for that symbol?

So rather than just saying you can't handle some type of symbol without
saying what the type _was_, just print out the type number too.

Fixes: 24ff6525 ("objtool: Teach get_alt_entry() about more relocation types")
Link: https://lore.kernel.org/lkml/CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@mail.gmail.com/Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7fab1c12
  27. 01 10月, 2021 2 次提交
  29. 17 9月, 2021 1 次提交
    • P
      objtool: Support pv_opsindirect calls for noinstr · db2b0c5d
      由 Peter Zijlstra 提交于 
      Normally objtool will now follow indirect calls; there is no need.

However, this becomes a problem with noinstr validation; if there's an
indirect call from noinstr code, we very much need to know it is to
another noinstr function. Luckily there aren't many indirect calls in
entry code with the obvious exception of paravirt. As such, noinstr
validation didn't work with paravirt kernels.

In order to track pv_ops[] call targets, objtool reads the static
pv_ops[] tables as well as direct assignments to the pv_ops[] array,
provided the compiler makes them a single instruction like:

  bf87:       48 c7 05 00 00 00 00 00 00 00 00        movq   $0x0,0x0(%rip)
    bf92 <xen_init_spinlocks+0x5f>
    bf8a: R_X86_64_PC32     pv_ops+0x268

There are, as of yet, no warnings for when this goes wrong :/

Using the functions found with the above means, all pv_ops[] calls are
now subject to noinstr validation.
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210624095149.118815755@infradead.org
      db2b0c5d
  31. 15 9月, 2021 3 次提交
  33. 24 6月, 2021 1 次提交
  35. 14 6月, 2021 1 次提交
  37. 11 6月, 2021 1 次提交
  39. 10 6月, 2021 1 次提交
  41. 14 5月, 2021 1 次提交