1. 09 Mar, 2016 40 commits
    • Peter Hurley's avatar
      serial: omap: Prevent DoS using unprivileged ioctl(TIOCSRS485) · 39779539
      Peter Hurley authored
      commit 308bbc9a upstream.
      
      The omap-serial driver emulates RS485 delays using software timers,
      but neglects to clamp the input values from the unprivileged
      ioctl(TIOCSRS485). Because the software implementation busy-waits,
      malicious userspace could stall the cpu for ~49 days.
      
      Clamp the input values to < 100ms.
      
      Fixes: 4a0ac0f5 ("OMAP: add RS485 support")
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      39779539
    • Mathias Krause's avatar
      crypto: user - lock crypto_alg_list on alg dump · d9b34037
      Mathias Krause authored
      commit 63e41ebc upstream.
      
      We miss to take the crypto_alg_sem semaphore when traversing the
      crypto_alg_list for CRYPTO_MSG_GETALG dumps. This allows a race with
      crypto_unregister_alg() removing algorithms from the list while we're
      still traversing it, thereby leading to a use-after-free as show below:
      
      [ 3482.071639] general protection fault: 0000 [#1] SMP
      [ 3482.075639] Modules linked in: aes_x86_64 glue_helper lrw ablk_helper cryptd gf128mul ipv6 pcspkr serio_raw virtio_net microcode virtio_pci virtio_ring virtio sr_mod cdrom [last unloaded: aesni_intel]
      [ 3482.075639] CPU: 1 PID: 11065 Comm: crconf Not tainted 4.3.4-grsec+ #126
      [ 3482.075639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
      [ 3482.075639] task: ffff88001cd41a40 ti: ffff88001cd422c8 task.ti: ffff88001cd422c8
      [ 3482.075639] RIP: 0010:[<ffffffff93722bd3>]  [<ffffffff93722bd3>] strncpy+0x13/0x30
      [ 3482.075639] RSP: 0018:ffff88001f713b60  EFLAGS: 00010202
      [ 3482.075639] RAX: ffff88001f6c4430 RBX: ffff88001f6c43a0 RCX: ffff88001f6c4430
      [ 3482.075639] RDX: 0000000000000040 RSI: fefefefefefeff16 RDI: ffff88001f6c4430
      [ 3482.075639] RBP: ffff88001f713b60 R08: ffff88001f6c4470 R09: ffff88001f6c4480
      [ 3482.075639] R10: 0000000000000002 R11: 0000000000000246 R12: ffff88001ce2aa28
      [ 3482.075639] R13: ffff880000093700 R14: ffff88001f5e4bf8 R15: 0000000000003b20
      [ 3482.075639] FS:  0000033826fa2700(0000) GS:ffff88001e900000(0000) knlGS:0000000000000000
      [ 3482.075639] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 3482.075639] CR2: ffffffffff600400 CR3: 00000000139ec000 CR4: 00000000001606f0
      [ 3482.075639] Stack:
      [ 3482.075639]  ffff88001f713bd8 ffffffff936ccd00 ffff88001e5c4200 ffff880000093700
      [ 3482.075639]  ffff88001f713bd0 ffffffff938ef4bf 0000000000000000 0000000000003b20
      [ 3482.075639]  ffff88001f5e4bf8 ffff88001f5e4848 0000000000000000 0000000000003b20
      [ 3482.075639] Call Trace:
      [ 3482.075639]  [<ffffffff936ccd00>] crypto_report_alg+0xc0/0x3e0
      [ 3482.075639]  [<ffffffff938ef4bf>] ? __alloc_skb+0x16f/0x300
      [ 3482.075639]  [<ffffffff936cd08a>] crypto_dump_report+0x6a/0x90
      [ 3482.075639]  [<ffffffff93935707>] netlink_dump+0x147/0x2e0
      [ 3482.075639]  [<ffffffff93935f99>] __netlink_dump_start+0x159/0x190
      [ 3482.075639]  [<ffffffff936ccb13>] crypto_user_rcv_msg+0xc3/0x130
      [ 3482.075639]  [<ffffffff936cd020>] ? crypto_report_alg+0x3e0/0x3e0
      [ 3482.075639]  [<ffffffff936cc4b0>] ? alg_test_crc32c+0x120/0x120
      [ 3482.075639]  [<ffffffff93933145>] ? __netlink_lookup+0xd5/0x120
      [ 3482.075639]  [<ffffffff936cca50>] ? crypto_add_alg+0x1d0/0x1d0
      [ 3482.075639]  [<ffffffff93938141>] netlink_rcv_skb+0xe1/0x130
      [ 3482.075639]  [<ffffffff936cc4f8>] crypto_netlink_rcv+0x28/0x40
      [ 3482.075639]  [<ffffffff939375a8>] netlink_unicast+0x108/0x180
      [ 3482.075639]  [<ffffffff93937c21>] netlink_sendmsg+0x541/0x770
      [ 3482.075639]  [<ffffffff938e31e1>] sock_sendmsg+0x21/0x40
      [ 3482.075639]  [<ffffffff938e4763>] SyS_sendto+0xf3/0x130
      [ 3482.075639]  [<ffffffff93444203>] ? bad_area_nosemaphore+0x13/0x20
      [ 3482.075639]  [<ffffffff93444470>] ? __do_page_fault+0x80/0x3a0
      [ 3482.075639]  [<ffffffff939d80cb>] entry_SYSCALL_64_fastpath+0x12/0x6e
      [ 3482.075639] Code: 88 4a ff 75 ed 5d 48 0f ba 2c 24 3f c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 85 d2 48 89 f8 48 89 f9 4c 8d 04 17 48 89 e5 74 15 <0f> b6 16 80 fa 01 88 11 48 83 de ff 48 83 c1 01 4c 39 c1 75 eb
      [ 3482.075639] RIP  [<ffffffff93722bd3>] strncpy+0x13/0x30
      
      To trigger the race run the following loops simultaneously for a while:
        $ while : ; do modprobe aesni-intel; rmmod aesni-intel; done
        $ while : ; do crconf show all > /dev/null; done
      
      Fix the race by taking the crypto_alg_sem read lock, thereby preventing
      crypto_unregister_alg() from modifying the algorithm list during the
      dump.
      
      This bug has been detected by the PaX memory sanitize feature.
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: PaX Team <pageexec@freemail.hu>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d9b34037
    • Konstantin Khlebnikov's avatar
      radix-tree: fix oops after radix_tree_iter_retry · 4dcc1a91
      Konstantin Khlebnikov authored
      commit 73204282 upstream.
      
      Helper radix_tree_iter_retry() resets next_index to the current index.
      In following radix_tree_next_slot current chunk size becomes zero.  This
      isn't checked and it tries to dereference null pointer in slot.
      
      Tagged iterator is fine because retry happens only at slot 0 where tag
      bitmask in iter->tags is filled with single bit.
      
      Fixes: 46437f9a ("radix-tree: fix race in gang lookup")
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      4dcc1a91
    • Konstantin Khlebnikov's avatar
      mm: replace vma_lock_anon_vma with anon_vma_lock_read/write · 9b3d1987
      Konstantin Khlebnikov authored
      commit 12352d3c upstream.
      
      Sequence vma_lock_anon_vma() - vma_unlock_anon_vma() isn't safe if
      anon_vma appeared between lock and unlock.  We have to check anon_vma
      first or call anon_vma_prepare() to be sure that it's here.  There are
      only few users of these legacy helpers.  Let's get rid of them.
      
      This patch fixes anon_vma lock imbalance in validate_mm().  Write lock
      isn't required here, read lock is enough.
      
      And reorders expand_downwards/expand_upwards: security_mmap_addr() and
      wrapping-around check don't have to be under anon vma lock.
      
      Link: https://lkml.kernel.org/r/CACT4Y+Y908EjM2z=706dv4rV6dWtxTLK9nFg9_7DhRMLppBo2g@mail.gmail.comSigned-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9b3d1987
    • xuejiufei's avatar
      ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup · 609e2834
      xuejiufei authored
      commit c95a5180 upstream.
      
      When recovery master down, dlm_do_local_recovery_cleanup() only remove
      the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
      Which will make umount thread falling in dead loop migrating $RECOVERY
      to the dead node.
      Signed-off-by: default avatarxuejiufei <xuejiufei@huawei.com>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      609e2834
    • Tetsuo Handa's avatar
      mm, vmstat: fix wrong WQ sleep when memory reclaim doesn't make any progress · 29092228
      Tetsuo Handa authored
      commit 564e81a5 upstream.
      
      Jan Stancek has reported that system occasionally hanging after "oom01"
      testcase from LTP triggers OOM.  Guessing from a result that there is a
      kworker thread doing memory allocation and the values between "Node 0
      Normal free:" and "Node 0 Normal:" differs when hanging, vmstat is not
      up-to-date for some reason.
      
      According to commit 373ccbe5 ("mm, vmstat: allow WQ concurrency to
      discover memory reclaim doesn't make any progress"), it meant to force
      the kworker thread to take a short sleep, but it by error used
      schedule_timeout(1).  We missed that schedule_timeout() in state
      TASK_RUNNING doesn't do anything.
      
      Fix it by using schedule_timeout_uninterruptible(1) which forces the
      kworker thread to take a short sleep in order to make sure that vmstat
      is up-to-date.
      
      Fixes: 373ccbe5 ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress")
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Cristopher Lameter <clameter@sgi.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Arkadiusz Miskiewicz <arekm@maven.pl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      29092228
    • Eric Dumazet's avatar
      dump_stack: avoid potential deadlocks · 0988de22
      Eric Dumazet authored
      commit d7ce3692 upstream.
      
      Some servers experienced fatal deadlocks because of a combination of
      bugs, leading to multiple cpus calling dump_stack().
      
      The checksumming bug was fixed in commit 34ae6a1a ("ipv6: update
      skb->csum when CE mark is propagated").
      
      The second problem is a faulty locking in dump_stack()
      
      CPU1 runs in process context and calls dump_stack(), grabs dump_lock.
      
         CPU2 receives a TCP packet under softirq, grabs socket spinlock, and
         call dump_stack() from netdev_rx_csum_fault().
      
         dump_stack() spins on atomic_cmpxchg(&dump_lock, -1, 2), since
         dump_lock is owned by CPU1
      
      While dumping its stack, CPU1 is interrupted by a softirq, and happens
      to process a packet for the TCP socket locked by CPU2.
      
      CPU1 spins forever in spin_lock() : deadlock
      
      Stack trace on CPU1 looked like :
      
          NMI backtrace for cpu 1
          RIP: _raw_spin_lock+0x25/0x30
          ...
          Call Trace:
            <IRQ>
            tcp_v6_rcv+0x243/0x620
            ip6_input_finish+0x11f/0x330
            ip6_input+0x38/0x40
            ip6_rcv_finish+0x3c/0x90
            ipv6_rcv+0x2a9/0x500
            process_backlog+0x461/0xaa0
            net_rx_action+0x147/0x430
            __do_softirq+0x167/0x2d0
            call_softirq+0x1c/0x30
            do_softirq+0x3f/0x80
            irq_exit+0x6e/0xc0
            smp_call_function_single_interrupt+0x35/0x40
            call_function_single_interrupt+0x6a/0x70
            <EOI>
            printk+0x4d/0x4f
            printk_address+0x31/0x33
            print_trace_address+0x33/0x3c
            print_context_stack+0x7f/0x119
            dump_trace+0x26b/0x28e
            show_trace_log_lvl+0x4f/0x5c
            show_stack_log_lvl+0x104/0x113
            show_stack+0x42/0x44
            dump_stack+0x46/0x58
            netdev_rx_csum_fault+0x38/0x3c
            __skb_checksum_complete_head+0x6e/0x80
            __skb_checksum_complete+0x11/0x20
            tcp_rcv_established+0x2bd5/0x2fd0
            tcp_v6_do_rcv+0x13c/0x620
            sk_backlog_rcv+0x15/0x30
            release_sock+0xd2/0x150
            tcp_recvmsg+0x1c1/0xfc0
            inet_recvmsg+0x7d/0x90
            sock_recvmsg+0xaf/0xe0
            ___sys_recvmsg+0x111/0x3b0
            SyS_recvmsg+0x5c/0xb0
            system_call_fastpath+0x16/0x1b
      
      Fixes: b58d9774 ("dump_stack: serialize the output from dump_stack()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0988de22
    • David Henningsson's avatar
      ALSA: hda - Fix static checker warning in patch_hdmi.c · dd53cfc6
      David Henningsson authored
      commit 360a8245 upstream.
      
      The static checker warning is:
      
      	sound/pci/hda/patch_hdmi.c:460 hdmi_eld_ctl_get()
      	error: __memcpy() 'eld->eld_buffer' too small (256 vs 512)
      
      I have a hard time figuring out if this can ever cause an information leak
      (I don't think so), but nonetheless it does not hurt to increase the
      robustness of the code.
      
      Fixes: 68e03de9 ('ALSA: hda - hdmi: Do not expose eld data when eld is invalid')
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      dd53cfc6
    • Harry Wentland's avatar
      drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil · fa1aea6c
      Harry Wentland authored
      commit 64566b5e upstream.
      
      drm_fixp_from_fraction allows us to create a fixed point directly
      from a fraction, rather than creating fixed point values and dividing
      later. This avoids overflow of our 64 bit value for large numbers.
      
      drm_fixp2int_ceil allows us to return the ceiling of our fixed point
      value.
      
      [airlied: squash Jordan's fix]
      32-bit-build-fix: Jordan Lazare <Jordan.Lazare@amd.com>
      Signed-off-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      fa1aea6c
    • Mika Westerberg's avatar
      SCSI: Add Marvell Console to VPD blacklist · 976e7aa7
      Mika Westerberg authored
      commit 82c43310 upstream.
      
      I have a Marvell 88SE9230 SATA Controller that has some sort of
      integrated console SCSI device attached to one of the ports.
      
        ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        ata14.00: ATAPI: MARVELL VIRTUALL, 1.09, max UDMA/66
        ata14.00: configured for UDMA/66
        scsi 13:0:0:0: Processor         Marvell  Console 1.01 PQ: 0 ANSI: 5
      
      Sending it VPD INQUIRY command seem to always fail with following error:
      
        ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
        ata14.00: irq_stat 0x40000001
        ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 2 dma 16640 in
                  Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
        ata14: hard resetting link
      
      This has been minor annoyance (only error printed on dmesg) until commit
      09e2b0b1 ("scsi: rescan VPD attributes") added call to scsi_attach_vpd()
      in scsi_rescan_device(). The commit causes the system to splat out
      following errors continuously without ever reaching the UI:
      
        ata14.00: configured for UDMA/66
        ata14: EH complete
        ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
        ata14.00: irq_stat 0x40000001
        ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 6 dma 16640 in
                  Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
        ata14: hard resetting link
        ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        ata14.00: configured for UDMA/66
        ata14: EH complete
        ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
        ata14.00: irq_stat 0x40000001
        ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 7 dma 16640 in
                  Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
      
      Without in-depth understanding of SCSI layer and the Marvell controller,
      I suspect this happens because when the link goes down (because of an
      error) we schedule scsi_rescan_device() which again fails to read VPD
      data... ad infinitum.
      
      Since VPD data cannot be read from the device anyway we prevent the SCSI
      layer from even trying by blacklisting the device. This gets away the
      error and the system starts up normally.
      
      [mkp: Widened the match to all revisions of this device]
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reported-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: default avatarAlexander Duyck <alexander.duyck@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      976e7aa7
    • Hannes Reinecke's avatar
      scsi_dh_rdac: always retry MODE SELECT on command lock violation · 862d1bc8
      Hannes Reinecke authored
      commit d2d06d4f upstream.
      
      If MODE SELECT returns with sense '05/91/36' (command lock violation)
      it should always be retried without counting the number of retries.
      During an HBA upgrade or similar circumstances one might see a flood
      of MODE SELECT command from various HBAs, which will easily trigger
      the sense code and exceed the retry count.
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      862d1bc8
    • Filipe Manana's avatar
      Btrfs: fix hang on extent buffer lock caused by the inode_paths ioctl · a3e331aa
      Filipe Manana authored
      commit 0c0fe3b0 upstream.
      
      While doing some tests I ran into an hang on an extent buffer's rwlock
      that produced the following trace:
      
      [39389.800012] NMI watchdog: BUG: soft lockup - CPU#15 stuck for 22s! [fdm-stress:32166]
      [39389.800016] NMI watchdog: BUG: soft lockup - CPU#14 stuck for 22s! [fdm-stress:32165]
      [39389.800016] Modules linked in: btrfs dm_mod ppdev xor sha256_generic hmac raid6_pq drbg ansi_cprng aesni_intel i2c_piix4 acpi_cpufreq aes_x86_64 ablk_helper tpm_tis parport_pc i2c_core sg cryptd evdev psmouse lrw tpm parport gf128mul serio_raw pcspkr glue_helper processor button loop autofs4 ext4 crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring crc32c_intel scsi_mod e1000 virtio floppy [last unloaded: btrfs]
      [39389.800016] irq event stamp: 0
      [39389.800016] hardirqs last  enabled at (0): [<          (null)>]           (null)
      [39389.800016] hardirqs last disabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
      [39389.800016] softirqs last  enabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
      [39389.800016] softirqs last disabled at (0): [<          (null)>]           (null)
      [39389.800016] CPU: 14 PID: 32165 Comm: fdm-stress Not tainted 4.4.0-rc6-btrfs-next-18+ #1
      [39389.800016] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
      [39389.800016] task: ffff880175b1ca40 ti: ffff8800a185c000 task.ti: ffff8800a185c000
      [39389.800016] RIP: 0010:[<ffffffff810902af>]  [<ffffffff810902af>] queued_spin_lock_slowpath+0x57/0x158
      [39389.800016] RSP: 0018:ffff8800a185fb80  EFLAGS: 00000202
      [39389.800016] RAX: 0000000000000101 RBX: ffff8801710c4e9c RCX: 0000000000000101
      [39389.800016] RDX: 0000000000000100 RSI: 0000000000000001 RDI: 0000000000000001
      [39389.800016] RBP: ffff8800a185fb98 R08: 0000000000000001 R09: 0000000000000000
      [39389.800016] R10: ffff8800a185fb68 R11: 6db6db6db6db6db7 R12: ffff8801710c4e98
      [39389.800016] R13: ffff880175b1ca40 R14: ffff8800a185fc10 R15: ffff880175b1ca40
      [39389.800016] FS:  00007f6d37fff700(0000) GS:ffff8802be9c0000(0000) knlGS:0000000000000000
      [39389.800016] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [39389.800016] CR2: 00007f6d300019b8 CR3: 0000000037c93000 CR4: 00000000001406e0
      [39389.800016] Stack:
      [39389.800016]  ffff8801710c4e98 ffff8801710c4e98 ffff880175b1ca40 ffff8800a185fbb0
      [39389.800016]  ffffffff81091e11 ffff8801710c4e98 ffff8800a185fbc8 ffffffff81091895
      [39389.800016]  ffff8801710c4e98 ffff8800a185fbe8 ffffffff81486c5c ffffffffa067288c
      [39389.800016] Call Trace:
      [39389.800016]  [<ffffffff81091e11>] queued_read_lock_slowpath+0x46/0x60
      [39389.800016]  [<ffffffff81091895>] do_raw_read_lock+0x3e/0x41
      [39389.800016]  [<ffffffff81486c5c>] _raw_read_lock+0x3d/0x44
      [39389.800016]  [<ffffffffa067288c>] ? btrfs_tree_read_lock+0x54/0x125 [btrfs]
      [39389.800016]  [<ffffffffa067288c>] btrfs_tree_read_lock+0x54/0x125 [btrfs]
      [39389.800016]  [<ffffffffa0622ced>] ? btrfs_find_item+0xa7/0xd2 [btrfs]
      [39389.800016]  [<ffffffffa069363f>] btrfs_ref_to_path+0xd6/0x174 [btrfs]
      [39389.800016]  [<ffffffffa0693730>] inode_to_path+0x53/0xa2 [btrfs]
      [39389.800016]  [<ffffffffa0693e2e>] paths_from_inode+0x117/0x2ec [btrfs]
      [39389.800016]  [<ffffffffa0670cff>] btrfs_ioctl+0xd5b/0x2793 [btrfs]
      [39389.800016]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
      [39389.800016]  [<ffffffff81276727>] ? __this_cpu_preempt_check+0x13/0x15
      [39389.800016]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
      [39389.800016]  [<ffffffff8118b3d4>] ? rcu_read_unlock+0x3e/0x5d
      [39389.800016]  [<ffffffff811822f8>] do_vfs_ioctl+0x42b/0x4ea
      [39389.800016]  [<ffffffff8118b4f3>] ? __fget_light+0x62/0x71
      [39389.800016]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
      [39389.800016]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
      [39389.800016] Code: b9 01 01 00 00 f7 c6 00 ff ff ff 75 32 83 fe 01 89 ca 89 f0 0f 45 d7 f0 0f b1 13 39 f0 74 04 89 c6 eb e2 ff ca 0f 84 fa 00 00 00 <8b> 03 84 c0 74 04 f3 90 eb f6 66 c7 03 01 00 e9 e6 00 00 00 e8
      [39389.800012] Modules linked in: btrfs dm_mod ppdev xor sha256_generic hmac raid6_pq drbg ansi_cprng aesni_intel i2c_piix4 acpi_cpufreq aes_x86_64 ablk_helper tpm_tis parport_pc i2c_core sg cryptd evdev psmouse lrw tpm parport gf128mul serio_raw pcspkr glue_helper processor button loop autofs4 ext4 crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring crc32c_intel scsi_mod e1000 virtio floppy [last unloaded: btrfs]
      [39389.800012] irq event stamp: 0
      [39389.800012] hardirqs last  enabled at (0): [<          (null)>]           (null)
      [39389.800012] hardirqs last disabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
      [39389.800012] softirqs last  enabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
      [39389.800012] softirqs last disabled at (0): [<          (null)>]           (null)
      [39389.800012] CPU: 15 PID: 32166 Comm: fdm-stress Tainted: G             L  4.4.0-rc6-btrfs-next-18+ #1
      [39389.800012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
      [39389.800012] task: ffff880179294380 ti: ffff880034a60000 task.ti: ffff880034a60000
      [39389.800012] RIP: 0010:[<ffffffff81091e8d>]  [<ffffffff81091e8d>] queued_write_lock_slowpath+0x62/0x72
      [39389.800012] RSP: 0018:ffff880034a639f0  EFLAGS: 00000206
      [39389.800012] RAX: 0000000000000101 RBX: ffff8801710c4e98 RCX: 0000000000000000
      [39389.800012] RDX: 00000000000000ff RSI: 0000000000000000 RDI: ffff8801710c4e9c
      [39389.800012] RBP: ffff880034a639f8 R08: 0000000000000001 R09: 0000000000000000
      [39389.800012] R10: ffff880034a639b0 R11: 0000000000001000 R12: ffff8801710c4e98
      [39389.800012] R13: 0000000000000001 R14: ffff880172cbc000 R15: ffff8801710c4e00
      [39389.800012] FS:  00007f6d377fe700(0000) GS:ffff8802be9e0000(0000) knlGS:0000000000000000
      [39389.800012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [39389.800012] CR2: 00007f6d3d3c1000 CR3: 0000000037c93000 CR4: 00000000001406e0
      [39389.800012] Stack:
      [39389.800012]  ffff8801710c4e98 ffff880034a63a10 ffffffff81091963 ffff8801710c4e98
      [39389.800012]  ffff880034a63a30 ffffffff81486f1b ffffffffa0672cb3 ffff8801710c4e00
      [39389.800012]  ffff880034a63a78 ffffffffa0672cb3 ffff8801710c4e00 ffff880034a63a58
      [39389.800012] Call Trace:
      [39389.800012]  [<ffffffff81091963>] do_raw_write_lock+0x72/0x8c
      [39389.800012]  [<ffffffff81486f1b>] _raw_write_lock+0x3a/0x41
      [39389.800012]  [<ffffffffa0672cb3>] ? btrfs_tree_lock+0x119/0x251 [btrfs]
      [39389.800012]  [<ffffffffa0672cb3>] btrfs_tree_lock+0x119/0x251 [btrfs]
      [39389.800012]  [<ffffffffa061aeba>] ? rcu_read_unlock+0x5b/0x5d [btrfs]
      [39389.800012]  [<ffffffffa061ce13>] ? btrfs_root_node+0xda/0xe6 [btrfs]
      [39389.800012]  [<ffffffffa061ce83>] btrfs_lock_root_node+0x22/0x42 [btrfs]
      [39389.800012]  [<ffffffffa062046b>] btrfs_search_slot+0x1b8/0x758 [btrfs]
      [39389.800012]  [<ffffffff810fc6b0>] ? time_hardirqs_on+0x15/0x28
      [39389.800012]  [<ffffffffa06365db>] btrfs_lookup_inode+0x31/0x95 [btrfs]
      [39389.800012]  [<ffffffff8108d62f>] ? trace_hardirqs_on+0xd/0xf
      [39389.800012]  [<ffffffff8148482b>] ? mutex_lock_nested+0x397/0x3bc
      [39389.800012]  [<ffffffffa068821b>] __btrfs_update_delayed_inode+0x59/0x1c0 [btrfs]
      [39389.800012]  [<ffffffffa068858e>] __btrfs_commit_inode_delayed_items+0x194/0x5aa [btrfs]
      [39389.800012]  [<ffffffff81486ab7>] ? _raw_spin_unlock+0x31/0x44
      [39389.800012]  [<ffffffffa0688a48>] __btrfs_run_delayed_items+0xa4/0x15c [btrfs]
      [39389.800012]  [<ffffffffa0688d62>] btrfs_run_delayed_items+0x11/0x13 [btrfs]
      [39389.800012]  [<ffffffffa064048e>] btrfs_commit_transaction+0x234/0x96e [btrfs]
      [39389.800012]  [<ffffffffa0618d10>] btrfs_sync_fs+0x145/0x1ad [btrfs]
      [39389.800012]  [<ffffffffa0671176>] btrfs_ioctl+0x11d2/0x2793 [btrfs]
      [39389.800012]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
      [39389.800012]  [<ffffffff81140261>] ? __might_fault+0x4c/0xa7
      [39389.800012]  [<ffffffff81140261>] ? __might_fault+0x4c/0xa7
      [39389.800012]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
      [39389.800012]  [<ffffffff8118b3d4>] ? rcu_read_unlock+0x3e/0x5d
      [39389.800012]  [<ffffffff811822f8>] do_vfs_ioctl+0x42b/0x4ea
      [39389.800012]  [<ffffffff8118b4f3>] ? __fget_light+0x62/0x71
      [39389.800012]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
      [39389.800012]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
      [39389.800012] Code: f0 0f b1 13 85 c0 75 ef eb 2a f3 90 8a 03 84 c0 75 f8 f0 0f b0 13 84 c0 75 f0 ba ff 00 00 00 eb 0a f0 0f b1 13 ff c8 74 0b f3 90 <8b> 03 83 f8 01 75 f7 eb ed c6 43 04 00 5b 5d c3 0f 1f 44 00 00
      
      This happens because in the code path executed by the inode_paths ioctl we
      end up nesting two calls to read lock a leaf's rwlock when after the first
      call to read_lock() and before the second call to read_lock(), another
      task (running the delayed items as part of a transaction commit) has
      already called write_lock() against the leaf's rwlock. This situation is
      illustrated by the following diagram:
      
               Task A                       Task B
      
        btrfs_ref_to_path()               btrfs_commit_transaction()
          read_lock(&eb->lock);
      
                                            btrfs_run_delayed_items()
                                              __btrfs_commit_inode_delayed_items()
                                                __btrfs_update_delayed_inode()
                                                  btrfs_lookup_inode()
      
                                                    write_lock(&eb->lock);
                                                      --> task waits for lock
      
          read_lock(&eb->lock);
          --> makes this task hang
              forever (and task B too
      	of course)
      
      So fix this by avoiding doing the nested read lock, which is easily
      avoidable. This issue does not happen if task B calls write_lock() after
      task A does the second call to read_lock(), however there does not seem
      to exist anything in the documentation that mentions what is the expected
      behaviour for recursive locking of rwlocks (leaving the idea that doing
      so is not a good usage of rwlocks).
      
      Also, as a side effect necessary for this fix, make sure we do not
      needlessly read lock extent buffers when the input path has skip_locking
      set (used when called from send).
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a3e331aa
    • Mauro Carvalho Chehab's avatar
      [media] saa7134-alsa: Only frees registered sound cards · dd068a07
      Mauro Carvalho Chehab authored
      commit ac75fe5d upstream.
      
      That prevents this bug:
      [ 2382.269496] BUG: unable to handle kernel NULL pointer dereference at 0000000000000540
      [ 2382.270013] IP: [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
      [ 2382.270013] PGD 0
      [ 2382.270013] Oops: 0002 [#1] SMP
      [ 2382.270013] Modules linked in: saa7134_alsa(-) tda1004x saa7134_dvb videobuf2_dvb dvb_core tda827x tda8290 tuner saa7134 tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc tun bridge stp llc ebtables ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack it87 hwmon_vid snd_hda_codec_idt snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq pcspkr i2c_i801 snd_seq_device snd_pcm snd_timer lpc_ich snd mfd_core soundcore binfmt_misc i915 video i2c_algo_bit drm_kms_helper drm r8169 ata_generic serio_raw pata_acpi mii i2c_core [last unloaded: videobuf2_memops]
      [ 2382.270013] CPU: 0 PID: 4899 Comm: rmmod Not tainted 4.5.0-rc1+ #4
      [ 2382.270013] Hardware name: PCCHIPS P17G/P17G, BIOS 080012  05/14/2008
      [ 2382.270013] task: ffff880039c38000 ti: ffff88003c764000 task.ti: ffff88003c764000
      [ 2382.270013] RIP: 0010:[<ffffffffa01fe616>]  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
      [ 2382.270013] RSP: 0018:ffff88003c767ea0  EFLAGS: 00010286
      [ 2382.270013] RAX: ffff88003c767eb8 RBX: 0000000000000000 RCX: 0000000000006260
      [ 2382.270013] RDX: ffffffffa020a060 RSI: ffffffffa0206de1 RDI: ffff88003c767eb0
      [ 2382.270013] RBP: ffff88003c767ed8 R08: 0000000000019960 R09: ffffffff811a5412
      [ 2382.270013] R10: ffffea0000d7c200 R11: 0000000000000000 R12: ffff88003c767ea8
      [ 2382.270013] R13: 00007ffe760617f7 R14: 0000000000000000 R15: 0000557625d7f1e0
      [ 2382.270013] FS:  00007f80bb1c0700(0000) GS:ffff88003f400000(0000) knlGS:0000000000000000
      [ 2382.270013] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 2382.270013] CR2: 0000000000000540 CR3: 000000003c00f000 CR4: 00000000000006f0
      [ 2382.270013] Stack:
      [ 2382.270013]  000000003c767ed8 ffffffff00000000 ffff880000000000 ffff88003c767eb8
      [ 2382.270013]  ffff88003c767eb8 ffffffffa049a890 00007ffe76060060 ffff88003c767ef0
      [ 2382.270013]  ffffffffa049889d ffffffffa049a500 ffff88003c767f48 ffffffff8111079c
      [ 2382.270013] Call Trace:
      [ 2382.270013]  [<ffffffffa049889d>] saa7134_alsa_exit+0x1d/0x780 [saa7134_alsa]
      [ 2382.270013]  [<ffffffff8111079c>] SyS_delete_module+0x19c/0x1f0
      [ 2382.270013]  [<ffffffff8170fc2e>] entry_SYSCALL_64_fastpath+0x12/0x71
      [ 2382.270013] Code: 20 a0 48 c7 c6 e1 6d 20 a0 48 89 e5 41 54 53 4c 8d 65 d0 48 89 fb 48 83 ec 28 c7 45 d0 00 00 00 00 49 8d 7c 24 08 e8 7a 55 ed e0 <4c> 89 a3 40 05 00 00 48 89 df e8 eb fd ff ff 85 c0 75 1a 48 8d
      [ 2382.270013] RIP  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
      [ 2382.270013]  RSP <ffff88003c767ea0>
      [ 2382.270013] CR2: 0000000000000540
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      dd068a07
    • Takashi Iwai's avatar
      ALSA: timer: Fix leftover link at closing · 03cb8ef9
      Takashi Iwai authored
      commit 094fd3be upstream.
      
      In ALSA timer core, the active timer instance is managed in
      active_list linked list.  Each element is added / removed dynamically
      at timer start, stop and in timer interrupt.  The problem is that
      snd_timer_interrupt() has a thinko and leaves the element in
      active_list when it's the last opened element.  This eventually leads
      to list corruption or use-after-free error.
      
      This hasn't been revealed because we used to delete the list forcibly
      in snd_timer_stop() in the past.  However, the recent fix avoids the
      double-stop behavior (in commit [f784beb7: ALSA: timer: Fix link
      corruption due to double start or stop]), and this leak hits reality.
      
      This patch fixes the link management in snd_timer_interrupt().  Now it
      simply unlinks no matter which stream is.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+Yy2aukHP-EDp8-ziNqNNmb-NTf=jDWXMP7jB8HDa2vng@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      03cb8ef9
    • Mauro Carvalho Chehab's avatar
      [media] tda1004x: only update the frontend properties if locked · a0e9fa92
      Mauro Carvalho Chehab authored
      commit e8beb023 upstream.
      
      The tda1004x was updating the properties cache before locking.
      If the device is not locked, the data at the registers are just
      random values with no real meaning.
      
      This caused the driver to fail with libdvbv5, as such library
      calls GET_PROPERTY from time to time, in order to return the
      DVB stats.
      
      Tested with a saa7134 card 78:
      	ASUSTeK P7131 Dual, vendor PCI ID: 1043:4862
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a0e9fa92
    • Nicholas Bellinger's avatar
      target: Fix race with SCF_SEND_DELAYED_TAS handling · 1edf5c68
      Nicholas Bellinger authored
      commit 310d3d31 upstream.
      
      This patch fixes a race between setting of SCF_SEND_DELAYED_TAS
      in transport_send_task_abort(), and check of the same bit in
      transport_check_aborted_status().
      
      It adds a __transport_check_aborted_status() version that is
      used by target_execute_cmd() when se_cmd->t_state_lock is
      held, and a transport_check_aborted_status() wrapper for
      all other existing callers.
      
      Also, it handles the case where the check happens before
      transport_send_task_abort() gets called.  For this, go
      ahead and set SCF_SEND_DELAYED_TAS early when necessary,
      and have transport_send_task_abort() send the abort.
      
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1edf5c68
    • Nicholas Bellinger's avatar
      target: Fix remote-port TMR ABORT + se_cmd fabric stop · 1a84b32c
      Nicholas Bellinger authored
      commit 0f4a9431 upstream.
      
      To address the bug where fabric driver level shutdown
      of se_cmd occurs at the same time when TMR CMD_T_ABORTED
      is happening resulting in a -1 ->cmd_kref, this patch
      adds a CMD_T_FABRIC_STOP bit that is used to determine
      when TMR + driver I_T nexus shutdown is happening
      concurrently.
      
      It changes target_sess_cmd_list_set_waiting() to obtain
      se_cmd->cmd_kref + set CMD_T_FABRIC_STOP, and drop local
      reference in target_wait_for_sess_cmds() and invoke extra
      target_put_sess_cmd() during Task Aborted Status (TAS)
      when necessary.
      
      Also, it adds a new target_wait_free_cmd() wrapper around
      transport_wait_for_tasks() for the special case within
      transport_generic_free_cmd() to set CMD_T_FABRIC_STOP,
      and is now aware of CMD_T_ABORTED + CMD_T_TAS status
      bits to know when an extra transport_put_cmd() during
      TAS is required.
      
      Note transport_generic_free_cmd() is expected to block on
      cmd->cmd_wait_comp in order to follow what iscsi-target
      expects during iscsi_conn context se_cmd shutdown.
      
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@daterainc.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1a84b32c
    • Nicholas Bellinger's avatar
      target: Fix TAS handling for multi-session se_node_acls · cf67a228
      Nicholas Bellinger authored
      commit ebde1ca5 upstream.
      
      This patch fixes a bug in TMR task aborted status (TAS)
      handling when multiple sessions are connected to the
      same target WWPN endpoint and se_node_acl descriptor,
      resulting in TASK_ABORTED status to not be generated
      for aborted se_cmds on the remote port.
      
      This is due to core_tmr_handle_tas_abort() incorrectly
      comparing se_node_acl instead of se_session, for which
      the multi-session case is expected to be sharing the
      same se_node_acl.
      
      Instead, go ahead and update core_tmr_handle_tas_abort()
      to compare tmr_sess + cmd->se_sess in order to determine
      if the LUN_RESET was received on a different I_T nexus,
      and TASK_ABORTED status response needs to be generated.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cf67a228
    • Nicholas Bellinger's avatar
      target: Fix LUN_RESET active I/O handling for ACK_KREF · d80e7069
      Nicholas Bellinger authored
      [ Upstream commit febe562c ]
      
      This patch fixes a NULL pointer se_cmd->cmd_kref < 0
      refcount bug during TMR LUN_RESET with active se_cmd
      I/O, that can be triggered during se_cmd descriptor
      shutdown + release via core_tmr_drain_state_list() code.
      
      To address this bug, add common __target_check_io_state()
      helper for ABORT_TASK + LUN_RESET w/ CMD_T_COMPLETE
      checking, and set CMD_T_ABORTED + obtain ->cmd_kref for
      both cases ahead of last target_put_sess_cmd() after
      TFO->aborted_task() -> transport_cmd_finish_abort()
      callback has completed.
      
      It also introduces SCF_ACK_KREF to determine when
      transport_cmd_finish_abort() needs to drop the second
      extra reference, ahead of calling target_put_sess_cmd()
      for the final kref_put(&se_cmd->cmd_kref).
      
      It also updates transport_cmd_check_stop() to avoid
      holding se_cmd->t_state_lock while dropping se_cmd
      device state via target_remove_from_state_list(), now
      that core_tmr_drain_state_list() is holding the
      se_device lock while checking se_cmd state from
      within TMR logic.
      
      Finally, move transport_put_cmd() release of SGL +
      TMR + extended CDB memory into target_free_cmd_mem()
      in order to avoid potential resource leaks in TMR
      ABORT_TASK + LUN_RESET code-paths.  Also update
      target_release_cmd_kref() accordingly.
      Reviewed-by: default avatarQuinn Tran <quinn.tran@qlogic.com>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d80e7069
    • Nicholas Bellinger's avatar
      target: Fix LUN_RESET active TMR descriptor handling · b6cc298d
      Nicholas Bellinger authored
      [ Upstream commit a6d9bb1c ]
      
      This patch fixes a NULL pointer se_cmd->cmd_kref < 0
      refcount bug during TMR LUN_RESET with active TMRs,
      triggered during se_cmd + se_tmr_req descriptor
      shutdown + release via core_tmr_drain_tmr_list().
      
      To address this bug, go ahead and obtain a local
      kref_get_unless_zero(&se_cmd->cmd_kref) for active I/O
      to set CMD_T_ABORTED, and transport_wait_for_tasks()
      followed by the final target_put_sess_cmd() to drop
      the local ->cmd_kref.
      
      Also add two new checks within target_tmr_work() to
      avoid CMD_T_ABORTED -> TFO->queue_tm_rsp() callbacks
      ahead of invoking the backend -> fabric put in
      transport_cmd_check_stop_to_fabric().
      
      For good measure, also change core_tmr_release_req()
      to use list_del_init() ahead of se_tmr_req memory
      free.
      Reviewed-by: default avatarQuinn Tran <quinn.tran@qlogic.com>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b6cc298d
    • Nicholas Bellinger's avatar
      target: Add TFO->abort_task for aborted task resources release · 324748ca
      Nicholas Bellinger authored
      [ Upstream commit 131e6abc ]
      
      Now that TASK_ABORTED status is not generated for all cases by
      TMR ABORT_TASK + LUN_RESET, a new TFO->abort_task() caller is
      necessary in order to give fabric drivers a chance to unmap
      hardware / software resources before the se_cmd descriptor is
      released via the normal TFO->release_cmd() codepath.
      
      This patch adds TFO->aborted_task() in core_tmr_abort_task()
      in place of the original transport_send_task_abort(), and
      also updates all fabric drivers to implement this caller.
      
      The fabric drivers that include changes to perform cleanup
      via ->aborted_task() are:
      
        - iscsi-target
        - iser-target
        - srpt
        - tcm_qla2xxx
      
      The fabric drivers that currently set ->aborted_task() to
      NOPs are:
      
        - loopback
        - tcm_fc
        - usb-gadget
        - sbp-target
        - vhost-scsi
      
      For the latter five, there appears to be no additional cleanup
      required before invoking TFO->release_cmd() to release the
      se_cmd descriptor.
      
      v2 changes:
        - Move ->aborted_task() call into transport_cmd_finish_abort (Alex)
      
      Cc: Alex Leung <amleung21@yahoo.com>
      Cc: Mark Rustad <mark.d.rustad@intel.com>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Vu Pham <vu@mellanox.com>
      Cc: Chris Boot <bootc@bootc.net>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
      Cc: Saurav Kashyap <saurav.kashyap@qlogic.com>
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      324748ca
    • Alex Leung's avatar
      target: Fix Task Aborted Status (TAS) handling · 59c9df62
      Alex Leung authored
      [ Upstream commit 68259b5a ]
      
      This patch addresses three of long standing issues wrt to Task
      Aborted Status (TAS) handling.
      
      The first is the incorrect assumption in core_tmr_handle_tas_abort()
      that TASK_ABORTED status is sent for the task referenced by TMR
      ABORT_TASK, and sending TASK_ABORTED status for TMR LUN_RESET on
      the same nexus the LUN_RESET was received.
      
      The second is to ensure the lun reference count is dropped within
      transport_cmd_finish_abort() by calling transport_lun_remove_cmd()
      before invoking transport_cmd_check_stop_to_fabric().
      
      The last is to fix the delayed TAS handling to allow outstanding
      WRITEs to complete before sending the TASK_ABORTED status. This
      includes changing transport_check_aborted_status() to avoid
      processing when SCF_SEND_DELAYED_TAS has not be set, and updating
      transport_send_task_abort() to drop the SCF_SENT_DELAYED_TAS
      check.
      Signed-off-by: default avatarAlex Leung <amleung21@yahoo.com>
      Cc: Alex Leung <amleung21@yahoo.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      59c9df62
    • Mathias Nyman's avatar
      xhci: Fix list corruption in urb dequeue at host removal · b4b60627
      Mathias Nyman authored
      commit 5c821711 upstream.
      
      xhci driver frees data for all devices, both usb2 and and usb3 the
      first time usb_remove_hcd() is called, including td_list and and xhci_ring
      structures.
      
      When usb_remove_hcd() is called a second time for the second xhci bus it
      will try to dequeue all pending urbs, and touches td_list which is already
      freed for that endpoint.
      Reported-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b4b60627
    • Lu Baolu's avatar
      usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms · 08bd119e
      Lu Baolu authored
      commit ccc04afb upstream.
      
      Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well.
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      08bd119e
    • Mathias Nyman's avatar
      Revert "xhci: don't finish a TD if we get a short-transfer event mid TD" · 46b825a4
      Mathias Nyman authored
      commit a6835090 upstream.
      
      This reverts commit e210c422 ("xhci: don't finish a TD if we get a
      short transfer event mid TD")
      
      Turns out that most host controllers do not follow the xHCI specs and never
      send the second event for the last TRB in the TD if there was a short event
      mid-TD.
      
      Returning the URB directly after the first short-transfer event is far
      better than never returning the URB. (class drivers usually timeout
      after 30sec). For the hosts that do send the second event we will go
      back to treating it as misplaced event and print an error message for it.
      
      The origial patch was sent to stable kernels and needs to be reverted from
      there as well
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      46b825a4
    • Matthew Wilcox's avatar
      radix-tree: fix race in gang lookup · 3e9445c7
      Matthew Wilcox authored
      commit 46437f9a upstream.
      
      If the indirect_ptr bit is set on a slot, that indicates we need to redo
      the lookup.  Introduce a new function radix_tree_iter_retry() which
      forces the loop to retry the lookup by setting 'slot' to NULL and
      turning the iterator back to point at the problematic entry.
      
      This is a pretty rare problem to hit at the moment; the lookup has to
      race with a grow of the radix tree from a height of 0.  The consequences
      of hitting this race are that gang lookup could return a pointer to a
      radix_tree_node instead of a pointer to whatever the user had inserted
      in the tree.
      
      Fixes: cebbd29e ("radix-tree: rewrite gang lookup using iterator")
      Signed-off-by: default avatarMatthew Wilcox <willy@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3e9445c7
    • Kirill A. Shutemov's avatar
      drivers/scsi/sg.c: mark VMA as VM_IO to prevent migration · 2c4c6833
      Kirill A. Shutemov authored
      commit 461c7fa1 upstream.
      
      Reduced testcase:
      
          #include <fcntl.h>
          #include <unistd.h>
          #include <sys/mman.h>
          #include <numaif.h>
      
          #define SIZE 0x2000
      
          int main()
          {
              int fd;
              void *p;
      
              fd = open("/dev/sg0", O_RDWR);
              p = mmap(NULL, SIZE, PROT_EXEC, MAP_PRIVATE | MAP_LOCKED, fd, 0);
              mbind(p, SIZE, 0, NULL, 0, MPOL_MF_MOVE);
              return 0;
          }
      
      We shouldn't try to migrate pages in sg VMA as we don't have a way to
      update Sg_scatter_hold::pages accordingly from mm core.
      
      Let's mark the VMA as VM_IO to indicate to mm core that the VMA is not
      migratable.
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Doug Gilbert <dgilbert@interlog.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Shiraz Hashim <shashim@codeaurora.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2c4c6833
    • Takashi Iwai's avatar
      ALSA: seq: Fix lockdep warnings due to double mutex locks · faadae52
      Takashi Iwai authored
      commit 7f0973e9 upstream.
      
      The port subscription code uses double mutex locks for source and
      destination ports, and this may become racy once when wrongly set up.
      It leads to lockdep warning splat, typically triggered by fuzzer like
      syzkaller, although the actual deadlock hasn't been seen, so far.
      
      This patch simplifies the handling by reducing to two single locks, so
      that no lockdep warning will be trigger any longer.
      
      By splitting to two actions, a still-in-progress element shall be
      added in one list while handling another.  For ignoring this element,
      a new check is added in deliver_to_subscribers().
      
      Along with it, the code to add/remove the subscribers list element was
      cleaned up and refactored.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      faadae52
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix race at copying & updating the position · 373a7677
      Takashi Iwai authored
      commit 81f57754 upstream.
      
      The rawmidi read and write functions manage runtime stream status
      such as runtime->appl_ptr and runtime->avail.  These point where to
      copy the new data and how many bytes have been copied (or to be
      read).  The problem is that rawmidi read/write call copy_from_user()
      or copy_to_user(), and the runtime spinlock is temporarily unlocked
      and relocked while copying user-space.  Since the current code
      advances and updates the runtime status after the spin unlock/relock,
      the copy and the update may be asynchronous, and eventually
      runtime->avail might go to a negative value when many concurrent
      accesses are done.  This may lead to memory corruption in the end.
      
      For fixing this race, in this patch, the status update code is
      performed in the same lock before the temporary unlock.  Also, the
      spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
      protecting more properly during the whole operation.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      373a7677
    • Takashi Iwai's avatar
      ALSA: rawmidi: Make snd_rawmidi_transmit() race-free · 29be754b
      Takashi Iwai authored
      commit 06ab3003 upstream.
      
      A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
      syzkaller fuzzer:
        WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
       [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
       [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
       [<ffffffff84f80bd5>] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
       [<ffffffff84fdb3c1>] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
       [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
       [<ffffffff84f87ed9>] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
       [<ffffffff84f89fd3>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
       [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528
       [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
       [<     inline     >] SYSC_write fs/read_write.c:624
       [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
       [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185
      
      Also a similar warning is found but in another path:
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff82be2c0d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
       [<ffffffff81355139>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
       [<ffffffff81355369>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
       [<ffffffff8527e69a>] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
       [<ffffffff8527e851>] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
       [<ffffffff852d9046>] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
       [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
       [<ffffffff85285a0b>] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
       [<ffffffff85287b73>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
       [<ffffffff817ba5f3>] __vfs_write+0x113/0x480 fs/read_write.c:528
       [<ffffffff817bc087>] vfs_write+0x167/0x4a0 fs/read_write.c:577
       [<     inline     >] SYSC_write fs/read_write.c:624
       [<ffffffff817bf371>] SyS_write+0x111/0x220 fs/read_write.c:616
       [<ffffffff86660276>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185
      
      In the former case, the reason is that virmidi has an open code
      calling snd_rawmidi_transmit_ack() with the value calculated outside
      the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
      consuming the input data, but even there, there is a race between
      snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().
      
      Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
      snd_rawmidi_tranmit_ack() separately without protection, so they are
      racy as well.
      
      The patch tries to address these issues by the following ways:
      - Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
        snd_rawmidi_transmit_ack() to be called inside the explicit lock.
      - Rewrite snd_rawmidi_transmit() to be race-free (the former case).
      - Make the split calls (the latter case) protected in the rawmidi spin
        lock.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com
      BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      29be754b
    • Takashi Iwai's avatar
      ALSA: Move EXPORT_SYMBOL() in appropriate places · ec305886
      Takashi Iwai authored
      commit 6776a5d7 upstream.
      
      Just a cleanup to follow the standard coding style.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ec305886
    • Takashi Iwai's avatar
      ALSA: hda - Add fixup for Mac Mini 7,1 model · b5f6c1e4
      Takashi Iwai authored
      commit 2154cc0e upstream.
      
      Mac Mini 7,1 model with CS4208 codec reports the headphone jack
      detection wrongly in an inverted way.  Moreover, the advertised pins
      for the audio input and SPDIF output have actually no jack detection.
      
      This patch addresses these issues.  The inv_jack_detect flag is set
      for fixing the headphone jack detection, and the pin configs for audio
      input and SPDIF output are marked as non-detectable.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105161
      Report-and-tested-by: moosotc@gmail.com
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b5f6c1e4
    • Rusty Russell's avatar
      module: wrapper for symbol name. · 650e643e
      Rusty Russell authored
      commit 2e7bac53 upstream.
      
      This trivial wrapper adds clarity and makes the following patch
      smaller.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      650e643e
    • Vinod Koul's avatar
      ASoC: dpcm: fix the BE state on hw_free · 39d42356
      Vinod Koul authored
      commit 5e82d2be upstream.
      
      While performing hw_free, DPCM checks the BE state but leaves out
      the suspend state. The suspend state needs to be checked as well,
      as we might be suspended and then usermode closes rather than
      resuming the audio stream.
      
      This was found by a stress testing of system with playback in
      loop and killed after few seconds running in background and second
      script running suspend-resume test in loop
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Acked-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      39d42356
    • zengtao's avatar
      cputime: Prevent 32bit overflow in time[val|spec]_to_cputime() · 84151472
      zengtao authored
      commit 0f26922f upstream.
      
      The datatype __kernel_time_t is u32 on 32bit platform, so its subject to
      overflows in the timeval/timespec to cputime conversion.
      
      Currently the following functions are affected:
      1. setitimer()
      2. timer_create/timer_settime()
      3. sys_clock_nanosleep
      
      This can happen on MIPS32 and ARM32 with "Full dynticks CPU time accounting"
      enabled, which is required for CONFIG_NO_HZ_FULL.
      
      Enforce u64 conversion to prevent the overflow.
      
      Fixes: 31c1fc81 ("ARM: Kconfig: allow full nohz CPU accounting")
      Signed-off-by: default avatarzengtao <prime.zeng@huawei.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/1454384314-154784-1-git-send-email-prime.zeng@huawei.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      84151472
    • Tejun Heo's avatar
      libata: fix sff host state machine locking while polling · 75d344cc
      Tejun Heo authored
      commit 8eee1d3e upstream.
      
      The bulk of ATA host state machine is implemented by
      ata_sff_hsm_move().  The function is called from either the interrupt
      handler or, if polling, a work item.  Unlike from the interrupt path,
      the polling path calls the function without holding the host lock and
      ata_sff_hsm_move() selectively grabs the lock.
      
      This is completely broken.  If an IRQ triggers while polling is in
      progress, the two can easily race and end up accessing the hardware
      and updating state machine state at the same time.  This can put the
      state machine in an illegal state and lead to a crash like the
      following.
      
        kernel BUG at drivers/ata/libata-sff.c:1302!
        invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
        Modules linked in:
        CPU: 1 PID: 10679 Comm: syz-executor Not tainted 4.5.0-rc1+ #300
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        task: ffff88002bd00000 ti: ffff88002e048000 task.ti: ffff88002e048000
        RIP: 0010:[<ffffffff83a83409>]  [<ffffffff83a83409>] ata_sff_hsm_move+0x619/0x1c60
        ...
        Call Trace:
         <IRQ>
         [<ffffffff83a84c31>] __ata_sff_port_intr+0x1e1/0x3a0 drivers/ata/libata-sff.c:1584
         [<ffffffff83a85611>] ata_bmdma_port_intr+0x71/0x400 drivers/ata/libata-sff.c:2877
         [<     inline     >] __ata_sff_interrupt drivers/ata/libata-sff.c:1629
         [<ffffffff83a85bf3>] ata_bmdma_interrupt+0x253/0x580 drivers/ata/libata-sff.c:2902
         [<ffffffff81479f98>] handle_irq_event_percpu+0x108/0x7e0 kernel/irq/handle.c:157
         [<ffffffff8147a717>] handle_irq_event+0xa7/0x140 kernel/irq/handle.c:205
         [<ffffffff81484573>] handle_edge_irq+0x1e3/0x8d0 kernel/irq/chip.c:623
         [<     inline     >] generic_handle_irq_desc include/linux/irqdesc.h:146
         [<ffffffff811a92bc>] handle_irq+0x10c/0x2a0 arch/x86/kernel/irq_64.c:78
         [<ffffffff811a7e4d>] do_IRQ+0x7d/0x1a0 arch/x86/kernel/irq.c:240
         [<ffffffff86653d4c>] common_interrupt+0x8c/0x8c arch/x86/entry/entry_64.S:520
         <EOI>
         [<     inline     >] rcu_lock_acquire include/linux/rcupdate.h:490
         [<     inline     >] rcu_read_lock include/linux/rcupdate.h:874
         [<ffffffff8164b4a1>] filemap_map_pages+0x131/0xba0 mm/filemap.c:2145
         [<     inline     >] do_fault_around mm/memory.c:2943
         [<     inline     >] do_read_fault mm/memory.c:2962
         [<     inline     >] do_fault mm/memory.c:3133
         [<     inline     >] handle_pte_fault mm/memory.c:3308
         [<     inline     >] __handle_mm_fault mm/memory.c:3418
         [<ffffffff816efb16>] handle_mm_fault+0x2516/0x49a0 mm/memory.c:3447
         [<ffffffff8127dc16>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
         [<ffffffff8127e358>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
         [<ffffffff8126f514>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
         [<ffffffff86655578>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
      
      Fix it by ensuring that the polling path is holding the host lock
      before entering ata_sff_hsm_move() so that all hardware accesses and
      state updates are performed under the host lock.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Link: http://lkml.kernel.org/g/CACT4Y+b_JsOxJu2EZyEf+mOXORc_zid5V1-pLZSroJVxyWdSpw@mail.gmail.comSigned-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      75d344cc
    • Takashi Iwai's avatar
      ALSA: timer: Fix link corruption due to double start or stop · ee208c37
      Takashi Iwai authored
      commit f784beb7 upstream.
      
      Although ALSA timer code got hardening for races, it still causes
      use-after-free error.  This is however rather a corrupted linked list,
      not actually the concurrent accesses.  Namely, when timer start is
      triggered twice, list_add_tail() is called twice, too.  This ends
      up with the link corruption and triggers KASAN error.
      
      The simplest fix would be replacing list_add_tail() with
      list_move_tail(), but fundamentally it's the problem that we don't
      check the double start/stop correctly.  So, the right fix here is to
      add the proper checks to snd_timer_start() and snd_timer_stop() (and
      their variants).
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+ZyPRoMQjmawbvmCEDrkBD2BQuH7R09=eOkf5ESK8kJAw@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ kamal: backport to 3.13-stable: context in _snd_timer_stop ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ee208c37
    • Takashi Iwai's avatar
      ALSA: seq: Fix yet another races among ALSA timer accesses · d72d3700
      Takashi Iwai authored
      commit 2cdc7b63 upstream.
      
      ALSA sequencer may open/close and control ALSA timer instance
      dynamically either via sequencer events or direct ioctls.  These are
      done mostly asynchronously, and it may call still some timer action
      like snd_timer_start() while another is calling snd_timer_close().
      Since the instance gets removed by snd_timer_close(), it may lead to
      a use-after-free.
      
      This patch tries to address such a race by protecting each
      snd_timer_*() call via the existing spinlock and also by avoiding the
      access to timer during close call.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+Z6RzW5MBr-HUdV-8zwg71WQfKTdPpYGvOeS7v4cyurNQ@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d72d3700
    • Takashi Iwai's avatar
      ALSA: pcm: Fix potential deadlock in OSS emulation · 1dc4fbfc
      Takashi Iwai authored
      commit b2483716 upstream.
      
      There are potential deadlocks in PCM OSS emulation code while
      accessing read/write and mmap concurrently.  This comes from the
      infamous mmap_sem usage in copy_from/to_user().  Namely,
      
         snd_pcm_oss_write() ->
           &runtime->oss.params_lock ->
              copy_to_user() ->
                &mm->mmap_sem
        mmap() ->
          &mm->mmap_sem ->
            snd_pcm_oss_mmap() ->
              &runtime->oss.params_lock
      
      Since we can't avoid taking params_lock from mmap code path, use
      trylock variant and aborts with -EAGAIN as a workaround of this AB/BA
      deadlock.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+bVrBKDG0G2_AcUgUQa+X91VKTeS4v+wN7BSHwHtqn3kQ@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1dc4fbfc
    • Takashi Iwai's avatar
      ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check · 5b6ee6f3
      Takashi Iwai authored
      commit cc85f7a6 upstream.
      
      NULL user-space buffer can be passed even in a normal path, thus it's
      not good to spew a kernel warning with stack trace at each time.
      Just drop snd_BUG_ON() macro usage there.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+YfVJ3L+q0i-4vyQVyyPD7V=OMX0PWPi29x9Bo3QaBLdw@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5b6ee6f3