1. 02 Jul, 2013 14 commits
  2. 20 Jun, 2013 4 commits
  3. 11 Jun, 2013 6 commits
  4. 08 Jun, 2013 3 commits
  5. 06 Jun, 2013 1 commit
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Use current_uid() for critical time tracing · f17a5194
      Steven Rostedt (Red Hat) authored
      
      
      The irqsoff tracer records the max time that interrupts are disabled.
      There are hooks in the assembly code that calls back into the tracer when
      interrupts are disabled or enabled.
      
      When they are enabled, the tracer checks if the amount of time they
      were disabled is larger than the previous recorded max interrupts off
      time. If it is, it creates a snapshot of the currently running trace
      to store where the last largest interrupts off time was held and how
      it happened.
      
      During testing, this RCU lockdep dump appeared:
      
      [ 1257.829021] ===============================
      [ 1257.829021] [ INFO: suspicious RCU usage. ]
      [ 1257.829021] 3.10.0-rc1-test+ #171 Tainted: G        W
      [ 1257.829021] -------------------------------
      [ 1257.829021] /home/rostedt/work/git/linux-trace.git/include/linux/rcupdate.h:780 rcu_read_lock() used illegally while idle!
      [ 1257.829021]
      [ 1257.829021] other info that might help us debug this:
      [ 1257.829021]
      [ 1257.829021]
      [ 1257.829021] RCU used illegally from idle CPU!
      [ 1257.829021] rcu_scheduler_active = 1, debug_locks = 0
      [ 1257.829021] RCU used illegally from extended quiescent state!
      [ 1257.829021] 2 locks held by trace-cmd/4831:
      [ 1257.829021]  #0:  (max_trace_lock){......}, at: [<ffffffff810e2b77>] stop_critical_timing+0x1a3/0x209
      [ 1257.829021]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff810dae5a>] __update_max_tr+0x88/0x1ee
      [ 1257.829021]
      [ 1257.829021] stack backtrace:
      [ 1257.829021] CPU: 3 PID: 4831 Comm: trace-cmd Tainted: G        W    3.10.0-rc1-test+ #171
      [ 1257.829021] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
      [ 1257.829021]  0000000000000001 ffff880065f49da8 ffffffff8153dd2b ffff880065f49dd8
      [ 1257.829021]  ffffffff81092a00 ffff88006bd78680 ffff88007add7500 0000000000000003
      [ 1257.829021]  ffff88006bd78680 ffff880065f49e18 ffffffff810daebf ffffffff810dae5a
      [ 1257.829021] Call Trace:
      [ 1257.829021]  [<ffffffff8153dd2b>] dump_stack+0x19/0x1b
      [ 1257.829021]  [<ffffffff81092a00>] lockdep_rcu_suspicious+0x109/0x112
      [ 1257.829021]  [<ffffffff810daebf>] __update_max_tr+0xed/0x1ee
      [ 1257.829021]  [<ffffffff810dae5a>] ? __update_max_tr+0x88/0x1ee
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810dbf85>] update_max_tr_single+0x11d/0x12d
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810e2b15>] stop_critical_timing+0x141/0x209
      [ 1257.829021]  [<ffffffff8109569a>] ? trace_hardirqs_on+0xd/0xf
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810e3057>] time_hardirqs_on+0x2a/0x2f
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff8109550c>] trace_hardirqs_on_caller+0x16/0x197
      [ 1257.829021]  [<ffffffff8109569a>] trace_hardirqs_on+0xd/0xf
      [ 1257.829021]  [<ffffffff811002b9>] user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810029b4>] do_notify_resume+0x92/0x97
      [ 1257.829021]  [<ffffffff8154bdca>] int_signal+0x12/0x17
      
      What happened was entering into the user code, the interrupts were enabled
      and a max interrupts off was recorded. The trace buffer was saved along with
      various information about the task: comm, pid, uid, priority, etc.
      
      The uid is recorded with task_uid(tsk). But this is a macro that uses rcu_read_lock()
      to retrieve the data, and this happened to happen where RCU is blind (user_enter).
      
      As only the preempt and irqs off tracers can have this happen, and they both
      only have the tsk == current, if tsk == current, use current_uid() instead of
      task_uid(), as current_uid() does not use RCU as only current can change its uid.
      
      This fixes the RCU suspicious splat.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      f17a5194
  6. 29 May, 2013 2 commits
  7. 28 May, 2013 5 commits
    • Jeff Liu's avatar
      cgroup: warn about mismatching options of a new mount of an existing hierarchy · 2a0ff3fb
      Jeff Liu authored
      
      
      With the new __DEVEL__sane_behavior mount option was introduced,
      if the root cgroup is alive with no xattr function, to mount a
      new cgroup with xattr will be rejected in terms of design which
      just fine.  However, if the root cgroup does not mounted with
      __DEVEL__sane_hehavior, to create a new cgroup with xattr option
      will succeed although after that the EA function does not works
      as expected but will get ENOTSUPP for setting up attributes under
      either cgroup. e.g.
      
      setfattr: /cgroup2/test: Operation not supported
      
      Instead of keeping silence in this case, it's better to drop a log
      entry in warning level.  That would be helpful to understand the
      reason behind the scene from the user's perspective, and this is
      essentially an improvement does not break the backward compatibilities.
      
      With this fix, above mount attemption will keep up works as usual but
      the following line cound be found at the system log:
      
      [ ...] cgroup: new mount options do not match the existing superblock
      
      tj: minor formatting / message updates.
      Signed-off-by: default avatarJie Liu <jeff.liu@oracle.com>
      Reported-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      2a0ff3fb
    • Zoran Markovic's avatar
      timekeeping: Correct run-time detection of persistent_clock. · 0d6bd995
      Zoran Markovic authored
      Since commit 31ade306
      
      , timekeeping_init()
      checks for presence of persistent clock by attempting to read a non-zero
      time value. This is an issue on platforms where persistent_clock (instead
      is implemented as a free-running counter (instead of an RTC) starting
      from zero on each boot and running during suspend. Examples are some ARM
      platforms (e.g. PandaBoard).
      
      An attempt to read such a clock during timekeeping_init() may return zero
      value and falsely declare persistent clock as missing. Additionally, in
      the above case suspend times may be accounted twice (once from
      timekeeping_resume() and once from rtc_resume()), resulting in a gradual
      drift of system time.
      
      This patch does a run-time correction of the issue by doing the same check
      during timekeeping_suspend().
      
      A better long-term solution would have to return error when trying to read
      non-existing clock and zero when trying to read an uninitialized clock, but
      that would require changing all persistent_clock implementations.
      
      This patch addresses the immediate breakage, for now.
      
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarZoran Markovic <zoran.markovic@linaro.org>
      [jstultz: Tweaked commit message and subject]
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      0d6bd995
    • Geert Uytterhoeven's avatar
      ntp: Remove unused variable flags in __hardpps · aa848233
      Geert Uytterhoeven authored
      kernel/time/ntp.c: In function ‘__hardpps’:
      kernel/time/ntp.c:877: warning: unused variable ‘flags’
      
      commit a076b214
      
       ("ntp: Remove ntp_lock,
      using the timekeeping locks to protect ntp state") removed its users,
      but not the actual variable.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      aa848233
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Do not poll non allocated cpu buffers · 6721cb60
      Steven Rostedt (Red Hat) authored
      
      
      The tracing infrastructure sets up for possible CPUs, but it uses
      the ring buffer polling, it is possible to call the ring buffer
      polling code with a CPU that hasn't been allocated. This will cause
      a kernel oops when it access a ring buffer cpu buffer that is part
      of the possible cpus but hasn't been allocated yet as the CPU has never
      been online.
      Reported-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Tested-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      6721cb60
    • Thomas Gleixner's avatar
      tick: Cure broadcast false positive pending bit warning · 2938d275
      Thomas Gleixner authored
      commit 26517f3e
      
       (tick: Avoid programming the local cpu timer if
      broadcast pending) added a warning if the cpu enters broadcast mode
      again while the pending bit is still set. Meelis reported that the
      warning triggers. There are two corner cases which have been not
      considered:
      
      1) cpuidle calls clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)
         twice. That can result in the following scenario
      
         CPU0                    CPU1
                                 cpuidle_idle_call()
                                   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)
                                     set cpu in tick_broadcast_oneshot_mask
      
         broadcast interrupt
           event expired for cpu1
           set pending bit
      
                                   acpi_idle_enter_simple()
                                     clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)
                                       WARN_ON(pending bit)
      
        Move the WARN_ON into the section where we enter broadcast mode so
        it wont provide false positives on the second call.
      
      2) safe_halt() enables interrupts, so a broadcast interrupt can be
         delivered befor the broadcast mode is disabled. That sets the
         pending bit for the CPU which receives the broadcast
         interrupt. Though the interrupt is delivered right away from the
         broadcast handler and leaves the pending bit stale.
      
         Clear the pending bit for the current cpu in the broadcast handler.
      Reported-and-tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305271841130.4220@ionos
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      2938d275
  8. 24 May, 2013 2 commits
    • Randy Dunlap's avatar
      auditfilter.c: fix kernel-doc warnings · 387b8b3e
      Randy Dunlap authored
      
      
      Fix kernel-doc warnings in kernel/auditfilter.c:
      
        Warning(kernel/auditfilter.c:1029): Excess function parameter 'loginuid' description in 'audit_receive_filter'
        Warning(kernel/auditfilter.c:1029): Excess function parameter 'sessionid' description in 'audit_receive_filter'
        Warning(kernel/auditfilter.c:1029): Excess function parameter 'sid' description in 'audit_receive_filter'
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      387b8b3e
    • Tejun Heo's avatar
      cgroup: fix a subtle bug in descendant pre-order walk · 7805d000
      Tejun Heo authored
      
      
      When cgroup_next_descendant_pre() initiates a walk, it checks whether
      the subtree root doesn't have any children and if not returns NULL.
      Later code assumes that the subtree isn't empty.  This is broken
      because the subtree may become empty inbetween, which can lead to the
      traversal escaping the subtree by walking to the sibling of the
      subtree root.
      
      There's no reason to have the early exit path.  Remove it along with
      the later assumption that the subtree isn't empty.  This simplifies
      the code a bit and fixes the subtle bug.
      
      While at it, fix the comment of cgroup_for_each_descendant_pre() which
      was incorrectly referring to ->css_offline() instead of
      ->css_online().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Cc: stable@vger.kernel.org
      7805d000
  9. 23 May, 2013 1 commit
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix crash when ftrace=nop on the kernel command line · ca164318
      Steven Rostedt (Red Hat) authored
      
      
      If ftrace=<tracer> is on the kernel command line, when that tracer is
      registered, it will be initiated by tracing_set_tracer() to execute that
      tracer.
      
      The nop tracer is just a stub tracer that is used to have no tracer
      enabled. It is assigned at early bootup as it is the default tracer.
      
      But if ftrace=nop is on the kernel command line, the registering of the
      nop tracer will call tracing_set_tracer() which will try to execute
      the nop tracer. But it expects tr->current_trace to be assigned something
      as it usually is assigned to the nop tracer. As it hasn't been assigned
      to anything yet, it causes the system to crash.
      
      The simple fix is to move the tr->current_trace = nop before registering
      the nop tracer. The functionality is still the same as the nop tracer
      doesn't do anything anyway.
      Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      ca164318
  10. 17 May, 2013 2 commits