Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 08 6月, 2018 12 次提交
  3. 27 5月, 2018 3 次提交
  5. 23 5月, 2018 2 次提交
    • A
      proc_lookupfd_common(): don't bother with instantiate unless the file is open · 1ae9bd8b
      由 Al Viro 提交于 
      ... and take the "check if file is open, pick ->f_mode" into a helper;
tid_fd_revalidate() can use it.

The next patch will get rid of tid_fd_revalidate() calls in instantiate
callbacks.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1ae9bd8b
    • A
      procfs: get rid of ancient BS in pid_revalidate() uses · 1bbc5513
      由 Al Viro 提交于 
      First of all, calling pid_revalidate() in the end of <pid>/* lookups
is *not* about closing any kind of races; that used to be true once
upon a time, but these days those comments are actively misleading.
Especially since pid_revalidate() doesn't even do d_drop() on
failure anymore.  It doesn't matter, anyway, since once
pid_revalidate() starts returning false, ->d_delete() of those
dentries starts saying "don't keep"; they won't get stuck in
dcache any longer than they are pinned.

These calls cannot be just removed, though - the side effect of
pid_revalidate() (updating i_uid/i_gid/etc.) is what we are calling
it for here.

Let's separate the "update ownership" into a new helper (pid_update_inode())
and use it, both in lookups and in pid_revalidate() itself.

The comments in pid_revalidate() are also out of date - they refer to
the time when pid_revalidate() used to call d_drop() directly...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1bbc5513
  7. 22 5月, 2018 1 次提交
  9. 18 5月, 2018 5 次提交
    • T
      workqueue: Show the latest workqueue name in /proc/PID/{comm,stat,status} · 6b59808b
      由 Tejun Heo 提交于 
      There can be a lot of workqueue workers and they all show up with the
cryptic kworker/* names making it difficult to understand which is
doing what and how they came to be.

  # ps -ef | grep kworker
  root           4       2  0 Feb25 ?        00:00:00 [kworker/0:0H]
  root           6       2  0 Feb25 ?        00:00:00 [kworker/u112:0]
  root          19       2  0 Feb25 ?        00:00:00 [kworker/1:0H]
  root          25       2  0 Feb25 ?        00:00:00 [kworker/2:0H]
  root          31       2  0 Feb25 ?        00:00:00 [kworker/3:0H]
  ...

This patch makes workqueue workers report the latest workqueue it was
executing for through /proc/PID/{comm,stat,status}.  The extra
information is appended to the kthread name with intervening '+' if
currently executing, otherwise '-'.

  # cat /proc/25/comm
  kworker/2:0-events_power_efficient
  # cat /proc/25/stat
  25 (kworker/2:0-events_power_efficient) I 2 0 0 0 -1 69238880 0 0...
  # grep Name /proc/25/status
  Name:   kworker/2:0-events_power_efficient

Unfortunately, ps(1) truncates comm to 15 characters,

  # ps 25
    PID TTY      STAT   TIME COMMAND
     25 ?        I      0:00 [kworker/2:0-eve]

making it a lot less useful; however, this should be an easy fix from
ps(1) side.
Signed-off-by: NTejun Heo <tj@kernel.org>
Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Craig Small <csmall@enc.com.au>
      6b59808b
    • T
      proc: Consolidate task->comm formatting into proc_task_name() · 88b72b31
      由 Tejun Heo 提交于 
      proc shows task->comm in three places - comm, stat, status - and each
is fetching and formatting task->comm slighly differently.  This patch
renames task_name() to proc_task_name(), makes it more generic, and
updates all three paths to use it.

This will enable expanding comm reporting for workqueue workers.
Signed-off-by: NTejun Heo <tj@kernel.org>
      88b72b31
    • L
      fs/proc: simplify and clarify get_mm_cmdline() function · 5ab82718
      由 Linus Torvalds 提交于 
      We have some very odd semantics for reading the command line through
/proc, because we allow people to rewrite their own command line pretty
much at will, and things get positively funky when you extend your
command line past the point that used to be the end of the command line,
and is now in the environment variable area.

But our weird semantics doesn't mean that we should write weird and
complex code to handle them.

So re-write get_mm_cmdline() to be much simpler, and much more explicit
about what it is actually doing and why.  And avoid the extra check for
"is there a NUL character at the end of the command line where I expect
one to be", by simply making the NUL character handling be part of the
normal "once you hit the end of the command line, stop at the first NUL
character" logic.

It's quite possible that we should stop the crazy "walk into
environment" entirely, but happily it's not really the usual case.

NOTE! We tried to really simplify and limit our odd cmdline parsing some
time ago, but people complained.  See commit c2c0bb44 ("proc: fix
PAGE_SIZE limit of /proc/$PID/cmdline") for details about why we have
this complexity.

Cc: Tejun Heo <tj@kernel.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ab82718
    • L
      fs/proc: re-factor proc_pid_cmdline_read() a bit · e4b4e441
      由 Linus Torvalds 提交于 
      This is a pure refactoring of the function, preparing for some further
cleanups.  The thing was pretty illegible, and the core functionality
still is, but now the core loop is a bit more isolated from the thing
that goes on around it.

This was "inspired" by the confluence of kworker workqueue name cleanups
by Tejun, currently scheduled for 4.18, and commit 7f7ccc2c ("proc:
do not access cmdline nor environ from file-backed areas").
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4b4e441
    • W
      proc: do not access cmdline nor environ from file-backed areas · 7f7ccc2c
      由 Willy Tarreau 提交于 
      proc_pid_cmdline_read() and environ_read() directly access the target
process' VM to retrieve the command line and environment. If this
process remaps these areas onto a file via mmap(), the requesting
process may experience various issues such as extra delays if the
underlying device is slow to respond.

Let's simply refuse to access file-backed areas in these functions.
For this we add a new FOLL_ANON gup flag that is passed to all calls
to access_remote_vm(). The code already takes care of such failures
(including unmapped areas). Accesses via /proc/pid/mem were not
changed though.

This was assigned CVE-2018-1120.

Note for stable backports: the patch may apply to kernels prior to 4.11
but silently miss one location; it must be checked that no call to
access_remote_vm() keeps zero as the last argument.
Reported-by: NQualys Security Advisory <qsa@qualys.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NWilly Tarreau <w@1wt.eu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7f7ccc2c
  11. 16 5月, 2018 11 次提交
  13. 15 5月, 2018 2 次提交
    • R
      vmcore: append device dumps to vmcore as elf notes · 7efe48df
      由 Rahul Lakkireddy 提交于 
      Update read and mmap logic to append device dumps as additional notes
before the other elf notes. We add device dumps before other elf notes
because the other elf notes may not fill the elf notes buffer
completely and we will end up with zero-filled data between the elf
notes and the device dumps. Tools will then try to decode this
zero-filled data as valid notes and we don't want that. Hence, adding
device dumps before the other elf notes ensure that zero-filled data
can be avoided. This also ensures that the device dumps and the
other elf notes can be properly mmaped at page aligned address.

Incorporate device dump size into the total vmcore size. Also update
offsets for other program headers after the device dumps are added.

Suggested-by: Eric Biederman <ebiederm@xmission.com>.
Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7efe48df
    • R
      vmcore: add API to collect hardware dump in second kernel · 2724273e
      由 Rahul Lakkireddy 提交于 
      The sequence of actions done by device drivers to append their device
specific hardware/firmware logs to /proc/vmcore are as follows:

1. During probe (before hardware is initialized), device drivers
register to the vmcore module (via vmcore_add_device_dump()), with
callback function, along with buffer size and log name needed for
firmware/hardware log collection.

2. vmcore module allocates the buffer with requested size. It adds
an Elf note and invokes the device driver's registered callback
function.

3. Device driver collects all hardware/firmware logs into the buffer
and returns control back to vmcore module.

Ensure that the device dump buffer size is always aligned to page size
so that it can be mmaped.

Also, rename alloc_elfnotes_buf() to vmcore_alloc_buf() to make it more
generic and reserve NT_VMCOREDD note type to indicate vmcore device
dump.

Suggested-by: Eric Biederman <ebiederm@xmission.com>.
Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2724273e
  15. 12 5月, 2018 1 次提交
  17. 10 5月, 2018 1 次提交
  19. 09 5月, 2018 2 次提交