1. 10 Aug, 2015 40 commits
    • 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
    • Mike Snitzer's avatar
      bio integrity: do not assume bio_integrity_pool exists if bioset exists · 050b6b27
      Mike Snitzer authored
      commit bb8bd38b upstream.
      
      bio_integrity_alloc() and bio_integrity_free() assume that if a bio was
      allocated from a bioset that that bioset also had its bio_integrity_pool
      allocated using bioset_integrity_create().  This is a very bad
      assumption given that bioset_create() and bioset_integrity_create() are
      completely disjoint.  Not all callers of bioset_create() have been
      trained to also call bioset_integrity_create() -- and they may not care
      to be.
      
      Fix this by falling back to kmalloc'ing 'struct bio_integrity_payload'
      rather than force all bioset consumers to (wastefully) preallocate a
      bio_integrity_pool that they very likely won't actually need (given the
      niche nature of the current block integrity support).
      
      Otherwise, a NULL pointer "Kernel BUG" with a trace like the following
      will be observed (as seen on s390x using zfcp storage) because dm-io
      doesn't use bioset_integrity_create() when creating its bioset:
      
          [  791.643338] Call Trace:
          [  791.643339] ([<00000003df98b848>] 0x3df98b848)
          [  791.643341]  [<00000000002c5de8>] bio_integrity_alloc+0x48/0xf8
          [  791.643348]  [<00000000002c6486>] bio_integrity_prep+0xae/0x2f0
          [  791.643349]  [<0000000000371e38>] blk_queue_bio+0x1c8/0x3d8
          [  791.643355]  [<000000000036f8d0>] generic_make_request+0xc0/0x100
          [  791.643357]  [<000000000036f9b2>] submit_bio+0xa2/0x198
          [  791.643406]  [<000003ff801f9774>] dispatch_io+0x15c/0x3b0 [dm_mod]
          [  791.643419]  [<000003ff801f9b3e>] dm_io+0x176/0x2f0 [dm_mod]
          [  791.643423]  [<000003ff8074b28a>] do_reads+0x13a/0x1a8 [dm_mirror]
          [  791.643425]  [<000003ff8074b43a>] do_mirror+0x142/0x298 [dm_mirror]
          [  791.643428]  [<0000000000154fca>] process_one_work+0x18a/0x3f8
          [  791.643432]  [<000000000015598a>] worker_thread+0x132/0x3b0
          [  791.643435]  [<000000000015d49a>] kthread+0xd2/0xd8
          [  791.643438]  [<00000000005bc0ca>] kernel_thread_starter+0x6/0xc
          [  791.643446]  [<00000000005bc0c4>] kernel_thread_starter+0x0/0xc
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      050b6b27
    • Zhao Junwang's avatar
      drm: add a check for x/y in drm_mode_setcrtc · 83034100
      Zhao Junwang authored
      commit 01447e9f upstream.
      
      legacy setcrtc ioctl does take a 32 bit value which might indeed
      overflow
      
      the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
      needed any more with this
      
      v2: -polish the annotation according to Daniel's comment
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarZhao Junwang <zhjwpku@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      83034100
    • Michal Nazarewicz's avatar
      usb: f_mass_storage: limit number of reported LUNs · be30468a
      Michal Nazarewicz authored
      commit 8515bac0 upstream.
      
      Mass storage function created via configfs always reports eight LUNs
      to the hosts even if only one LUN has been configured.  Adjust the
      number when the USB function is allocated based on LUNs that user
      has created.
      Tested-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      [ luis: backported to 3.16:
        - file rename: drivers/usb/gadget/function/f_mass_storage.c ->
          drivers/usb/gadget/f_mass_storage.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      be30468a
    • Felipe Balbi's avatar
      usb: musb: host: rely on port_mode to call musb_start() · 6645294d
      Felipe Balbi authored
      commit be9d3988 upstream.
      
      Currently, we're calling musb_start() twice for DRD ports
      in some situations. This has been observed to cause enumeration
      issues after suspend/resume cycles with AM335x.
      
      In order to fix the problem, we just have to fix the check
      on musb_has_gadget() so that it only returns true if
      current mode is Host and ignore the fact that we have or
      not a gadget driver loaded.
      
      Fixes: ae44df2e (usb: musb: call musb_start() only once in OTG mode)
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Tested-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6645294d
    • Joe Thornber's avatar
      dm btree: silence lockdep lock inversion in dm_btree_del() · 75064b47
      Joe Thornber authored
      commit 1c751879 upstream.
      
      Allocate memory using GFP_NOIO when deleting a btree.  dm_btree_del()
      can be called via an ioctl and we don't want to recurse into the FS or
      block layer.
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      75064b47
    • Peter Sanford's avatar
      USB: cp210x: add ID for Aruba Networks controllers · 7ec0d6ed
      Peter Sanford authored
      commit f98a7aa8 upstream.
      
      Add the USB serial console device ID for Aruba Networks 7xxx series
      controllers which have a USB port for their serial console.
      Signed-off-by: default avatarPeter Sanford <peter@sanford.io>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7ec0d6ed
    • Claudio Cappelli's avatar
      USB: option: add 2020:4000 ID · c4ec7b0e
      Claudio Cappelli authored
      commit f6d7fb37 upstream.
      
      Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
      
      T:  Bus=01 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=4000 Rev=03.00
      S:  Manufacturer=Network Connect
      S:  Product=MT6225
      C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      Signed-off-by: default avatarClaudio Cappelli <claudio.cappelli.linux@gmail.com>
      Suggested-by: default avatarLars Melin <larsm17@gmail.com>
      [johan: amend commit message with devices info ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c4ec7b0e
    • Vutla, Lokesh's avatar
      crypto: omap-des - Fix unmapping of dma channels · a87b9ace
      Vutla, Lokesh authored
      commit acb33cc5 upstream.
      
      dma_unmap_sg() is being called twice after completing the
      task. Looks like this is a copy paste error when creating
      des driver.
      With this the following warn appears during boot:
      
      [    4.210457] ------------[ cut here ]------------
      [    4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0()
      [    4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000ab2ce000] [size=8 bytes]
      [    4.236785] Modules linked in:
      [    4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182
      [    4.247918] [<c001678c>] (unwind_backtrace) from [<c0012574>] (show_stack+0x10/0x14)
      [    4.255710] [<c0012574>] (show_stack) from [<c05a37e8>] (dump_stack+0x84/0xb8)
      [    4.262977] [<c05a37e8>] (dump_stack) from [<c0046464>] (warn_slowpath_common+0x68/0x8c)
      [    4.271107] [<c0046464>] (warn_slowpath_common) from [<c004651c>] (warn_slowpath_fmt+0x30/0x40)
      [    4.279854] [<c004651c>] (warn_slowpath_fmt) from [<c02d50a4>] (check_unmap+0x710/0x9a0)
      [    4.287991] [<c02d50a4>] (check_unmap) from [<c02d5478>] (debug_dma_unmap_sg+0x90/0x19c)
      [    4.296128] [<c02d5478>] (debug_dma_unmap_sg) from [<c04a77d8>] (omap_des_done_task+0x1cc/0x3e4)
      [    4.304963] [<c04a77d8>] (omap_des_done_task) from [<c004a090>] (tasklet_action+0x84/0x124)
      [    4.313370] [<c004a090>] (tasklet_action) from [<c004a4ac>] (__do_softirq+0xf0/0x20c)
      [    4.321235] [<c004a4ac>] (__do_softirq) from [<c004a840>] (irq_exit+0x98/0xec)
      [    4.328500] [<c004a840>] (irq_exit) from [<c000f9ac>] (handle_IRQ+0x50/0xb0)
      [    4.335589] [<c000f9ac>] (handle_IRQ) from [<c0008688>] (gic_handle_irq+0x28/0x5c)
      
      Removing the duplicate call to dma_unmap_sg().
      Reported-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a87b9ace
    • Vineet Gupta's avatar
      ARC: Override toplevel default -O2 with -O3 · 42dd36b8
      Vineet Gupta authored
      commit 97709069 upstream.
      
      ARC kernels have historically been built with -O3, despite top level
      Makefile defaulting to -O2. This was facilitated by implicitly ordering
      of arch makefile include AFTER top level assigned -O2.
      
      An upstream fix to top level a1c48bb1 ("Makefile: Fix unrecognized
      cross-compiler command line options") changed the ordering, making ARC
      -O3 defunct.
      
      Fix that by NOT relying on any ordering whatsoever and use the proper
      arch override facility now present in kbuild (ARCH_*FLAGS)
      
      Depends-on: ("kbuild: Allow arch Makefiles to override {cpp,ld,c}flags")
      Suggested-by: default avatarMichal Marek <mmarek@suse.cz>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      42dd36b8
    • Michal Marek's avatar
      kbuild: Allow arch Makefiles to override {cpp,ld,c}flags · 4a9e44d5
      Michal Marek authored
      commit 61754c18 upstream.
      
      Since commit a1c48bb1 (Makefile: Fix unrecognized cross-compiler command
      line options), the arch Makefile is included earlier by the main
      Makefile, preventing the arc architecture to set its -O3 compiler
      option. Since there might be more use cases for an arch Makefile to
      fine-tune the options, add support for ARCH_CPPFLAGS, ARCH_AFLAGS and
      ARCH_CFLAGS variables that are appended to the respective kbuild
      variables. The user still has the final say via the KCPPFLAGS, KAFLAGS
      and KCFLAGS variables.
      Reported-by: default avatarVineet Gupta <Vineet.Gupta1@synopsys.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4a9e44d5
    • Dennis Yang's avatar
      dm btree remove: fix bug in redistribute3 · 88913562
      Dennis Yang authored
      commit 4c7e3093 upstream.
      
      redistribute3() shares entries out across 3 nodes.  Some entries were
      being moved the wrong way, breaking the ordering.  This manifested as a
      BUG() in dm-btree-remove.c:shift() when entries were removed from the
      btree.
      
      For additional context see:
      https://www.redhat.com/archives/dm-devel/2015-May/msg00113.htmlSigned-off-by: default avatarDennis Yang <shinrairis@gmail.com>
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      88913562
    • Peter Meerwald's avatar
      iio: tmp006: Check channel info on write · 4e882ddc
      Peter Meerwald authored
      commit 8d05abfa upstream.
      
      only SAMP_FREQ is writable
      
      Will lead to SAMP_FREQ being written by any attempt to write
      to the other exported attributes and hence a rather unexpected
      result!
      Signed-off-by: default avatarPeter Meerwald <pmeerw@pmeerw.net>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4e882ddc
    • Dominic Sacré's avatar
      ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4 · 2b24558c
      Dominic Sacré authored
      commit 0689a86a upstream.
      
      The Steinberg MI2 and MI4 interfaces are compatible with the USB class
      audio spec, but the MIDI part of the devices is reported as a vendor
      specific interface.
      
      This patch adds entries to quirks-table.h to recognize the MIDI
      endpoints. Audio functionality was already working and is unaffected by
      this change.
      Signed-off-by: default avatarDominic Sacré <dominic.sacre@gmx.de>
      Signed-off-by: default avatarAlbert Huitsing <albert@huitsing.nl>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2b24558c
    • Jan Leupold's avatar
      iio: adc: at91_adc: allow to use full range of startup time · 46fa3216
      Jan Leupold authored
      commit 2ab5f39b upstream.
      
      The DT-Property "atmel,adc-startup-time" is stored in an u8 for a microsecond
      value. When trying to increase the value of STARTUP in Register AT91_ADC_MR
      some higher values can't be reached.
      
      Change the type in function parameter and private structure field from u8 to
      u32.
      Signed-off-by: default avatarJan Leupold <leupold@rsi-elektrotechnik.de>
      [nicolas.ferre@atmel.com: change commit message, increase u16 to u32 for startup time]
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      46fa3216
    • JM Friedt's avatar
      iio: DAC: ad5624r_spi: fix bit shift of output data value · 76fa7f7a
      JM Friedt authored
      commit adfa9698 upstream.
      
      The value sent on the SPI bus is shifted by an erroneous number of bits.
      The shift value was already computed in the iio_chan_spec structure and
      hence subtracting this argument to 16 yields an erroneous data position
      in the SPI stream.
      Signed-off-by: default avatarJM Friedt <jmfriedt@femto-st.fr>
      Acked-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      76fa7f7a
    • Adriana Reus's avatar
      iio: inv-mpu: Specify the expected format/precision for write channels · a86dcecb
      Adriana Reus authored
      commit 6a3c45bb upstream.
      
      The gyroscope needs IIO_VAL_INT_PLUS_NANO for the scale channel and
      unless specified write returns MICRO by default.
      This needs to be properly specified so that write operations into scale
      have the expected behaviour.
      Signed-off-by: default avatarAdriana Reus <adriana.reus@intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a86dcecb
    • Fabio Estevam's avatar
      iio: twl4030-madc: Pass the IRQF_ONESHOT flag · 6f344cab
      Fabio Estevam authored
      commit 6c0d48cb upstream.
      
      Since commit 1c6c6952 ("genirq: Reject bogus threaded irq requests")
      threaded IRQs without a primary handler need to be requested with
      IRQF_ONESHOT, otherwise the request will fail.
      
      So pass the IRQF_ONESHOT flag in this case.
      
      The semantic patch that makes this change is available
      in scripts/coccinelle/misc/irqf_oneshot.cocci.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6f344cab