1. 09 Dec, 2014 2 commits
  2. 01 Dec, 2014 3 commits
  3. 27 Nov, 2014 2 commits
    • Jeff Layton's avatar
      sunrpc: add a debugfs rpc_xprt directory with an info file in it · 388f0c77
      Jeff Layton authored
      Add a new directory heirarchy under the debugfs sunrpc/ directory:
      
          sunrpc/
              rpc_xprt/
                  <xprt id>/
      
      Within that directory, we can put files that give info about the
      xprts. We do have the (minor) problem that there is no succinct,
      unique identifier for rpc_xprts. So we generate them synthetically
      with a static atomic_t counter.
      
      For now, this directory just holds an "info" file, but we may add
      other files to it in the future.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      388f0c77
    • Jeff Layton's avatar
      sunrpc: add debugfs file for displaying client rpc_task queue · b4b9d2cc
      Jeff Layton authored
      It's possible to get a dump of the RPC task queue by writing a value to
      /proc/sys/sunrpc/rpc_debug. If you write any value to that file, you get
      a dump of the RPC client task list into the log buffer. This is a rather
      inconvenient interface however, and makes it hard to get immediate info
      about the task queue.
      
      Add a new directory hierarchy under debugfs:
      
          sunrpc/
              rpc_clnt/
                  <clientid>/
      
      Within each clientid directory we create a new "tasks" file that will
      dump info similar to what shows up in the log buffer, but with a few
      small differences -- we avoid printing raw kernel addresses in favor of
      symbolic names and the XID is also displayed.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      b4b9d2cc
  4. 26 Nov, 2014 2 commits
  5. 25 Nov, 2014 15 commits
  6. 24 Nov, 2014 11 commits
  7. 23 Nov, 2014 5 commits
    • Linus Torvalds's avatar
      Linux 3.18-rc6 · 5d01410f
      Linus Torvalds authored
      5d01410f
    • Andy Lutomirski's avatar
      uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME · 82975bc6
      Andy Lutomirski authored
      x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set but
      not on non-paranoid returns.  I suspect that this is a mistake and that
      the code only works because int3 is paranoid.
      
      Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a workaround
      for the x86 bug.  With that bug fixed, we can remove _TIF_NOTIFY_RESUME
      from the uprobes code.
      Reported-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      82975bc6
    • Thomas Gleixner's avatar
      sched: Provide update_curr callbacks for stop/idle scheduling classes · 90e362f4
      Thomas Gleixner authored
      Chris bisected a NULL pointer deference in task_sched_runtime() to
      commit 6e998916 'sched/cputime: Fix clock_nanosleep()/clock_gettime()
      inconsistency'.
      
      Chris observed crashes in atop or other /proc walking programs when he
      started fork bombs on his machine.  He assumed that this is a new exit
      race, but that does not make any sense when looking at that commit.
      
      What's interesting is that, the commit provides update_curr callbacks
      for all scheduling classes except stop_task and idle_task.
      
      While nothing can ever hit that via the clock_nanosleep() and
      clock_gettime() interfaces, which have been the target of the commit in
      question, the author obviously forgot that there are other code paths
      which invoke task_sched_runtime()
      
      do_task_stat(()
       thread_group_cputime_adjusted()
         thread_group_cputime()
           task_cputime()
             task_sched_runtime()
              if (task_current(rq, p) && task_on_rq_queued(p)) {
                update_rq_clock(rq);
                up->sched_class->update_curr(rq);
              }
      
      If the stats are read for a stomp machine task, aka 'migration/N' and
      that task is current on its cpu, this will happily call the NULL pointer
      of stop_task->update_curr.  Ooops.
      
      Chris observation that this happens faster when he runs the fork bomb
      makes sense as the fork bomb will kick migration threads more often so
      the probability to hit the issue will increase.
      
      Add the missing update_curr callbacks to the scheduler classes stop_task
      and idle_task.  While idle tasks cannot be monitored via /proc we have
      other means to hit the idle case.
      
      Fixes: 6e998916 'sched/cputime: Fix clock_nanosleep()/clock_gettime() inconsistency'
      Reported-by: default avatarChris Mason <clm@fb.com>
      Reported-and-tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Stanislaw Gruszka <sgruszka@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      90e362f4
    • Linus Torvalds's avatar
      Merge branch 'x86-traps' (trap handling from Andy Lutomirski) · 00c89b2f
      Linus Torvalds authored
      Merge x86-64 iret fixes from Andy Lutomirski:
       "This addresses the following issues:
      
         - an unrecoverable double-fault triggerable with modify_ldt.
         - invalid stack usage in espfix64 failed IRET recovery from IST
           context.
         - invalid stack usage in non-espfix64 failed IRET recovery from IST
           context.
      
        It also makes a good but IMO scary change: non-espfix64 failed IRET
        will now report the correct error.  Hopefully nothing depended on the
        old incorrect behavior, but maybe Wine will get confused in some
        obscure corner case"
      
      * emailed patches from Andy Lutomirski <luto@amacapital.net>:
        x86_64, traps: Rework bad_iret
        x86_64, traps: Stop using IST for #SS
        x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C
      00c89b2f
    • Andy Lutomirski's avatar
      x86_64, traps: Rework bad_iret · b645af2d
      Andy Lutomirski authored
      It's possible for iretq to userspace to fail.  This can happen because
      of a bad CS, SS, or RIP.
      
      Historically, we've handled it by fixing up an exception from iretq to
      land at bad_iret, which pretends that the failed iret frame was really
      the hardware part of #GP(0) from userspace.  To make this work, there's
      an extra fixup to fudge the gs base into a usable state.
      
      This is suboptimal because it loses the original exception.  It's also
      buggy because there's no guarantee that we were on the kernel stack to
      begin with.  For example, if the failing iret happened on return from an
      NMI, then we'll end up executing general_protection on the NMI stack.
      This is bad for several reasons, the most immediate of which is that
      general_protection, as a non-paranoid idtentry, will try to deliver
      signals and/or schedule from the wrong stack.
      
      This patch throws out bad_iret entirely.  As a replacement, it augments
      the existing swapgs fudge into a full-blown iret fixup, mostly written
      in C.  It's should be clearer and more correct.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b645af2d