1. 11 Aug, 2015 9 commits
  2. 10 Aug, 2015 31 commits
    • Sergei Shtylyov's avatar
      can: rcar_can: print signed IRQ # · e9193bf0
      Sergei Shtylyov authored
      commit c1a4c87b upstream.
      
      Printing IRQ # using "%x" and "%u" unsigned formats isn't quite correct as
      'ndev->irq' is of  type *int*, so  the "%d" format  needs to be used instead.
      
      While fixing this, beautify the dev_info() message in rcar_can_probe() a bit.
      
      Fixes: fd115931 ("can: add Renesas R-Car CAN driver")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e9193bf0
    • Florian Fainelli's avatar
      net: dsa: Fix off-by-one in switch address parsing · 0e1b541b
      Florian Fainelli authored
      commit c8cf89f7 upstream.
      
      cd->sw_addr is used as a MDIO bus address, which cannot exceed
      PHY_MAX_ADDR (32), our check was off-by-one.
      
      Fixes: 5e95329b ("dsa: add device tree bindings to register DSA switches")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0e1b541b
    • Florian Fainelli's avatar
      net: dsa: Test array index before use · a72eb546
      Florian Fainelli authored
      commit 8f5063e9 upstream.
      
      port_index is used an index into an array, and this information comes
      from Device Tree, make sure that port_index is not equal to the array
      size before using it. Move the check against port_index earlier in the
      loop.
      
      Fixes: 5e95329b: ("dsa: add device tree bindings to register DSA switches")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a72eb546
    • Julian Anastasov's avatar
      net: do not process device backlog during unregistration · 25516aec
      Julian Anastasov authored
      commit e9e4dd32 upstream.
      
      commit 381c759d ("ipv4: Avoid crashing in ip_error")
      fixes a problem where processed packet comes from device
      with destroyed inetdev (dev->ip_ptr). This is not expected
      because inetdev_destroy is called in NETDEV_UNREGISTER
      phase and packets should not be processed after
      dev_close_many() and synchronize_net(). Above fix is still
      required because inetdev_destroy can be called for other
      reasons. But it shows the real problem: backlog can keep
      packets for long time and they do not hold reference to
      device. Such packets are then delivered to upper levels
      at the same time when device is unregistered.
      Calling flush_backlog after NETDEV_UNREGISTER_FINAL still
      accounts all packets from backlog but before that some packets
      continue to be delivered to upper levels long after the
      synchronize_net call which is supposed to wait the last
      ones. Also, as Eric pointed out, processed packets, mostly
      from other devices, can continue to add new packets to backlog.
      
      Fix the problem by moving flush_backlog early, after the
      device driver is stopped and before the synchronize_net() call.
      Then use netif_running check to make sure we do not add more
      packets to backlog. We have to do it in enqueue_to_backlog
      context when the local IRQ is disabled. As result, after the
      flush_backlog and synchronize_net sequence all packets
      should be accounted.
      
      Thanks to Eric W. Biederman for the test script and his
      valuable feedback!
      Reported-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Fixes: 6e583ce5 ("net: eliminate refcounting in backlog queue")
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      25516aec
    • Nikolay Aleksandrov's avatar
      bridge: mdb: zero out the local br_ip variable before use · f07f6f98
      Nikolay Aleksandrov authored
      commit f1158b74 upstream.
      
      Since commit b0e9a30d ("bridge: Add vlan id to multicast groups")
      there's a check in br_ip_equal() for a matching vlan id, but the mdb
      functions were not modified to use (or at least zero it) so when an
      entry was added it would have a garbage vlan id (from the local br_ip
      variable in __br_mdb_add/del) and this would prevent it from being
      matched and also deleted. So zero out the whole local ip var to protect
      ourselves from future changes and also to fix the current bug, since
      there's no vlan id support in the mdb uapi - use always vlan id 0.
      Example before patch:
      root@debian:~# bridge mdb add dev br0 port eth1 grp 239.0.0.1 permanent
      root@debian:~# bridge mdb
      dev br0 port eth1 grp 239.0.0.1 permanent
      root@debian:~# bridge mdb del dev br0 port eth1 grp 239.0.0.1 permanent
      RTNETLINK answers: Invalid argument
      
      After patch:
      root@debian:~# bridge mdb add dev br0 port eth1 grp 239.0.0.1 permanent
      root@debian:~# bridge mdb
      dev br0 port eth1 grp 239.0.0.1 permanent
      root@debian:~# bridge mdb del dev br0 port eth1 grp 239.0.0.1 permanent
      root@debian:~# bridge mdb
      Signed-off-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Fixes: b0e9a30d ("bridge: Add vlan id to multicast groups")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f07f6f98
    • Timo Teräs's avatar
      ip_tunnel: fix ipv4 pmtu check to honor inner ip header df · f0663e5c
      Timo Teräs authored
      commit fc24f2b2 upstream.
      
      Frag needed should be sent only if the inner header asked
      to not fragment. Currently fragmentation is broken if the
      tunnel has df set, but df was not asked in the original
      packet. The tunnel's df needs to be still checked to update
      internally the pmtu cache.
      
      Commit 23a3647b broke it, and this commit fixes
      the ipv4 df check back to the way it was.
      
      Fixes: 23a3647b ("ip_tunnels: Use skb-len to PMTU check.")
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f0663e5c
    • Eric Dumazet's avatar
      net: graceful exit from netif_alloc_netdev_queues() · f02f07a4
      Eric Dumazet authored
      commit d339727c upstream.
      
      User space can crash kernel with
      
      ip link add ifb10 numtxqueues 100000 type ifb
      
      We must replace a BUG_ON() by proper test and return -EINVAL for
      crazy values.
      
      Fixes: 60877a32 ("net: allow large number of tx queues")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f02f07a4
    • Satish Ashok's avatar
      bridge: mdb: start delete timer for temp static entries · e64a0c1a
      Satish Ashok authored
      commit f7e2965d upstream.
      
      Start the delete timer when adding temp static entries so they can expire.
      Signed-off-by: default avatarSatish Ashok <sashok@cumulusnetworks.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Fixes: ccb1c31a ("bridge: add flags to distinguish permanent mdb entires")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e64a0c1a
    • Angga's avatar
      ipv6: Make MLD packets to only be processed locally · 1d2bb302
      Angga authored
      commit 4c938d22 upstream.
      
      Before commit daad1512 ("ipv6: Make ipv6_is_mld() inline and use it
      from ip6_mc_input().") MLD packets were only processed locally. After the
      change, a copy of MLD packet goes through ip6_mr_input, causing
      MRT6MSG_NOCACHE message to be generated to user space.
      
      Make MLD packet only processed locally.
      
      Fixes: daad1512 ("ipv6: Make ipv6_is_mld() inline and use it from ip6_mc_input().")
      Signed-off-by: default avatarHermin Anggawijaya <hermin.anggawijaya@alliedtelesis.co.nz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1d2bb302
    • Marek Szyprowski's avatar
      ARM: 8404/1: dma-mapping: fix off-by-one error in bitmap size check · 26f98b66
      Marek Szyprowski authored
      commit 462859aa upstream.
      
      nr_bitmaps member of mapping structure stores the number of already
      allocated bitmaps and it is interpreted as loop iterator (it starts from
      0 not from 1), so a comparison against number of possible bitmap
      extensions should include this fact. This patch fixes this by changing
      the extension failure condition. This issue has been introduced by
      commit 4d852ef8 ("arm: dma-mapping: Add
      support to extend DMA IOMMU mappings").
      Reported-by: default avatarHyungwon Hwang <human.hwang@samsung.com>
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarHyungwon Hwang <human.hwang@samsung.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      26f98b66
    • Andy Lutomirski's avatar
      x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection · 84b6f866
      Andy Lutomirski authored
      commit 810bc075 upstream.
      
      We have a tricky bug in the nested NMI code: if we see RSP
      pointing to the NMI stack on NMI entry from kernel mode, we
      assume that we are executing a nested NMI.
      
      This isn't quite true.  A malicious userspace program can point
      RSP at the NMI stack, issue SYSCALL, and arrange for an NMI to
      happen while RSP is still pointing at the NMI stack.
      
      Fix it with a sneaky trick.  Set DF in the region of code that
      the RSP check is intended to detect.  IRET will clear DF
      atomically.
      
      ( Note: other than paravirt, there's little need for all this
        complexity. We could check RIP instead of RSP. )
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 4.0: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      [ luis: backported to 3.16: Used Ben's backport to 4.0 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      84b6f866
    • Andy Lutomirski's avatar
      x86/nmi/64: Reorder nested NMI checks · 4e79de2a
      Andy Lutomirski authored
      commit a27507ca upstream.
      
      Check the repeat_nmi .. end_repeat_nmi special case first.  The
      next patch will rework the RSP check and, as a side effect, the
      RSP check will no longer detect repeat_nmi .. end_repeat_nmi, so
      we'll need this ordering of the checks.
      
      Note: this is more subtle than it appears.  The check for
      repeat_nmi .. end_repeat_nmi jumps straight out of the NMI code
      instead of adjusting the "iret" frame to force a repeat.  This
      is necessary, because the code between repeat_nmi and
      end_repeat_nmi sets "NMI executing" and then writes to the
      "iret" frame itself.  If a nested NMI comes in and modifies the
      "iret" frame while repeat_nmi is also modifying it, we'll end up
      with garbage.  The old code got this right, as does the new
      code, but the new code is a bit more explicit.
      
      If we were to move the check right after the "NMI executing"
      check, then we'd get it wrong and have random crashes.
      
      ( Because the "NMI executing" check would jump to the code that would
        modify the "iret" frame without checking if the interrupted NMI was
        currently modifying it. )
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 4.0: adjust filename, spacing]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      [ luis: backported to 3.16: Used Ben's backport to 4.0 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4e79de2a
    • Andy Lutomirski's avatar
      x86/nmi/64: Improve nested NMI comments · f79aba67
      Andy Lutomirski authored
      commit 0b22930e upstream.
      
      I found the nested NMI documentation to be difficult to follow.
      Improve the comments.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 4.0: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      [ luis: backported to 3.16: Used Ben's backport to 4.0 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f79aba67
    • Andy Lutomirski's avatar
      x86/nmi/64: Switch stacks on userspace NMI entry · 67b91ab3
      Andy Lutomirski authored
      commit 9b6e6a83 upstream.
      
      Returning to userspace is tricky: IRET can fail, and ESPFIX can
      rearrange the stack prior to IRET.
      
      The NMI nesting fixup relies on a precise stack layout and
      atomic IRET.  Rather than trying to teach the NMI nesting fixup
      to handle ESPFIX and failed IRET, punt: run NMIs that came from
      user mode on the normal kernel stack.
      
      This will make some nested NMIs visible to C code, but the C
      code is okay with that.
      
      As a side effect, this should speed up perf: it eliminates an
      RDMSR when NMIs come from user mode.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 4.0:
       - Adjust filename, context
       - s/restore_c_regs_and_iret/restore_args/
       - Use kernel_stack + KERNEL_STACK_OFFSET instead of cpu_current_top_of_stack]
      [luto: Open-coded return path to avoid dependency on partial pt_regs details]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      [ luis: backported to 3.16: used Ben and Andy backport to 4.0 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      67b91ab3
    • Andy Lutomirski's avatar
      x86/nmi/64: Remove asm code that saves CR2 · ac11aba3
      Andy Lutomirski authored
      commit 0e181bb5 upstream.
      
      Now that do_nmi saves CR2, we don't need to save it in asm.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 4.0: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      [ luis: backported to 3.16: used Ben's backport to 4.0 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ac11aba3
    • Andy Lutomirski's avatar
      x86/nmi: Enable nested do_nmi() handling for 64-bit kernels · 58e0d2a4
      Andy Lutomirski authored
      commit 9d050416 upstream.
      
      32-bit kernels handle nested NMIs in C.  Enable the exact same
      handling on 64-bit kernels as well.  This isn't currently
      necessary, but it will become necessary once the asm code starts
      allowing limited nesting.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      58e0d2a4
    • Denys Vlasenko's avatar
      x86/asm/entry/64: Remove a redundant jump · 7ca15f09
      Denys Vlasenko authored
      commit a30b0085 upstream.
      
      Jumping to the very next instruction is not very useful:
      
              jmp label
          label:
      
      Removing the jump.
      Signed-off-by: default avatarDenys Vlasenko <dvlasenk@redhat.com>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Drewry <wad@chromium.org>
      Link: http://lkml.kernel.org/r/1428439424-7258-5-git-send-email-dvlasenk@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7ca15f09
    • Denys Vlasenko's avatar
      x86/asm/entry/64: Fold the 'test_in_nmi' macro into its only user · 93148640
      Denys Vlasenko authored
      commit 0784b364 upstream.
      
      No code changes.
      Signed-off-by: default avatarDenys Vlasenko <dvlasenk@redhat.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Drewry <wad@chromium.org>
      Link: http://lkml.kernel.org/r/1427899858-7165-1-git-send-email-dvlasenk@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      93148640
    • Thomas Gleixner's avatar
      genirq: Prevent resend to interrupts marked IRQ_NESTED_THREAD · 605cb392
      Thomas Gleixner authored
      commit 75a06189 upstream.
      
      The resend mechanism happily calls the interrupt handler of interrupts
      which are marked IRQ_NESTED_THREAD from softirq context. This can
      result in crashes because the interrupt handler is not the proper way
      to invoke the device handlers. They must be invoked via
      handle_nested_irq.
      
      Prevent the resend even if the interrupt has no valid parent irq
      set. Its better to have a lost interrupt than a crashing machine.
      Reported-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      605cb392
    • Michel Dänzer's avatar
      drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL · fd6139cf
      Michel Dänzer authored
      commit 233709d2 upstream.
      
      This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
      or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
      flushes the TLB after setting rdev->gart.ptr to non-NULL.
      
      Fixes panic on powering off R7xx GPUs.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fd6139cf
    • Alex Deucher's avatar
    • Seymour, Shane M's avatar
      st: null pointer dereference panic caused by use after kref_put by st_open · e84ed278
      Seymour, Shane M authored
      commit e7ac6c66 upstream.
      
      Two SLES11 SP3 servers encountered similar crashes simultaneously
      following some kind of SAN/tape target issue:
      
      ...
      qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
      qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
      qla2xxx [0000:81:00.0]-8009:3: DEVICE RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
      qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
      qla2xxx [0000:81:00.0]-800f:3: DEVICE RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
      qla2xxx [0000:81:00.0]-8009:3: TARGET RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
      qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
      qla2xxx [0000:81:00.0]-800f:3: TARGET RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
      qla2xxx [0000:81:00.0]-8012:3: BUS RESET ISSUED nexus=3:0:2.
      qla2xxx [0000:81:00.0]-802b:3: BUS RESET SUCCEEDED nexus=3:0:2.
      qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
      qla2xxx [0000:81:00.0]-8018:3: ADAPTER RESET ISSUED nexus=3:0:2.
      qla2xxx [0000:81:00.0]-00af:3: Performing ISP error recovery - ha=ffff88bf04d18000.
       rport-3:0-0: blocked FC remote port time out: removing target and saving binding
      qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
      qla2xxx [0000:81:00.0]-8017:3: ADAPTER RESET SUCCEEDED nexus=3:0:2.
       rport-2:0-0: blocked FC remote port time out: removing target and saving binding
      sg_rq_end_io: device detached
      BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8
      IP: [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
      PGD 7e6586f067 PUD 7e5af06067 PMD 0 [1739975.390354] Oops: 0002 [#1] SMP
      CPU 0
      ...
      Supported: No, Proprietary modules are loaded [1739975.390463]
      Pid: 27965, comm: ABCD Tainted: PF           X 3.0.101-0.29-default #1 HP ProLiant DL580 Gen8
      RIP: 0010:[<ffffffff8133b268>]  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
      RSP: 0018:ffff8839dc1e7c68  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffff883f0592fc00 RCX: 0000000000000090
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000138
      RBP: 0000000000000138 R08: 0000000000000010 R09: ffffffff81bd39d0
      R10: 00000000000009c0 R11: ffffffff81025790 R12: 0000000000000001
      R13: ffff883022212b80 R14: 0000000000000004 R15: ffff883022212b80
      FS:  00007f8e54560720(0000) GS:ffff88407f800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00000000000002a8 CR3: 0000007e6ced6000 CR4: 00000000001407f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process ABCD (pid: 27965, threadinfo ffff8839dc1e6000, task ffff883592e0c640)
      Stack:
       ffff883f0592fc00 00000000fffffffa 0000000000000001 ffff883022212b80
       ffff883eff772400 ffffffffa03fa309 0000000000000000 0000000000000000
       ffffffffa04003a0 ffff883f063196c0 ffff887f0379a930 ffffffff8115ea1e
      Call Trace:
       [<ffffffffa03fa309>] st_open+0x129/0x240 [st]
       [<ffffffff8115ea1e>] chrdev_open+0x13e/0x200
       [<ffffffff811588a8>] __dentry_open+0x198/0x310
       [<ffffffff81167d74>] do_last+0x1f4/0x800
       [<ffffffff81168fe9>] path_openat+0xd9/0x420
       [<ffffffff8116946c>] do_filp_open+0x4c/0xc0
       [<ffffffff8115a00f>] do_sys_open+0x17f/0x250
       [<ffffffff81468d92>] system_call_fastpath+0x16/0x1b
       [<00007f8e4f617fd0>] 0x7f8e4f617fcf
      Code: eb d3 90 48 83 ec 28 40 f6 c6 04 48 89 6c 24 08 4c 89 74 24 20 48 89 fd 48 89 1c 24 4c 89 64 24 10 41 89 f6 4c 89 6c 24 18 74 11 <f0> ff 8f 70 01 00 00 0f 94 c0 45 31 ed 84 c0 74 2b 4c 8d a5 a0
      RIP  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
       RSP <ffff8839dc1e7c68>
      CR2: 00000000000002a8
      
      Analysis reveals the cause of the crash to be due to STp->device
      being NULL. The pointer was NULLed via scsi_tape_put(STp) when it
      calls scsi_tape_release(). In st_open() we jump to err_out after
      scsi_block_when_processing_errors() completes and returns the
      device as offline (sdev_state was SDEV_DEL):
      
      1180 /* Open the device. Needs to take the BKL only because of incrementing the SCSI host
      1181    module count. */
      1182 static int st_open(struct inode *inode, struct file *filp)
      1183 {
      1184         int i, retval = (-EIO);
      1185         int resumed = 0;
      1186         struct scsi_tape *STp;
      1187         struct st_partstat *STps;
      1188         int dev = TAPE_NR(inode);
      1189         char *name;
      ...
      1217         if (scsi_autopm_get_device(STp->device) < 0) {
      1218                 retval = -EIO;
      1219                 goto err_out;
      1220         }
      1221         resumed = 1;
      1222         if (!scsi_block_when_processing_errors(STp->device)) {
      1223                 retval = (-ENXIO);
      1224                 goto err_out;
      1225         }
      ...
      1264  err_out:
      1265         normalize_buffer(STp->buffer);
      1266         spin_lock(&st_use_lock);
      1267         STp->in_use = 0;
      1268         spin_unlock(&st_use_lock);
      1269         scsi_tape_put(STp); <-- STp->device = 0 after this
      1270         if (resumed)
      1271                 scsi_autopm_put_device(STp->device);
      1272         return retval;
      
      The ref count for the struct scsi_tape had already been reduced
      to 1 when the .remove method of the st module had been called.
      The kref_put() in scsi_tape_put() caused scsi_tape_release()
      to be called:
      
      0266 static void scsi_tape_put(struct scsi_tape *STp)
      0267 {
      0268         struct scsi_device *sdev = STp->device;
      0269
      0270         mutex_lock(&st_ref_mutex);
      0271         kref_put(&STp->kref, scsi_tape_release); <-- calls this
      0272         scsi_device_put(sdev);
      0273         mutex_unlock(&st_ref_mutex);
      0274 }
      
      In scsi_tape_release() the struct scsi_device in the struct
      scsi_tape gets set to NULL:
      
      4273 static void scsi_tape_release(struct kref *kref)
      4274 {
      4275         struct scsi_tape *tpnt = to_scsi_tape(kref);
      4276         struct gendisk *disk = tpnt->disk;
      4277
      4278         tpnt->device = NULL; <<<---- where the dev is nulled
      4279
      4280         if (tpnt->buffer) {
      4281                 normalize_buffer(tpnt->buffer);
      4282                 kfree(tpnt->buffer->reserved_pages);
      4283                 kfree(tpnt->buffer);
      4284         }
      4285
      4286         disk->private_data = NULL;
      4287         put_disk(disk);
      4288         kfree(tpnt);
      4289         return;
      4290 }
      
      Although the problem was reported on SLES11.3 the problem appears
      in linux-next as well.
      
      The crash is fixed by reordering the code so we no longer access
      the struct scsi_tape after the kref_put() is done on it in st_open().
      Signed-off-by: default avatarShane Seymour <shane.seymour@hp.com>
      Signed-off-by: default avatarDarren Lavender <darren.lavender@hp.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.com>
      Acked-by: default avatarKai Mäkisara <kai.makisara@kolumbus.fi>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e84ed278
    • Filipe Manana's avatar
      Btrfs: fix file corruption after cloning inline extents · b027d6ba
      Filipe Manana authored
      commit ed958762 upstream.
      
      Using the clone ioctl (or extent_same ioctl, which calls the same extent
      cloning function as well) we end up allowing copy an inline extent from
      the source file into a non-zero offset of the destination file. This is
      something not expected and that the btrfs code is not prepared to deal
      with - all inline extents must be at a file offset equals to 0.
      
      For example, the following excerpt of a test case for fstests triggers
      a crash/BUG_ON() on a write operation after an inline extent is cloned
      into a non-zero offset:
      
        _scratch_mkfs >>$seqres.full 2>&1
        _scratch_mount
      
        # Create our test files. File foo has the same 2K of data at offset 4K
        # as file bar has at its offset 0.
        $XFS_IO_PROG -f -s -c "pwrite -S 0xaa 0 4K" \
            -c "pwrite -S 0xbb 4k 2K" \
            -c "pwrite -S 0xcc 8K 4K" \
            $SCRATCH_MNT/foo | _filter_xfs_io
      
        # File bar consists of a single inline extent (2K size).
        $XFS_IO_PROG -f -s -c "pwrite -S 0xbb 0 2K" \
           $SCRATCH_MNT/bar | _filter_xfs_io
      
        # Now call the clone ioctl to clone the extent of file bar into file
        # foo at its offset 4K. This made file foo have an inline extent at
        # offset 4K, something which the btrfs code can not deal with in future
        # IO operations because all inline extents are supposed to start at an
        # offset of 0, resulting in all sorts of chaos.
        # So here we validate that clone ioctl returns an EOPNOTSUPP, which is
        # what it returns for other cases dealing with inlined extents.
        $CLONER_PROG -s 0 -d $((4 * 1024)) -l $((2 * 1024)) \
            $SCRATCH_MNT/bar $SCRATCH_MNT/foo
      
        # Because of the inline extent at offset 4K, the following write made
        # the kernel crash with a BUG_ON().
        $XFS_IO_PROG -c "pwrite -S 0xdd 6K 2K" $SCRATCH_MNT/foo | _filter_xfs_io
      
        status=0
        exit
      
      The stack trace of the BUG_ON() triggered by the last write is:
      
        [152154.035903] ------------[ cut here ]------------
        [152154.036424] kernel BUG at mm/page-writeback.c:2286!
        [152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
        [152154.036424] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop fuse parport_pc acpi_cpu$
        [152154.036424] CPU: 2 PID: 17873 Comm: xfs_io Tainted: G        W       4.1.0-rc6-btrfs-next-11+ #2
        [152154.036424] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
        [152154.036424] task: ffff880429f70990 ti: ffff880429efc000 task.ti: ffff880429efc000
        [152154.036424] RIP: 0010:[<ffffffff8111a9d5>]  [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
        [152154.036424] RSP: 0018:ffff880429effc68  EFLAGS: 00010246
        [152154.036424] RAX: 0200000000000806 RBX: ffffea0006a6d8f0 RCX: 0000000000000001
        [152154.036424] RDX: 0000000000000000 RSI: ffffffff81155d1b RDI: ffffea0006a6d8f0
        [152154.036424] RBP: ffff880429effc78 R08: ffff8801ce389fe0 R09: 0000000000000001
        [152154.036424] R10: 0000000000002000 R11: ffffffffffffffff R12: ffff8800200dce68
        [152154.036424] R13: 0000000000000000 R14: ffff8800200dcc88 R15: ffff8803d5736d80
        [152154.036424] FS:  00007fbf119f6700(0000) GS:ffff88043d280000(0000) knlGS:0000000000000000
        [152154.036424] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [152154.036424] CR2: 0000000001bdc000 CR3: 00000003aa555000 CR4: 00000000000006e0
        [152154.036424] Stack:
        [152154.036424]  ffff8803d5736d80 0000000000000001 ffff880429effcd8 ffffffffa04e97c1
        [152154.036424]  ffff880429effd68 ffff880429effd60 0000000000000001 ffff8800200dc9c8
        [152154.036424]  0000000000000001 ffff8800200dcc88 0000000000000000 0000000000001000
        [152154.036424] Call Trace:
        [152154.036424]  [<ffffffffa04e97c1>] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs]
        [152154.036424]  [<ffffffffa04ea82c>] __btrfs_buffered_write+0x245/0x4c8 [btrfs]
        [152154.036424]  [<ffffffffa04ed14b>] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs]
        [152154.036424]  [<ffffffffa04ed15a>] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs]
        [152154.036424]  [<ffffffffa04ed2c7>] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs]
        [152154.036424]  [<ffffffff81165a4a>] __vfs_write+0x7c/0xa5
        [152154.036424]  [<ffffffff81165f89>] vfs_write+0xa0/0xe4
        [152154.036424]  [<ffffffff81166855>] SyS_pwrite64+0x64/0x82
        [152154.036424]  [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
        [152154.036424] Code: 48 89 c7 e8 0f ff ff ff 5b 41 5c 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 ae ef 00 00 49 89 c4 48 8b 03 a8 01 75 02 <0f> 0b 4d 85 e4 74 59 49 8b 3c 2$
        [152154.036424] RIP  [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
        [152154.036424]  RSP <ffff880429effc68>
        [152154.242621] ---[ end trace e3d3376b23a57041 ]---
      
      Fix this by returning the error EOPNOTSUPP if an attempt to copy an
      inline extent into a non-zero offset happens, just like what is done for
      other scenarios that would require copying/splitting inline extents,
      which were introduced by the following commits:
      
         00fdf13a ("Btrfs: fix a crash of clone with inline extents's split")
         3f9e3df8 ("btrfs: replace error code from btrfs_drop_extents")
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b027d6ba
    • Alexey Brodkin's avatar
      ARC: make sure instruction_pointer() returns unsigned value · c7bc7995
      Alexey Brodkin authored
      commit f51e2f19 upstream.
      
      Currently instruction_pointer() returns pt_regs->ret and so return value
      is of type "long", which implicitly stands for "signed long".
      
      While that's perfectly fine when dealing with 32-bit values if return
      value of instruction_pointer() gets assigned to 64-bit variable sign
      extension may happen.
      
      And at least in one real use-case it happens already.
      In perf_prepare_sample() return value of perf_instruction_pointer()
      (which is an alias to instruction_pointer() in case of ARC) is assigned
      to (struct perf_sample_data)->ip (which type is "u64").
      
      And what we see if instuction pointer points to user-space application
      that in case of ARC lays below 0x8000_0000 "ip" gets set properly with
      leading 32 zeros. But if instruction pointer points to kernel address
      space that starts from 0x8000_0000 then "ip" is set with 32 leadig
      "f"-s. I.e. id instruction_pointer() returns 0x8100_0000, "ip" will be
      assigned with 0xffff_ffff__8100_0000. Which is obviously wrong.
      
      In particular that issuse broke output of perf, because perf was unable
      to associate addresses like 0xffff_ffff__8100_0000 with anything from
      /proc/kallsyms.
      
      That's what we used to see:
       ----------->8----------
        6.27%  ls       [unknown]                [k] 0xffffffff8046c5cc
        2.96%  ls       libuClibc-0.9.34-git.so  [.] memcpy
        2.25%  ls       libuClibc-0.9.34-git.so  [.] memset
        1.66%  ls       [unknown]                [k] 0xffffffff80666536
        1.54%  ls       libuClibc-0.9.34-git.so  [.] 0x000224d6
        1.18%  ls       libuClibc-0.9.34-git.so  [.] 0x00022472
       ----------->8----------
      
      With that change perf output looks much better now:
       ----------->8----------
        8.21%  ls       [kernel.kallsyms]        [k] memset
        3.52%  ls       libuClibc-0.9.34-git.so  [.] memcpy
        2.11%  ls       libuClibc-0.9.34-git.so  [.] malloc
        1.88%  ls       libuClibc-0.9.34-git.so  [.] memset
        1.64%  ls       [kernel.kallsyms]        [k] _raw_spin_unlock_irqrestore
        1.41%  ls       [kernel.kallsyms]        [k] __d_lookup_rcu
       ----------->8----------
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: arc-linux-dev@synopsys.com
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c7bc7995
    • Sergei Shtylyov's avatar
      can: rcar_can: fix IRQ check · dfe8266d
      Sergei Shtylyov authored
      commit 5e63e6ba upstream.
      
      rcar_can_probe() regards 0 as a wrong IRQ #, despite platform_get_irq() that it
      calls returns negative error code in that case. This leads to the following
      being printed to the console when attempting to open the device:
      
      error requesting interrupt fffffffa
      
      because  rcar_can_open() calls request_irq() with a negative IRQ #, and that
      function naturally fails with -EINVAL.
      
      Check for the negative error codes instead and propagate them upstream instead
      of just returning -ENODEV.
      
      Fixes: fd115931 ("can: add Renesas R-Car CAN driver")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dfe8266d
    • Filipe Manana's avatar
      Btrfs: fix list transaction->pending_ordered corruption · 16da885e
      Filipe Manana authored
      commit d3efe084 upstream.
      
      When we call btrfs_commit_transaction(), we splice the list "ordered"
      of our transaction handle into the transaction's "pending_ordered"
      list, but we don't re-initialize the "ordered" list of our transaction
      handle, this means it still points to the same elements it used to
      before the splice. Then we check if the current transaction's state is
      >= TRANS_STATE_COMMIT_START and if it is we end up calling
      btrfs_end_transaction() which simply splices again the "ordered" list
      of our handle into the transaction's "pending_ordered" list, leaving
      multiple pointers to the same ordered extents which results in list
      corruption when we are iterating, removing and freeing ordered extents
      at btrfs_wait_pending_ordered(), resulting in access to dangling
      pointers / use-after-free issues.
      Similarly, btrfs_end_transaction() can end up in some cases calling
      btrfs_commit_transaction(), and both did a list splice of the transaction
      handle's "ordered" list into the transaction's "pending_ordered" without
      re-initializing the handle's "ordered" list, resulting in exactly the
      same problem.
      
      This produces the following warning on a kernel with linked list
      debugging enabled:
      
      [109749.265416] ------------[ cut here ]------------
      [109749.266410] WARNING: CPU: 7 PID: 324 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98()
      [109749.267969] list_del corruption. prev->next should be ffff8800ba087e20, but was fffffff8c1f7c35d
      (...)
      [109749.287505] Call Trace:
      [109749.288135]  [<ffffffff8145f077>] dump_stack+0x4f/0x7b
      [109749.298080]  [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
      [109749.331605]  [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
      [109749.334849]  [<ffffffff81260642>] ? __list_del_entry+0x5a/0x98
      [109749.337093]  [<ffffffff8104b410>] warn_slowpath_fmt+0x46/0x48
      [109749.337847]  [<ffffffff81260642>] __list_del_entry+0x5a/0x98
      [109749.338678]  [<ffffffffa053e8bf>] btrfs_wait_pending_ordered+0x46/0xdb [btrfs]
      [109749.340145]  [<ffffffffa058a65f>] ? __btrfs_run_delayed_items+0x149/0x163 [btrfs]
      [109749.348313]  [<ffffffffa054077d>] btrfs_commit_transaction+0x36b/0xa10 [btrfs]
      [109749.349745]  [<ffffffff81087310>] ? trace_hardirqs_on+0xd/0xf
      [109749.350819]  [<ffffffffa055370d>] btrfs_sync_file+0x36f/0x3fc [btrfs]
      [109749.351976]  [<ffffffff8118ec98>] vfs_fsync_range+0x8f/0x9e
      [109749.360341]  [<ffffffff8118ecc3>] vfs_fsync+0x1c/0x1e
      [109749.368828]  [<ffffffff8118ee1d>] do_fsync+0x34/0x4e
      [109749.369790]  [<ffffffff8118f045>] SyS_fsync+0x10/0x14
      [109749.370925]  [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
      [109749.382274] ---[ end trace 48e0d07f7c03d95a ]---
      
      On a non-debug kernel this leads to invalid memory accesses, causing a
      crash. Fix this by using list_splice_init() instead of list_splice() in
      btrfs_commit_transaction() and btrfs_end_transaction().
      
      Fixes: 50d9aa99 ("Btrfs: make sure logged extents complete in the current transaction V3"
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      16da885e
    • Filipe Manana's avatar
      Btrfs: fix memory leak in the extent_same ioctl · b5ada126
      Filipe Manana authored
      commit 497b4050 upstream.
      
      We were allocating memory with memdup_user() but we were never releasing
      that memory. This affected pretty much every call to the ioctl, whether
      it deduplicated extents or not.
      
      This issue was reported on IRC by Julian Taylor and on the mailing list
      by Marcel Ritter, credit goes to them for finding the issue.
      Reported-by: default avatarJulian Taylor <jtaylor.debian@googlemail.com>
      Reported-by: default avatarMarcel Ritter <ritter.marcel@gmail.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarMark Fasheh <mfasheh@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b5ada126
    • Johannes Thumshirn's avatar
      USB: serial: Destroy serial_minors IDR on module exit · 063fd5d5
      Johannes Thumshirn authored
      commit d23f47d4 upstream.
      
      Destroy serial_minors IDR on module exit, reclaiming the allocated memory.
      
      This was detected by the following semantic patch (written by Luis
      Rodriguez <mcgrof@suse.com>)
      
      <SmPL>
      @ defines_module_init @
      declarer name module_init, module_exit;
      declarer name DEFINE_IDR;
      identifier init;
      @@
      
      module_init(init);
      
      @ defines_module_exit @
      identifier exit;
      @@
      
      module_exit(exit);
      
      @ declares_idr depends on defines_module_init && defines_module_exit @
      identifier idr;
      @@
      
      DEFINE_IDR(idr);
      
      @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       idr_destroy(&idr);
       ...
      }
      
      @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       +idr_destroy(&idr);
      }
      </SmPL>
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      063fd5d5
    • Mugunthan V N's avatar
      drivers: net: cpsw: fix crash while accessing second slave ethernet interface · d5ecf017
      Mugunthan V N authored
      commit 1973db0d upstream.
      
      When cpsw's number of slave is set to 1 in device tree and while
      accessing second slave ndev and priv in cpsw_tx_interrupt(),
      there is a kernel crash. This is due to cpsw_get_slave_priv()
      not verifying number of slaves while retriving netdev priv and
      returns a invalid memory region. Fixing the issue by introducing
      number of slave check in cpsw_get_slave_priv() and
      cpsw_get_slave_ndev().
      
      [   15.879589] Unable to handle kernel paging request at virtual address 0f0e142c
      [   15.888540] pgd = ed374000
      [   15.891359] [0f0e142c] *pgd=00000000
      [   15.895105] Internal error: Oops: 5 [#1] SMP ARM
      [   15.899936] Modules linked in:
      [   15.903139] CPU: 0 PID: 593 Comm: udhcpc Tainted: G        W       4.1.0-12205-gfda8b18c-dirty #10
      [   15.912386] Hardware name: Generic AM43 (Flattened Device Tree)
      [   15.918557] task: ed2a2e00 ti: ed3fe000 task.ti: ed3fe000
      [   15.924187] PC is at cpsw_tx_interrupt+0x30/0x44
      [   15.929008] LR is at _raw_spin_unlock_irqrestore+0x40/0x44
      [   15.934726] pc : [<c048b9cc>]    lr : [<c05ef4f4>]    psr: 20000193
      [   15.934726] sp : ed3ffc08  ip : ed2a2e40  fp : 00000000
      [   15.946685] r10: c0969ce8  r9 : c0969cfc  r8 : 00000000
      [   15.952129] r7 : 000000c6  r6 : ee54ab00  r5 : ee169c64  r4 : ee534e00
      [   15.958932] r3 : 0f0e0d0c  r2 : 00000000  r1 : ed3ffbc0  r0 : 00000001
      [   15.965735] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [   15.973261] Control: 10c5387d  Table: ad374059  DAC: 00000015
      [   15.979246] Process udhcpc (pid: 593, stack limit = 0xed3fe218)
      [   15.985414] Stack: (0xed3ffc08 to 0xed400000)
      [   15.989954] fc00:                   ee54ab00 c009928c c0a9e648 60000193 000032e4 ee169c00
      [   15.998478] fc20: ee169c64 ee169c00 ee169c64 ee54ab00 00000001 00000001 ee67e268 ee008800
      [   16.006995] fc40: ee534800 c009946c ee169c00 ee169c64 c08bd660 c009c370 c009c2a4 000000c6
      [   16.015513] fc60: c08b75c4 c08b0854 00000000 c0098b3c 000000c6 c0098c50 ed3ffcb0 0000003a
      [   16.024033] fc80: ed3ffcb0 fa24010c c08b7800 fa240100 ee7e9880 c00094c4 c05ef4e8 60000013
      [   16.032556] fca0: ffffffff ed3ffce4 ee7e9880 c05ef964 00000001 ed2a33d8 00000000 ed2a2e00
      [   16.041080] fcc0: 60000013 ee536bf8 60000013 ee51b800 ee7e9880 ee67e268 ee7e9880 ee534800
      [   16.049603] fce0: c0ad0768 ed3ffcf8 c008e910 c05ef4e8 60000013 ffffffff 00000001 00000001
      [   16.058121] fd00: ee536bf8 c0487a04 00000000 00000000 ee534800 00000000 00000156 c048c990
      [   16.066645] fd20: 00000000 00000000 c0969f40 00000000 00000000 c05000e8 00000001 00000000
      [   16.075167] fd40: 00000000 c051eefc 00000000 ee67e268 00000000 00000000 ee51b800 ed3ffd9c
      [   16.083690] fd60: 00000000 ee67e200 ee51b800 ee7e9880 ee67e268 00000000 00000000 ee67e200
      [   16.092211] fd80: ee51b800 ee7e9880 ee67e268 ee534800 ee67e200 c051eedc ee67e268 00000010
      [   16.100727] fda0: 00000000 00000000 ee7e9880 ee534800 00000000 ee67e268 ee51b800 c05006fc
      [   16.109247] fdc0: ee67e268 00000001 c0500488 00000156 ee7e9880 00000000 ed3fe000 fffffff4
      [   16.117771] fde0: ed3fff1c ee7e9880 ee534800 00000148 00000000 ed1f8340 00000000 00000000
      [   16.126289] fe00: 00000000 c05a9054 00000000 00000000 00000156 c0ab62a8 00000010 ed3e7000
      [   16.134812] fe20: 00000000 00000008 edcfb700 ed3fff1c c0fb5f94 ed2a2e00 c0fb5f64 000005d8
      [   16.143336] fe40: c0a9b3b8 00000000 ed3e7070 00000000 00000000 00000000 00009f40 00000000
      [   16.151858] fe60: 00000000 00020022 00110008 00000000 00000000 43004400 00000000 ffffffff
      [   16.160374] fe80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [   16.168898] fea0: edcfb700 bee5f380 00000014 00000000 ed3fe000 00000000 00004400 c04e2b64
      [   16.177415] fec0: 00000002 c04e3b00 ed3ffeec 00000001 0000011a 00000000 00000000 bee5f394
      [   16.185937] fee0: 00000148 ed3fff10 00000014 00000001 00000000 00000000 ed3ffee4 00000000
      [   16.194459] ff00: 00000000 00000000 00000000 c04e3664 00080011 00000002 06000000 ffffffff
      [   16.202980] ff20: 0000ffff ffffffff 0000ffff c008dd54 ee5a6f08 ee636e80 c096972d c0089c14
      [   16.211499] ff40: 00000000 60000013 ee5a6f40 60000013 00000000 ee5a6f40 00000002 00000006
      [   16.220023] ff60: 00000000 edcfb700 00000001 ed2a2e00 c000f60c 00000001 0000011a c008ea34
      [   16.228540] ff80: 00000006 00000000 bee5f380 00000014 bee5f380 00000014 bee5f380 00000122
      [   16.237059] ffa0: c000f7c4 c000f5e0 bee5f380 00000014 00000006 bee5f394 00000148 00000000
      [   16.245581] ffc0: bee5f380 00000014 bee5f380 00000122 fffffd6e 00004300 00004800 00004400
      [   16.254104] ffe0: bee5f378 bee5f36c 000307ec b6f39044 40000010 00000006 ed36fa40 00000000
      [   16.262642] [<c048b9cc>] (cpsw_tx_interrupt) from [<c009928c>] (handle_irq_event_percpu+0x64/0x204)
      [   16.272076] [<c009928c>] (handle_irq_event_percpu) from [<c009946c>] (handle_irq_event+0x40/0x64)
      [   16.281330] [<c009946c>] (handle_irq_event) from [<c009c370>] (handle_fasteoi_irq+0xcc/0x1a8)
      [   16.290220] [<c009c370>] (handle_fasteoi_irq) from [<c0098b3c>] (generic_handle_irq+0x20/0x30)
      [   16.299197] [<c0098b3c>] (generic_handle_irq) from [<c0098c50>] (__handle_domain_irq+0x64/0xdc)
      [   16.308273] [<c0098c50>] (__handle_domain_irq) from [<c00094c4>] (gic_handle_irq+0x20/0x60)
      [   16.316987] [<c00094c4>] (gic_handle_irq) from [<c05ef964>] (__irq_svc+0x44/0x5c)
      [   16.324779] Exception stack(0xed3ffcb0 to 0xed3ffcf8)
      [   16.330044] fca0:                                     00000001 ed2a33d8 00000000 ed2a2e00
      [   16.338567] fcc0: 60000013 ee536bf8 60000013 ee51b800 ee7e9880 ee67e268 ee7e9880 ee534800
      [   16.347090] fce0: c0ad0768 ed3ffcf8 c008e910 c05ef4e8 60000013 ffffffff
      [   16.353987] [<c05ef964>] (__irq_svc) from [<c05ef4e8>] (_raw_spin_unlock_irqrestore+0x34/0x44)
      [   16.362973] [<c05ef4e8>] (_raw_spin_unlock_irqrestore) from [<c0487a04>] (cpdma_check_free_tx_desc+0x60/0x6c)
      [   16.373311] [<c0487a04>] (cpdma_check_free_tx_desc) from [<c048c990>] (cpsw_ndo_start_xmit+0xb4/0x1ac)
      [   16.383017] [<c048c990>] (cpsw_ndo_start_xmit) from [<c05000e8>] (dev_hard_start_xmit+0x2a4/0x4c0)
      [   16.392364] [<c05000e8>] (dev_hard_start_xmit) from [<c051eedc>] (sch_direct_xmit+0xf4/0x210)
      [   16.401246] [<c051eedc>] (sch_direct_xmit) from [<c05006fc>] (__dev_queue_xmit+0x2ac/0x7bc)
      [   16.409960] [<c05006fc>] (__dev_queue_xmit) from [<c05a9054>] (packet_sendmsg+0xc68/0xeb4)
      [   16.418585] [<c05a9054>] (packet_sendmsg) from [<c04e2b64>] (sock_sendmsg+0x14/0x24)
      [   16.426663] [<c04e2b64>] (sock_sendmsg) from [<c04e3b00>] (SyS_sendto+0xb4/0xe0)
      [   16.434377] [<c04e3b00>] (SyS_sendto) from [<c000f5e0>] (ret_fast_syscall+0x0/0x54)
      [   16.442360] Code: e5943118 e593303c e3530000 0a000002 (e5930720)
      [   16.448716] ---[ end trace a68159f094d85ba6 ]---
      [   16.453526] Kernel panic - not syncing: Fatal exception in interrupt
      [   16.460149] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d5ecf017
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Have branch tracer use recursive field of task struct · 1f827fd5
      Steven Rostedt (Red Hat) authored
      commit 6224beb1 upstream.
      
      Fengguang Wu's tests triggered a bug in the branch tracer's start up
      test when CONFIG_DEBUG_PREEMPT set. This was because that config
      adds some debug logic in the per cpu field, which calls back into
      the branch tracer.
      
      The branch tracer has its own recursive checks, but uses a per cpu
      variable to implement it. If retrieving the per cpu variable calls
      back into the branch tracer, you can see how things will break.
      
      Instead of using a per cpu variable, use the trace_recursion field
      of the current task struct. Simply set a bit when entering the
      branch tracing and clear it when leaving. If the bit is set on
      entry, just don't do the tracing.
      
      There's also the case with lockdep, as the local_irq_save() called
      before the recursion can also trigger code that can call back into
      the function. Changing that to a raw_local_irq_save() will protect
      that as well.
      
      This prevents the recursion and the inevitable crash that follows.
      
      Link: http://lkml.kernel.org/r/20150630141803.GA28071@wfg-t540p.sh.intel.comReported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1f827fd5
    • Stefan Wahren's avatar
      ARM: dts: mx23: fix iio-hwmon support · d2e50432
      Stefan Wahren authored
      commit e8e94ed6 upstream.
      
      In order to get iio-hwmon support, the lradc must be declared as an
      iio provider. So fix this issue by adding the #io-channel-cells property.
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Fixes: bd798f9c ("ARM: dts: mxs: Add iio-hwmon to mx23 soc")
      Reviewed-by: default avatarMarek Vasut <marex@denx.de>
      Reviewed-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d2e50432