1. 07 Jun, 2014 3 commits
    • Behan Webster's avatar
      all: LLVMLinux: Change DWARF flag to support gcc and clang · 2288328c
      Behan Webster authored
      Both gcc (well, actually gnu as) and clang support the "-Wa,-gdwarf-2" option
      (though clang does not support "-Wa,--gdwarf-2"). Since these flags are equivalent
      in meaning, this patch uses the one which is better supported across compilers.
      Signed-off-by: default avatarBehan Webster <behanw@converseincode.com>
      2288328c
    • Mark Charlebois's avatar
      net: netfilter: LLVMLinux: vlais-netfilter · 066c6807
      Mark Charlebois authored
      Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
      xt_repldata.h with a C99 compliant flexible array member and then calculated
      offsets to the other struct members. These other members aren't referenced by
      name in this code, however this patch maintains the same memory layout and
      padding as was previously accomplished using VLAIS.
      
      Had the original structure been ordered differently, with the entries VLA at
      the end, then it could have been a flexible member, and this patch would have
      been a lot simpler. However since the data stored in this structure is
      ultimately exported to userspace, the order of this structure can't be changed.
      
      This patch makes no attempt to change the existing behavior, merely the way in
      which the current layout is accomplished using standard C99 constructs. As such
      the code can now be compiled with either gcc or clang.
      
      This version of the patch removes the trailing alignment that the VLAIS
      structure would allocate in order to simplify the patch.
      
      Author: Mark Charlebois <charlebm@gmail.com>
      Signed-off-by: default avatarMark Charlebois <charlebm@gmail.com>
      Signed-off-by: default avatarBehan Webster <behanw@converseincode.com>
      Signed-off-by: default avatarVinícius Tinti <viniciustinti@gmail.com>
      066c6807
    • Mark Charlebois's avatar
      crypto: LLVMLinux: aligned-attribute.patch · 66d8ea57
      Mark Charlebois authored
      __attribute__((aligned)) applies the default alignment for the largest scalar
      type for the target ABI. gcc allows it to be applied inline to a defined type.
      Clang only allows it to be applied to a type definition (PR11071).
      
      Making it into 2 lines makes it more readable and works with both compilers.
      
      Author: Mark Charlebois <charlebm@gmail.com>
      Signed-off-by: default avatarMark Charlebois <charlebm@gmail.com>
      Signed-off-by: default avatarBehan Webster <behanw@converseincode.com>
      66d8ea57
  2. 06 Jun, 2014 3 commits
  3. 05 Jun, 2014 11 commits
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 951e2730
      Linus Torvalds authored
      Pull perf fixes from Ingo Molnar:
       "Two last minute tooling fixes"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf probe: Fix perf probe to find correct variable DIE
        perf probe: Fix a segfault if asked for variable it doesn't find
      951e2730
    • Linus Torvalds's avatar
      Merge branch 'futex-fixes' (futex fixes from Thomas Gleixner) · 1c5aefb5
      Linus Torvalds authored
      Merge futex fixes from Thomas Gleixner:
       "So with more awake and less futex wreckaged brain, I went through my
        list of points again and came up with the following 4 patches.
      
        1) Prevent pi requeueing on the same futex
      
           I kept Kees check for uaddr1 == uaddr2 as a early check for private
           futexes and added a key comparison to both futex_requeue and
           futex_wait_requeue_pi.
      
           Sebastian, sorry for the confusion yesterday night.  I really
           misunderstood your question.
      
           You are right the check is pointless for shared futexes where the
           same physical address is mapped to two different virtual addresses.
      
        2) Sanity check atomic acquisiton in futex_lock_pi_atomic
      
           That's basically what Darren suggested.
      
           I just simplified it to use futex_top_waiter() to find kernel
           internal state.  If state is found return -EINVAL and do not bother
           to fix up the user space variable.  It's corrupted already.
      
        3) Ensure state consistency in futex_unlock_pi
      
           The code is silly versus the owner died bit.  There is no point to
           preserve it on unlock when the user space thread owns the futex.
      
           What's worse is that it does not update the user space value when
           the owner died bit is set.  So the kernel itself creates observable
           inconsistency.
      
           Another "optimization" is to retry an atomic unlock.  That's
           pointless as in a sane environment user space would not call into
           that code if it could have unlocked it atomically.  So we always
           check whether there is kernel state around and only if there is
           none, we do the unlock by setting the user space value to 0.
      
        4) Sanitize lookup_pi_state
      
           lookup_pi_state is ambigous about TID == 0 in the user space value.
      
           This can be a valid state even if there is kernel state on this
           uaddr, but we miss a few corner case checks.
      
           I tried to come up with a smaller solution hacking the checks into
           the current cruft, but it turned out to be ugly as hell and I got
           more confused than I was before.  So I rewrote the sanity checks
           along the state documentation with awful lots of commentry"
      
      * emailed patches from Thomas Gleixner <tglx@linutronix.de>:
        futex: Make lookup_pi_state more robust
        futex: Always cleanup owner tid in unlock_pi
        futex: Validate atomic acquisition in futex_lock_pi_atomic()
        futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)
      1c5aefb5
    • Thomas Gleixner's avatar
      futex: Make lookup_pi_state more robust · 54a21788
      Thomas Gleixner authored
      The current implementation of lookup_pi_state has ambigous handling of
      the TID value 0 in the user space futex.  We can get into the kernel
      even if the TID value is 0, because either there is a stale waiters bit
      or the owner died bit is set or we are called from the requeue_pi path
      or from user space just for fun.
      
      The current code avoids an explicit sanity check for pid = 0 in case
      that kernel internal state (waiters) are found for the user space
      address.  This can lead to state leakage and worse under some
      circumstances.
      
      Handle the cases explicit:
      
             Waiter | pi_state | pi->owner | uTID      | uODIED | ?
      
        [1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
        [2]  NULL   | ---      | ---       | >0        | 0/1    | Valid
      
        [3]  Found  | NULL     | --        | Any       | 0/1    | Invalid
      
        [4]  Found  | Found    | NULL      | 0         | 1      | Valid
        [5]  Found  | Found    | NULL      | >0        | 1      | Invalid
      
        [6]  Found  | Found    | task      | 0         | 1      | Valid
      
        [7]  Found  | Found    | NULL      | Any       | 0      | Invalid
      
        [8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
        [9]  Found  | Found    | task      | 0         | 0      | Invalid
        [10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid
      
       [1] Indicates that the kernel can acquire the futex atomically. We
           came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.
      
       [2] Valid, if TID does not belong to a kernel thread. If no matching
           thread is found then it indicates that the owner TID has died.
      
       [3] Invalid. The waiter is queued on a non PI futex
      
       [4] Valid state after exit_robust_list(), which sets the user space
           value to FUTEX_WAITERS | FUTEX_OWNER_DIED.
      
       [5] The user space value got manipulated between exit_robust_list()
           and exit_pi_state_list()
      
       [6] Valid state after exit_pi_state_list() which sets the new owner in
           the pi_state but cannot access the user space value.
      
       [7] pi_state->owner can only be NULL when the OWNER_DIED bit is set.
      
       [8] Owner and user space value match
      
       [9] There is no transient state which sets the user space TID to 0
           except exit_robust_list(), but this is indicated by the
           FUTEX_OWNER_DIED bit. See [4]
      
      [10] There is no transient state which leaves owner and user space
           TID out of sync.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Darren Hart <dvhart@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      54a21788
    • Thomas Gleixner's avatar
      futex: Always cleanup owner tid in unlock_pi · 13fbca4c
      Thomas Gleixner authored
      If the owner died bit is set at futex_unlock_pi, we currently do not
      cleanup the user space futex.  So the owner TID of the current owner
      (the unlocker) persists.  That's observable inconsistant state,
      especially when the ownership of the pi state got transferred.
      
      Clean it up unconditionally.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Darren Hart <dvhart@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      13fbca4c
    • Thomas Gleixner's avatar
      futex: Validate atomic acquisition in futex_lock_pi_atomic() · b3eaa9fc
      Thomas Gleixner authored
      We need to protect the atomic acquisition in the kernel against rogue
      user space which sets the user space futex to 0, so the kernel side
      acquisition succeeds while there is existing state in the kernel
      associated to the real owner.
      
      Verify whether the futex has waiters associated with kernel state.  If
      it has, return -EINVAL.  The state is corrupted already, so no point in
      cleaning it up.  Subsequent calls will fail as well.  Not our problem.
      
      [ tglx: Use futex_top_waiter() and explain why we do not need to try
        	restoring the already corrupted user space state. ]
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Will Drewry <wad@chromium.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b3eaa9fc
    • Thomas Gleixner's avatar
      futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in... · e9c243a5
      Thomas Gleixner authored
      futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)
      
      If uaddr == uaddr2, then we have broken the rule of only requeueing from
      a non-pi futex to a pi futex with this call.  If we attempt this, then
      dangling pointers may be left for rt_waiter resulting in an exploitable
      condition.
      
      This change brings futex_requeue() in line with futex_wait_requeue_pi()
      which performs the same check as per commit 6f7b0a2a ("futex: Forbid
      uaddr == uaddr2 in futex_wait_requeue_pi()")
      
      [ tglx: Compare the resulting keys as well, as uaddrs might be
        	different depending on the mapping ]
      
      Fixes CVE-2014-3153.
      
      Reported-by: Pinkie Pie
      Signed-off-by: default avatarWill Drewry <wad@chromium.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e9c243a5
    • Roman Gushchin's avatar
      sched/fair: Fix tg_set_cfs_bandwidth() deadlock on rq->lock · 09dc4ab0
      Roman Gushchin authored
      tg_set_cfs_bandwidth() sets cfs_b->timer_active to 0 to
      force the period timer restart. It's not safe, because
      can lead to deadlock, described in commit 927b54fc:
      "__start_cfs_bandwidth calls hrtimer_cancel while holding rq->lock,
      waiting for the hrtimer to finish. However, if sched_cfs_period_timer
      runs for another loop iteration, the hrtimer can attempt to take
      rq->lock, resulting in deadlock."
      
      Three CPUs must be involved:
      
        CPU0               CPU1                         CPU2
        take rq->lock      period timer fired
        ...                take cfs_b lock
        ...                ...                          tg_set_cfs_bandwidth()
        throttle_cfs_rq()  release cfs_b lock           take cfs_b lock
        ...                distribute_cfs_runtime()     timer_active = 0
        take cfs_b->lock   wait for rq->lock            ...
        __start_cfs_bandwidth()
        {wait for timer callback
         break if timer_active == 1}
      
      So, CPU0 and CPU1 are deadlocked.
      
      Instead of resetting cfs_b->timer_active, tg_set_cfs_bandwidth can
      wait for period timer callbacks (ignoring cfs_b->timer_active) and
      restart the timer explicitly.
      Signed-off-by: default avatarRoman Gushchin <klamm@yandex-team.ru>
      Reviewed-by: default avatarBen Segall <bsegall@google.com>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/87wqdi9g8e.wl\%klamm@yandex-team.ru
      Cc: pjt@google.com
      Cc: chris.j.arges@canonical.com
      Cc: gregkh@linuxfoundation.org
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      09dc4ab0
    • Kirill Tkhai's avatar
      sched/dl: Fix race in dl_task_timer() · 0f397f2c
      Kirill Tkhai authored
      Throttled task is still on rq, and it may be moved to other cpu
      if user is playing with sched_setaffinity(). Therefore, unlocked
      task_rq() access makes the race.
      
      Juri Lelli reports he got this race when dl_bandwidth_enabled()
      was not set.
      
      Other thing, pointed by Peter Zijlstra:
      
         "Now I suppose the problem can still actually happen when
          you change the root domain and trigger a effective affinity
          change that way".
      
      To fix that we do the same as made in __task_rq_lock(). We do not
      use __task_rq_lock() itself, because it has a useful lockdep check,
      which is not correct in case of dl_task_timer(). We do not need
      pi_lock locked here. This case is an exception (PeterZ):
      
         "The only reason we don't strictly need ->pi_lock now is because
          we're guaranteed to have p->state == TASK_RUNNING here and are
          thus free of ttwu races".
      Signed-off-by: default avatarKirill Tkhai <tkhai@yandex.ru>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: <stable@vger.kernel.org> # v3.14+
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/3056991400578422@web14g.yandex.ruSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0f397f2c
    • Richard Weinberger's avatar
      sched: Fix sched_policy < 0 comparison · b14ed2c2
      Richard Weinberger authored
      attr.sched_policy is u32, therefore a comparison against < 0 is never true.
      Fix this by casting sched_policy to int.
      
      This issue was reported by coverity CID 1219934.
      
      Fixes: dbdb2275 ("sched: Disallow sched_attr::sched_policy < 0")
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1401741514-7045-1-git-send-email-richard@nod.atSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b14ed2c2
    • Steven Rostedt's avatar
      sched/numa: Fix use of spin_{un}lock_irq() when interrupts are disabled · e9dd685c
      Steven Rostedt authored
      As Peter Zijlstra told me, we have the following path:
      
      do_exit()
        exit_itimers()
          itimer_delete()
            spin_lock_irqsave(&timer->it_lock, &flags);
            timer_delete_hook(timer);
              kc->timer_del(timer) := posix_cpu_timer_del()
                put_task_struct()
                  __put_task_struct()
                    task_numa_free()
                      spin_lock(&grp->lock);
      
      Which means that task_numa_free() can be called with interrupts
      disabled, which means that we should not be using spin_lock_irq() but
      spin_lock_irqsave() instead. Otherwise we are enabling interrupts while
      holding an interrupt unsafe lock!
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner<tglx@linutronix.de>
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20140527182541.GH11096@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e9dd685c
    • Ingo Molnar's avatar
      Merge tag 'perf-urgent-for-mingo' of... · 22c91aa2
      Ingo Molnar authored
      Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/urgent
      
      Pull perf/urgent fixes from Jiri Olsa:
      
       * Fix perf probe to find correct variable DIE (Masami Hiramatsu)
      
       * Fix a segfault in perf probe if asked for variable it doesn't find (Masami Hiramatsu)
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      22c91aa2
  4. 04 Jun, 2014 7 commits
    • Linus Torvalds's avatar
      Merge branch 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu · 54539cd2
      Linus Torvalds authored
      Pull percpu fix from Tejun Heo:
       "It is very late but this is an important percpu-refcount fix from
        Sebastian Ott.
      
        The problem is that percpu_ref_*() used __this_cpu_*() instead of
        this_cpu_*().  The difference between the two is that the latter is
        atomic on the local cpu while the former is not.  this_cpu_inc() is
        guaranteed to increment the percpu counter on the cpu that the
        operation is executed on without any synchronization; however,
        __this_cpu_inc() doesn't and if the local cpu invokes the function
        from different contexts (e.g.  process and irq) of the same CPU, it's
        not guaranteed to actually increment as it may be implemented as rmw.
      
        This bug existed from the get-go but it hasn't been noticed earlier
        probably because on x86 __this_cpu_inc() is equivalent to
        this_cpu_inc() as both get translated into single instruction;
        however, s390 uses the generic rmw implementation and gets affected by
        the bug.  Kudos to Sebastian and Heiko for diagnosing it.
      
        The change is very low risk and fixes a critical issue on the affected
        architectures, so I think it's a good candidate for inclusion although
        it's very late in the devel cycle.  On the other hand, this has been
        broken since v3.11, so backporting it through -stable post -rc1 won't
        be the end of the world.
      
        I'll ping Christoph whether __this_cpu_*() ops can be better annotated
        so that it can trigger lockdep warning when used from multiple
        contexts"
      
      * 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
        percpu-refcount: fix usage of this_cpu_ops
      54539cd2
    • Sebastian Ott's avatar
      percpu-refcount: fix usage of this_cpu_ops · 0c36b390
      Sebastian Ott authored
      The percpu-refcount infrastructure uses the underscore variants of
      this_cpu_ops in order to modify percpu reference counters.
      (e.g. __this_cpu_inc()).
      
      However the underscore variants do not atomically update the percpu
      variable, instead they may be implemented using read-modify-write
      semantics (more than one instruction).  Therefore it is only safe to
      use the underscore variant if the context is always the same (process,
      softirq, or hardirq). Otherwise it is possible to lose updates.
      
      This problem is something that Sebastian has seen within the aio
      subsystem which uses percpu refcounters both in process and softirq
      context leading to reference counts that never dropped to zeroes; even
      though the number of "get" and "put" calls matched.
      
      Fix this by using the non-underscore this_cpu_ops variant which
      provides correct per cpu atomic semantics and fixes the corrupted
      reference counts.
      
      Cc: Kent Overstreet <kmo@daterainc.com>
      Cc: <stable@vger.kernel.org> # v3.11+
      Reported-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      References: http://lkml.kernel.org/g/alpine.LFD.2.11.1406041540520.21183@denkbrett
      0c36b390
    • Linus Torvalds's avatar
      Merge tag 'pm-3.15-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · c717d156
      Linus Torvalds authored
      Pull intel pstate fixes from Rafael Wysocki:
       "Final power management fixes for 3.15
      
         - Taking non-idle time into account when calculating core busy time
           was a mistake and led to a performance regression.  Since the
           problem it was supposed to address is now taken care of in a
           different way, we don't need to do it any more, so drop the
           non-idle time tracking from intel_pstate.  Dirk Brandewie.
      
         - Changing to fixed point math throughout the busy calculation
           introduced rounding errors that adversely affect the accuracy of
           intel_pstate's computations.  Fix from Dirk Brandewie.
      
         - The PID controller algorithm used by intel_pstate assumes that the
           time interval between two adjacent samples will always be the same
           which is not the case for deferable timers (used by intel_pstate)
           when the system is idle.  This leads to inaccurate predictions and
           artificially increases convergence times for the minimum P-state.
           Fix from Dirk Brandewie.
      
         - intel_pstate carries out computations using 32-bit variables that
           may overflow for large enough values of APERF/MPERF.  Switch to
           using 64-bit variables for computations, from Doug Smythies"
      
      * tag 'pm-3.15-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        intel_pstate: Improve initial busy calculation
        intel_pstate: add sample time scaling
        intel_pstate: Correct rounding in busy calculation
        intel_pstate: Remove C0 tracking
      c717d156
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 9e9a928e
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "All fairly small: radeon stability and a panic path fix.
      
        Mostly radeon fixes, suspend/resume fix, stability on the CIK
        chipsets, along with a locking check avoidance patch for panic times
        regression"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/radeon: use the CP DMA on CIK
        drm/radeon: sync page table updates
        drm/radeon: fix vm buffer size estimation
        drm/crtc-helper: skip locking checks in panicking path
        drm/radeon/dpm: resume fixes for some systems
      9e9a928e
    • Masami Hiramatsu's avatar
      perf probe: Fix perf probe to find correct variable DIE · 082f96a9
      Masami Hiramatsu authored
      Fix perf probe to find correct variable DIE which has location or
      external instance by tracking down the lexical blocks.
      
      Current die_find_variable() expects that the all variable DIEs
      which has DW_TAG_variable have a location. However, since recent
      dwarf information may have declaration variable DIEs at the
      entry of function (subprogram), die_find_variable() returns it.
      
      To solve this problem, it must track down the DIE tree to find
      a DIE which has an actual location or a reference for external
      instance.
      
      e.g. finding a DIE which origin is <0xdc73>;
      
       <1><11496>: Abbrev Number: 95 (DW_TAG_subprogram)
          <11497>   DW_AT_abstract_origin: <0xdc42>
          <1149b>   DW_AT_low_pc      : 0x1850
      [...]
       <2><114cc>: Abbrev Number: 119 (DW_TAG_variable) <- this is a declaration
          <114cd>   DW_AT_abstract_origin: <0xdc73>
       <2><114d1>: Abbrev Number: 119 (DW_TAG_variable)
      [...]
       <3><115a7>: Abbrev Number: 105 (DW_TAG_lexical_block)
          <115a8>   DW_AT_ranges      : 0xaa0
       <4><115ac>: Abbrev Number: 96 (DW_TAG_variable) <- this has a location
          <115ad>   DW_AT_abstract_origin: <0xdc73>
          <115b1>   DW_AT_location    : 0x486c        (location list)
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Acked-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/20140529121930.30879.87092.stgit@ltc230.yrl.intra.hitachi.co.jpSigned-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      082f96a9
    • Masami Hiramatsu's avatar
      perf probe: Fix a segfault if asked for variable it doesn't find · 0c188a07
      Masami Hiramatsu authored
      Fix a segfault bug by asking for variable it doesn't find.
      Since the convert_variable() didn't handle error code returned
      from convert_variable_location(), it just passed an incomplete
      variable field and then a segfault was occurred when formatting
      the field.
      
      This fixes that bug by handling success code correctly in
      convert_variable(). Other callers of convert_variable_location()
      are correctly checking the return code.
      
      This bug was introduced by following commit. But another hidden
      erroneous error handling has been there previously (-ENOMEM case).
      
       commit 3d918a12Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Reported-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/20140529105232.28251.30447.stgit@ltc230.yrl.intra.hitachi.co.jpSigned-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      0c188a07
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes · 0a4ae727
      Dave Airlie authored
      The first one is a one liner fixing a stupid typo in the VM handling code and is only relevant if play with one of the VM defines.
      
      The other two switches CIK to use the CPDMA instead of the SDMA for buffer moves, as it turned out the SDMA is still sometimes not 100% reliable.
      
      * 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
        drm/radeon: use the CP DMA on CIK
        drm/radeon: sync page table updates
        drm/radeon: fix vm buffer size estimation
      0a4ae727
  5. 03 Jun, 2014 6 commits
    • Linus Torvalds's avatar
      Merge tag 'sound-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · d2cfd310
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "A few addition of HD-audio fixups for ALC260 and AD1986A codecs.  All
        marked as stable fixes.
      
        The fixes are pretty local and they are old machines, so quite safe to
        apply"
      
      * tag 'sound-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda/realtek - Fix COEF widget NID for ALC260 replacer fixup
        ALSA: hda/realtek - Correction of fixup codes for PB V7900 laptop
        ALSA: hda/analog - Fix silent output on ASUS A8JN
      d2cfd310
    • Jianyu Zhan's avatar
      kernfs: move the last knowledge of sysfs out from kernfs · c9482a5b
      Jianyu Zhan authored
      There is still one residue of sysfs remaining: the sb_magic
      SYSFS_MAGIC. However this should be kernfs user specific,
      so this patch moves it out. Kerrnfs user should specify their
      magic number while mouting.
      Signed-off-by: default avatarJianyu Zhan <nasa4836@gmail.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c9482a5b
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · cae61ba3
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Unbreak zebra and other netlink apps, from Eric W Biederman.
      
       2) Some new qmi_wwan device IDs, from Aleksander Morgado.
      
       3) Fix info leak in DCB netlink handler of qlcnic driver, from Dan
          Carpenter.
      
       4) inet_getid() and ipv6_select_ident() do not generate monotonically
          increasing ID numbers, fix from Eric Dumazet.
      
       5) Fix memory leak in __sk_prepare_filter(), from Leon Yu.
      
       6) Netlink leftover bytes warning message is user triggerable, rate
          limit it.  From Michal Schmidt.
      
       7) Fix non-linear SKB panic in ipvs, from Peter Christensen.
      
       8) Congestion window undo needs to be performed even if only never
          retransmitted data is SACK'd, fix from Yuching Cheng.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (24 commits)
        net: filter: fix possible memory leak in __sk_prepare_filter()
        net: ec_bhf: Add runtime dependencies
        tcp: fix cwnd undo on DSACK in F-RTO
        netlink: Only check file credentials for implicit destinations
        ipheth: Add support for iPad 2 and iPad 3
        team: fix mtu setting
        net: fix inet_getid() and ipv6_select_ident() bugs
        net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI
        net: qmi_wwan: add additional Sierra Wireless QMI devices
        bridge: Prevent insertion of FDB entry with disallowed vlan
        netlink: rate-limit leftover bytes warning and print process name
        bridge: notify user space after fdb update
        net: qmi_wwan: add Netgear AirCard 341U
        net: fix wrong mac_len calculation for vlans
        batman-adv: fix NULL pointer dereferences
        net/mlx4_core: Reset RoCE VF gids when guest driver goes down
        emac: aggregation of v1-2 PLB errors for IER register
        emac: add missing support of 10mbit in emac/rgmii
        can: only rename enabled led triggers when changing the netdev name
        ipvs: Fix panic due to non-linear skb
        ...
      cae61ba3
    • Leon Yu's avatar
      net: filter: fix possible memory leak in __sk_prepare_filter() · 418c96ac
      Leon Yu authored
      __sk_prepare_filter() was reworked in commit bd4cf0ed (net: filter:
      rework/optimize internal BPF interpreter's instruction set) so that it should
      have uncharged memory once things went wrong. However that work isn't complete.
      Error is handled only in __sk_migrate_filter() while memory can still leak in
      the error path right after sk_chk_filter().
      
      Fixes: bd4cf0ed ("net: filter: rework/optimize internal BPF interpreter's instruction set")
      Signed-off-by: default avatarLeon Yu <chianglungyu@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Tested-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      418c96ac
    • Linus Torvalds's avatar
      Merge tag 'md/3.15-fixes' of git://neil.brown.name/md · ca755175
      Linus Torvalds authored
      Pull two md bugfixes from Neil Brown:
       "Two md bugfixes for possible corruption when restarting reshape
      
        If a raid5/6 reshape is restarted (After stopping and re-assembling
        the array) and the array is marked read-only (or read-auto), then the
        reshape will appear to complete immediately, without actually moving
        anything around.  This can result in corruption.
      
        There are two patches which do much the same thing in different
        places.  They are separate because one is an older bug and so can be
        applied to more -stable kernels"
      
      * tag 'md/3.15-fixes' of git://neil.brown.name/md:
        md: always set MD_RECOVERY_INTR when interrupting a reshape thread.
        md: always set MD_RECOVERY_INTR when aborting a reshape or other "resync".
      ca755175
    • Jean Delvare's avatar
      net: ec_bhf: Add runtime dependencies · 3aab01d8
      Jean Delvare authored
      The ec_bhf driver is specific to the Beckhoff CX embedded PC series.
      These are based on Intel x86 CPU. So we can add a dependency on
      X86, with COMPILE_TEST as an alternative to still allow for broader
      build-testing.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Cc: Darek Marcinkiewicz <reksio@newterm.pl>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3aab01d8
  6. 02 Jun, 2014 10 commits