Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 1月, 2013 4 次提交
  3. 20 1月, 2013 1 次提交
  5. 17 1月, 2013 1 次提交
    • T
      module, async: async_synchronize_full() on module init iff async is used · 774a1221
      由 Tejun Heo 提交于 
      If the default iosched is built as module, the kernel may deadlock
while trying to load the iosched module on device probe if the probing
was running off async.  This is because async_synchronize_full() at
the end of module init ends up waiting for the async job which
initiated the module loading.

 async A				modprobe

 1. finds a device
 2. registers the block device
 3. request_module(default iosched)
					4. modprobe in userland
					5. load and init module
					6. async_synchronize_full()

Async A waits for modprobe to finish in request_module() and modprobe
waits for async A to finish in async_synchronize_full().

Because there's no easy to track dependency once control goes out to
userland, implementing properly nested flushing is difficult.  For
now, make module init perform async_synchronize_full() iff module init
has queued async jobs as suggested by Linus.

This avoids the described deadlock because iosched module doesn't use
async and thus wouldn't invoke async_synchronize_full().  This is
hacky and incomplete.  It will deadlock if async module loading nests;
however, this works around the known problem case and seems to be the
best of bad options.

For more details, please refer to the following thread.

  http://thread.gmane.org/gmane.linux.kernel/1420814Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NAlex Riesen <raa.lkml@gmail.com>
Tested-by: NMing Lei <ming.lei@canonical.com>
Tested-by: NAlex Riesen <raa.lkml@gmail.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      774a1221
  7. 15 1月, 2013 1 次提交
  9. 12 1月, 2013 7 次提交
    • R
      module: put modules in list much earlier. · 1fb9341a
      由 Rusty Russell 提交于 
      Prarit's excellent bug report:
> In recent Fedora releases (F17 & F18) some users have reported seeing
> messages similar to
>
> [   15.478160] kvm: Could not allocate 304 bytes percpu data
> [   15.478174] PERCPU: allocation failed, size=304 align=32, alloc from
> reserved chunk failed
>
> during system boot.  In some cases, users have also reported seeing this
> message along with a failed load of other modules.
>
> What is happening is systemd is loading an instance of the kvm module for
> each cpu found (see commit e9bda3b3).  When the module load occurs the kernel
> currently allocates the modules percpu data area prior to checking to see
> if the module is already loaded or is in the process of being loaded.  If
> the module is already loaded, or finishes load, the module loading code
> releases the current instance's module's percpu data.

Now we have a new state MODULE_STATE_UNFORMED, we can insert the
module into the list (and thus guarantee its uniqueness) before we
allocate the per-cpu region.
Reported-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Tested-by: NPrarit Bhargava <prarit@redhat.com>
      1fb9341a
    • R
      module: add new state MODULE_STATE_UNFORMED. · 0d21b0e3
      由 Rusty Russell 提交于 
      You should never look at such a module, so it's excised from all paths
which traverse the modules list.

We add the state at the end, to avoid gratuitous ABI break (ksplice).
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      0d21b0e3
    • A
      kernel/audit.c: avoid negative sleep durations · 82919919
      由 Andrew Morton 提交于 
      audit_log_start() performs the same jiffies comparison in two places.
If sufficient time has elapsed between the two comparisons, the second
one produces a negative sleep duration:

  schedule_timeout: wrong timeout value fffffffffffffff0
  Pid: 6606, comm: trinity-child1 Not tainted 3.8.0-rc1+ #43
  Call Trace:
    schedule_timeout+0x305/0x340
    audit_log_start+0x311/0x470
    audit_log_exit+0x4b/0xfb0
    __audit_syscall_exit+0x25f/0x2c0
    sysret_audit+0x17/0x21

Fix it by performing the comparison a single time.
Reported-by: NDave Jones <davej@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      82919919
    • K
      audit: catch possible NULL audit buffers · 0644ec0c
      由 Kees Cook 提交于 
      It's possible for audit_log_start() to return NULL.  Handle it in the
various callers.
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Julien Tinnes <jln@google.com>
Cc: Will Drewry <wad@google.com>
Cc: Steve Grubb <sgrubb@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0644ec0c
    • K
      audit: create explicit AUDIT_SECCOMP event type · 7b9205bd
      由 Kees Cook 提交于 
      The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
could only kill a process.  While we still want to make sure an audit
record is forced on a kill, this should use a separate record type since
seccomp mode 2 introduces other behaviors.

In the case of "handled" behaviors (process wasn't killed), only emit a
record if the process is under inspection.  This change also fixes
userspace examination of seccomp audit events, since it was considered
malformed due to missing fields of the AUDIT_ANOM_ABEND event type.
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Julien Tinnes <jln@google.com>
Acked-by: NWill Drewry <wad@chromium.org>
Acked-by: NSteve Grubb <sgrubb@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b9205bd
    • J
      lockdep, rwsem: provide down_write_nest_lock() · 1b963c81
      由 Jiri Kosina 提交于 
      down_write_nest_lock() provides a means to annotate locking scenario
where an outer lock is guaranteed to serialize the order nested locks
are being acquired.

This is analogoue to already existing mutex_lock_nest_lock() and
spin_lock_nest_lock().
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Cc: Rik van Riel <riel@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mel Gorman <mel@csn.ul.ie>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1b963c81
    • S
      tracing: Fix regression with irqsoff tracer and tracing_on file · 2df8f8a6
      由 Steven Rostedt 提交于 
      Commit 02404baf "tracing: Remove deprecated tracing_enabled file"
removed the tracing_enabled file as it never worked properly and
the tracing_on file should be used instead. But the tracing_on file
didn't call into the tracers start/stop routines like the
tracing_enabled file did. This caused trace-cmd to break when it
enabled the irqsoff tracer.

If you just did "echo irqsoff > current_tracer" then it would work
properly. But the tool trace-cmd disables tracing first by writing
"0" into the tracing_on file. Then it writes "irqsoff" into
current_tracer and then writes "1" into tracing_on. Unfortunately,
the above commit changed the irqsoff tracer to check the tracing_on
status instead of the tracing_enabled status. If it's disabled then
it does not start the tracer internals.

The problem is that writing "1" into tracing_on does not call the
tracers "start" routine like writing "1" into tracing_enabled did.
This makes the irqsoff tracer not start when using the trace-cmd
tool, and is a regression for userspace.

Simple fix is to have the tracing_on file call the tracers start()
method when being enabled (and the stop() method when disabled).
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      2df8f8a6
  11. 11 1月, 2013 1 次提交
  13. 10 1月, 2013 1 次提交
    • S
      tracing: Fix regression of trace_options file setting · a8dd2176
      由 Steven Rostedt 提交于 
      The latest change to allow trace options to be set on the command
line also broke the trace_options file.

The zeroing of the last byte of the option name that is echoed into
the trace_option file was removed with the consolidation of some
of the code. The compare between the option and what was written to
the trace_options file fails because the string holding the data
written doesn't terminate with a null character.

A zero needs to be added to the end of the string copied from
user space.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      a8dd2176
  15. 06 1月, 2013 2 次提交
  17. 05 1月, 2013 1 次提交
    • R
      printk: fix incorrect length from print_time() when seconds > 99999 · 35dac27c
      由 Roland Dreier 提交于 
      print_prefix() passes a NULL buf to print_time() to get the length of
the time prefix; when printk times are enabled, the current code just
returns the constant 15, which matches the format "[%5lu.%06lu] " used
to print the time value.  However, this is obviously incorrect when the
whole seconds part of the time gets beyond 5 digits (100000 seconds is a
bit more than a day of uptime).

The simple fix is to use snprintf(NULL, 0, ...) to calculate the actual
length of the time prefix.  This could be micro-optimized but it seems
better to have simpler, more readable code here.

The bug leads to the syslog system call miscomputing which messages fit
into the userspace buffer.  If there are enough messages to fill
log_buf_len and some have a timestamp >= 100000, dmesg may fail with:

    # dmesg
    klogctl: Bad address

When this happens, strace shows that the failure is indeed EFAULT due to
the kernel mistakenly accessing past the end of dmesg's buffer, since
dmesg asks the kernel how big a buffer it needs, allocates a bit more,
and then gets an error when it asks the kernel to fill it:

    syslog(0xa, 0, 0)                       = 1048576
    mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4d25d2000
    syslog(0x3, 0x7fa4d25d2010, 0x100008)   = -1 EFAULT (Bad address)

As far as I can see, the bug has been there as long as print_time(),
which comes from commit 084681d1 ("printk: flush continuation lines
immediately to console") in 3.5-rc5.
Signed-off-by: NRoland Dreier <roland@purestorage.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joe Perches <joe@perches.com>
Cc: Sylvain Munaut <s.munaut@whatever-company.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      35dac27c
  19. 03 1月, 2013 1 次提交
  21. 26 12月, 2012 5 次提交
    • A
      x32: fix sigtimedwait · b2ddedcd
      由 Al Viro 提交于 
      It needs 64bit timespec.  As it is, we end up truncating the timeout
to whole seconds; usually it doesn't matter, but for having all
sub-second timeouts truncated to one jiffy is visibly wrong.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      b2ddedcd
    • A
      x32: fix waitid() · a566c288
      由 Al Viro 提交于 
      It needs 64bit rusage and 32bit siginfo.  glibc never calls it with
non-NULL rusage pointer, or we would've seen breakage already...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      a566c288
    • A
      switch compat_sys_wait4() and compat_sys_waitid() to COMPAT_SYSCALL_DEFINE · 8d9807b1
      由 Al Viro 提交于 
      Strictly speaking, ppc64 needs it for C ABI compliance.  Realistically
I would be very surprised if e.g. passing 0xffffffff as 'options'
argument to waitid() from 32bit task would cause problems, but yes,
it puts us into undefined behaviour territory.  ppc64 expects int
argument to be passed in 64bit register with bits 31..63 containing
the same value.  SYSCALL_DEFINE on ppc provides a wrapper that normalizes
the value passed from userland; so does COMPAT_SYSCALL_DEFINE.  Plain
declaration of compat_sys_something() with an int argument obviously
doesn't.  Again, for wait4 and waitid I would be extremely surprised
if gcc started to produce code depending on that value having been
properly sign-extended - the argument(s) in question end up passed
blindly to sys_wait4 and sys_waitid resp. and normalization for native
syscalls takes care of their use there.  Still, better to use
COMPAT_SYSCALL_DEFINE here than worry about nasal daemons...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8d9807b1
    • A
      switch compat_sys_sigaltstack() to COMPAT_SYSCALL_DEFINE · 90228fc1
      由 Al Viro 提交于 
      Makes sigaltstack conversion easier to split into per-architecture
parts.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      90228fc1
    • E
      pidns: Stop pid allocation when init dies · c876ad76
      由 Eric W. Biederman 提交于 
      Oleg pointed out that in a pid namespace the sequence.
- pid 1 becomes a zombie
- setns(thepidns), fork,...
- reaping pid 1.
- The injected processes exiting.

Can lead to processes attempting access their child reaper and
instead following a stale pointer.

That waitpid for init can return before all of the processes in
the pid namespace have exited is also unfortunate.

Avoid these problems by disabling the allocation of new pids in a pid
namespace when init dies, instead of when the last process in a pid
namespace is reaped.
Pointed-out-by: NOleg Nesterov <oleg@redhat.com>
Reviewed-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      c876ad76
  23. 25 12月, 2012 1 次提交
  25. 21 12月, 2012 2 次提交
  27. 20 12月, 2012 7 次提交
  29. 19 12月, 2012 3 次提交
  31. 18 12月, 2012 2 次提交