1. 12 May, 2015 8 commits
    • hujianyang's avatar
      UBI: fix soft lockup in ubi_check_volume() · f0958ab0
      hujianyang authored
      commit 9aa272b4 upstream.
      
      Running mtd-utils/tests/ubi-tests/io_basic.c could cause
      soft lockup or watchdog reset. It is because *updatevol*
      will perform ubi_check_volume() after updating finish
      and this function will full scan the updated lebs if the
      volume is initialized as STATIC_VOLUME.
      
      This patch adds *cond_resched()* in the loop of lebs scan
      to avoid soft lockup.
      
      Helped by Richard Weinberger <richard@nod.at>
      
      [ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 jiffies g=1606 c=1605 q=56)
      [ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G           O 3.10.53 #21
      [ 2158.172898] [<c000f624>] (unwind_backtrace+0x0/0x120) from [<c000c294>] (show_stack+0x10/0x14)
      [ 2158.172918] [<c000c294>] (show_stack+0x10/0x14) from [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660)
      [ 2158.172936] [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660) from [<c002b480>] (update_process_times+0x38/0x64)
      [ 2158.172953] [<c002b480>] (update_process_times+0x38/0x64) from [<c005ff38>] (tick_sched_handle+0x54/0x60)
      [ 2158.172966] [<c005ff38>] (tick_sched_handle+0x54/0x60) from [<c00601ac>] (tick_sched_timer+0x44/0x74)
      [ 2158.172978] [<c00601ac>] (tick_sched_timer+0x44/0x74) from [<c003f348>] (__run_hrtimer+0xc8/0x1b8)
      [ 2158.172992] [<c003f348>] (__run_hrtimer+0xc8/0x1b8) from [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4)
      [ 2158.173007] [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4) from [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30)
      [ 2158.173022] [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30) from [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124)
      [ 2158.173036] [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124) from [<c0082bd8>] (generic_handle_irq+0x20/0x30)
      [ 2158.173049] [<c0082bd8>] (generic_handle_irq+0x20/0x30) from [<c000969c>] (handle_IRQ+0x64/0x8c)
      [ 2158.173060] [<c000969c>] (handle_IRQ+0x64/0x8c) from [<c0008544>] (gic_handle_irq+0x3c/0x60)
      [ 2158.173074] [<c0008544>] (gic_handle_irq+0x3c/0x60) from [<c02f0f80>] (__irq_svc+0x40/0x50)
      [ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
      [ 2158.173092] 3c80:                                                       c4043ce4 00000019
      [ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
      [ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
      [ 2158.173130] [<c02f0f80>] (__irq_svc+0x40/0x50) from [<c0186cb8>] (read_current_timer+0x4/0x38)
      [ 2158.173145] [<c0186cb8>] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
      [ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
      [ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]
      Signed-off-by: default avatarWang Kai <morgan.wang@huawei.com>
      Signed-off-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f0958ab0
    • Vineet Gupta's avatar
      ARC: signal handling robustify · 4a5abf78
      Vineet Gupta authored
      commit e4140819 upstream.
      
      A malicious signal handler / restorer can DOS the system by fudging the
      user regs saved on stack, causing weird things such as sigreturn returning
      to user mode PC but cpu state still being kernel mode....
      
      Ensure that in sigreturn path status32 always has U bit; any other bogosity
      (gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.
      
      Reproducer signal handler:
      
          void handle_sig(int signo, siginfo_t *info, void *context)
          {
      	ucontext_t *uc = context;
      	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
      
      	regs->scratch.status32 = 0;
          }
      
      Before the fix, kernel would go off to weeds like below:
      
          --------->8-----------
          [ARCLinux]$ ./signal-test
          Path: /signal-test
          CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
          task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000
      
          [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
          [EFA   ]: 0x00000010
          [BLINK ]: 0x2007c1ee
          [ERET  ]: 0x10698
          [STAT32]: 0x00000000 :                                   <--------
          BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
          LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
          ...
          --------->8-----------
      Reported-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      [ luis: backported to 3.16: used Vineet's backport to 3.14 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4a5abf78
    • Matt Fleming's avatar
      x86/reboot: Add EFI reboot quirk for ACPI Hardware Reduced flag · 694b7f5f
      Matt Fleming authored
      commit 44be28e9 upstream.
      
      It appears that the BayTrail-T class of hardware requires EFI in order
      to powerdown and reboot and no other reliable method exists.
      
      This quirk is generally applicable to all hardware that has the ACPI
      Hardware Reduced bit set, since usually ACPI would be the preferred
      method.
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      [ luis: backported to 3.16:
        - move changes from quirks.c into efi.c
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      694b7f5f
    • Matt Fleming's avatar
      efi/reboot: Allow powering off machines using EFI · f6c2e46d
      Matt Fleming authored
      commit 0c5ed61a upstream.
      
      Not only can EfiResetSystem() be used to reboot, it can also be used to
      power down machines.
      
      By and large, this functionality doesn't work very well across the range
      of EFI machines in the wild, so it should definitely only be used as a
      last resort. In an ideal world, this wouldn't be needed at all.
      
      Unfortunately, we're starting to see machines where EFI is the *only*
      reliable way to power down, and nothing else, not PCI, not ACPI, works.
      
      efi_poweroff_required() should be implemented on a per-architecture
      basis, since exactly when we should be using EFI runtime services is a
      platform-specific decision. There's no analogue for reboot because each
      architecture handles reboot very differently - the x86 code in
      particular is pretty complex.
      
      Patches to enable this for specific classes of hardware will be
      submitted separately.
      Tested-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f6c2e46d
    • Matt Fleming's avatar
      efi/reboot: Add generic wrapper around EfiResetSystem() · c4bb687a
      Matt Fleming authored
      commit 8562c99c upstream.
      
      Implement efi_reboot(), which is really just a wrapper around the
      EfiResetSystem() EFI runtime service, but it does at least allow us to
      funnel all callers through a single location.
      
      It also simplifies the callsites since users no longer need to check to
      see whether EFI_RUNTIME_SERVICES are enabled.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Tested-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c4bb687a
    • Ido Shamay's avatar
      net/mlx4_en: Schedule napi when RX buffers allocation fails · ddef2b7f
      Ido Shamay authored
      commit 07841f9d upstream.
      
      When system is out of memory, refilling of RX buffers fails while
      the driver continue to pass the received packets to the kernel stack.
      At some point, when all RX buffers deplete, driver may fall into a
      sleep, and not recover when memory for new RX buffers is once again
      availible. This is because hardware does not have valid descriptors,
      so no interrupt will be generated for the driver to return to work
      in napi context. Fix it by schedule the napi poll function from
      stats_task delayed workqueue, as long as the allocations fail.
      Signed-off-by: default avatarIdo Shamay <idos@mellanox.com>
      Signed-off-by: default avatarAmir Vadai <amirv@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ddef2b7f
    • Benjamin Poirier's avatar
      mlx4: Fix tx ring affinity_mask creation · 0502c51a
      Benjamin Poirier authored
      commit 42eab005 upstream.
      
      By default, the number of tx queues is limited by the number of online cpus
      in mlx4_en_get_profile(). However, this limit no longer holds after the
      ethtool .set_channels method has been called. In that situation, the driver
      may access invalid bits of certain cpumask variables when queue_index >=
      nr_cpu_ids.
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.de>
      Acked-by: default avatarIdo Shamay <idos@mellanox.com>
      Fixes: d03a68f8 ("net/mlx4_en: Configure the XPS queue mapping on driver load")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0502c51a
    • Luis Henriques's avatar
      Linux 3.16.7-ckt11 · 56a11552
      Luis Henriques authored
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      56a11552
  2. 06 May, 2015 32 commits