1. 07 9月, 2013 4 次提交
  2. 04 9月, 2013 6 次提交
    • H
      s390/irq: rework irq subclass handling · 82003c3e
      Heiko Carstens 提交于
      Let's not add a function for every external interrupt subclass for
      which we need reference counting. Just have two register/unregister
      functions which have a subclass parameter:
      
      void irq_subclass_register(enum irq_subclass subclass);
      void irq_subclass_unregister(enum irq_subclass subclass);
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      82003c3e
    • H
      s390/irq: use hlists for external interrupt handler array · 50ce749d
      Heiko Carstens 提交于
      Use hlists for the hashed array of external interrupt handlers.
      Reduces the size of the array by 50% (2KB).
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      50ce749d
    • H
      s390/dumpstack: convert print_symbol to %pSR · 8237ac3c
      Heiko Carstens 提交于
      This is the same as what other architectures did.
      The change has also the advantage that there won't be any interleaving
      messages between printk() and print_symbol().
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      8237ac3c
    • H
    • H
      s390: update defconfig · 3b459c54
      Heiko Carstens 提交于
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      3b459c54
    • H
      s390/bpf,jit: fix address randomization · 4784955a
      Heiko Carstens 提交于
      Add misssing braces to hole calculation. This resulted in an addition
      instead of an substraction. Which in turn means that the jit compiler
      could try to write out of bounds of the allocated piece of memory.
      
      This bug was introduced with aa2d2c73 "s390/bpf,jit: address randomize
      and write protect jit code".
      
      Fixes this one:
      
      [   37.320956] Unable to handle kernel pointer dereference at virtual kernel address 000003ff80231000
      [   37.320984] Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [   37.320993] Modules linked in: dm_multipath scsi_dh eadm_sch dm_mod ctcm fsm autofs4
      [   37.321007] CPU: 28 PID: 6443 Comm: multipathd Not tainted 3.10.9-61.x.20130829-s390xdefault #1
      [   37.321011] task: 0000004ada778000 ti: 0000004ae3304000 task.ti: 0000004ae3304000
      [   37.321014] Krnl PSW : 0704c00180000000 000000000012d1de (bpf_jit_compile+0x198e/0x23d0)
      [   37.321022]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
                     Krnl GPRS: 000000004350207d 0000004a00000001 0000000000000007 000003ff80231002
      [   37.321029]            0000000000000007 000003ff80230ffe 00000000a7740000 000003ff80230f76
      [   37.321032]            000003ffffffffff 000003ff00000000 000003ff0000007d 000000000071e820
      [   37.321035]            0000004adbe99950 000000000071ea18 0000004af3d9e7c0 0000004ae3307b80
      [   37.321046] Krnl Code: 000000000012d1d0: 41305004            la      %r3,4(%r5)
                                000000000012d1d4: e330f0f80021        clg     %r3,248(%r15)
                               #000000000012d1da: a7240009            brc     2,12d1ec
                               >000000000012d1de: 50805000            st      %r8,0(%r5)
                                000000000012d1e2: e330f0f00004        lg      %r3,240(%r15)
                                000000000012d1e8: 41303004            la      %r3,4(%r3)
                                000000000012d1ec: e380f0e00004        lg      %r8,224(%r15)
                                000000000012d1f2: e330f0f00024        stg     %r3,240(%r15)
      [   37.321074] Call Trace:
      [   37.321077] ([<000000000012da78>] bpf_jit_compile+0x2228/0x23d0)
      [   37.321083]  [<00000000006007c2>] sk_attach_filter+0xfe/0x214
      [   37.321090]  [<00000000005d2d92>] sock_setsockopt+0x926/0xbdc
      [   37.321097]  [<00000000005cbfb6>] SyS_setsockopt+0x8a/0xe8
      [   37.321101]  [<00000000005ccaa8>] SyS_socketcall+0x264/0x364
      [   37.321106]  [<0000000000713f1c>] sysc_nr_ok+0x22/0x28
      [   37.321113]  [<000003fffce10ea8>] 0x3fffce10ea8
      [   37.321118] INFO: lockdep is turned off.
      [   37.321121] Last Breaking-Event-Address:
      [   37.321124]  [<000000000012d192>] bpf_jit_compile+0x1942/0x23d0
      [   37.321132]
      [   37.321135] Kernel panic - not syncing: Fatal exception: panic_on_oops
      
      Cc: stable@vger.kernel.org # v3.11
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      4784955a
  3. 03 9月, 2013 2 次提交
    • L
      ARM: dts: Use the PWM polarity flags · eb9bdef1
      Laurent Pinchart 提交于
      Replace the numerical polarity flags with the PWM_POLARITY_INVERTED
      symbolic constant.
      Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
      eb9bdef1
    • L
      lockref: implement lockless reference count updates using cmpxchg() · bc08b449
      Linus Torvalds 提交于
      Instead of taking the spinlock, the lockless versions atomically check
      that the lock is not taken, and do the reference count update using a
      cmpxchg() loop.  This is semantically identical to doing the reference
      count update protected by the lock, but avoids the "wait for lock"
      contention that you get when accesses to the reference count are
      contended.
      
      Note that a "lockref" is absolutely _not_ equivalent to an atomic_t.
      Even when the lockref reference counts are updated atomically with
      cmpxchg, the fact that they also verify the state of the spinlock means
      that the lockless updates can never happen while somebody else holds the
      spinlock.
      
      So while "lockref_put_or_lock()" looks a lot like just another name for
      "atomic_dec_and_lock()", and both optimize to lockless updates, they are
      fundamentally different: the decrement done by atomic_dec_and_lock() is
      truly independent of any lock (as long as it doesn't decrement to zero),
      so a locked region can still see the count change.
      
      The lockref structure, in contrast, really is a *locked* reference
      count.  If you hold the spinlock, the reference count will be stable and
      you can modify the reference count without using atomics, because even
      the lockless updates will see and respect the state of the lock.
      
      In order to enable the cmpxchg lockless code, the architecture needs to
      do three things:
      
       (1) Make sure that the "arch_spinlock_t" and an "unsigned int" can fit
           in an aligned u64, and have a "cmpxchg()" implementation that works
           on such a u64 data type.
      
       (2) define a helper function to test for a spinlock being unlocked
           ("arch_spin_value_unlocked()")
      
       (3) select the "ARCH_USE_CMPXCHG_LOCKREF" config variable in its
           Kconfig file.
      
      This enables it for x86-64 (but not 32-bit, we'd need to make sure
      cmpxchg() turns into the proper cmpxchg8b in order to enable it for
      32-bit mode).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bc08b449
  4. 30 8月, 2013 11 次提交
  5. 29 8月, 2013 2 次提交
  6. 28 8月, 2013 8 次提交
  7. 27 8月, 2013 2 次提交
    • P
      powerpc: Work around gcc miscompilation of __pa() on 64-bit · bdbc29c1
      Paul Mackerras 提交于
      On 64-bit, __pa(&static_var) gets miscompiled by recent versions of
      gcc as something like:
      
              addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
              addi 3,3,.LANCHOR1+4611686018427387904@toc@l
      
      This ends up effectively ignoring the offset, since its bottom 32 bits
      are zero, and means that the result of __pa() still has 0xC in the top
      nibble.  This happens with gcc 4.8.1, at least.
      
      To work around this, for 64-bit we make __pa() use an AND operator,
      and for symmetry, we make __va() use an OR operator.  Using an AND
      operator rather than a subtraction ends up with slightly shorter code
      since it can be done with a single clrldi instruction, whereas it
      takes three instructions to form the constant (-PAGE_OFFSET) and add
      it on.  (Note that MEMORY_START is always 0 on 64-bit.)
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bdbc29c1
    • B
      powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor · f5f6cbb6
      Benjamin Herrenschmidt 提交于
      /proc/powerpc/lparcfg is an ancient facility (though still actively used)
      which allows access to some informations relative to the partition when
      running underneath a PAPR compliant hypervisor.
      
      It makes no sense on non-pseries machines. However, currently, not only
      can it be created on these if the kernel has pseries support, but accessing
      it on such a machine will crash due to trying to do hypervisor calls.
      
      In fact, it should also not do HV calls on older pseries that didn't have
      an hypervisor either.
      
      Finally, it has the plumbing to be a module but is a "bool" Kconfig option.
      
      This fixes the whole lot by turning it into a machine_device_initcall
      that is only created on pseries, and adding the necessary hypervisor
      check before calling the H_GET_EM_PARMS hypercall
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f5f6cbb6
  8. 25 8月, 2013 1 次提交
  9. 23 8月, 2013 4 次提交