1. 25 Feb, 2016 39 commits
    • Filipe Manana's avatar
      Btrfs: fix hang on extent buffer lock caused by the inode_paths ioctl · b10a62d6
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      b10a62d6
    • Mauro Carvalho Chehab's avatar
      [media] saa7134-alsa: Only frees registered sound cards · 8e4c5027
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      8e4c5027
    • Takashi Iwai's avatar
      ALSA: timer: Fix leftover link at closing · 789565bd
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      789565bd
    • Mauro Carvalho Chehab's avatar
      [media] tda1004x: only update the frontend properties if locked · 6b33f7da
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      6b33f7da
    • Mathias Nyman's avatar
      xhci: Fix list corruption in urb dequeue at host removal · 5d666904
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      5d666904
    • Lu Baolu's avatar
      usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms · 5635ac10
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      5635ac10
    • Mathias Nyman's avatar
      Revert "xhci: don't finish a TD if we get a short-transfer event mid TD" · 877417fe
      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>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      877417fe
    • Matthew Wilcox's avatar
      radix-tree: fix race in gang lookup · 4a2597f9
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      4a2597f9
    • Kirill A. Shutemov's avatar
      drivers/scsi/sg.c: mark VMA as VM_IO to prevent migration · 58b18a2a
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      58b18a2a
    • Takashi Iwai's avatar
      ALSA: seq: Fix lockdep warnings due to double mutex locks · 5f458366
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      5f458366
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix race at copying & updating the position · 417d58e0
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      417d58e0
    • Takashi Iwai's avatar
      ALSA: rawmidi: Make snd_rawmidi_transmit() race-free · 530372de
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      530372de
    • Takashi Iwai's avatar
      ALSA: hda - Add fixup for Mac Mini 7,1 model · 0d0254d7
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      0d0254d7
    • Rusty Russell's avatar
      module: wrapper for symbol name. · 1d6bac0b
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      1d6bac0b
    • Vinod Koul's avatar
      ASoC: dpcm: fix the BE state on hw_free · 6d64a48c
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      6d64a48c
    • zengtao's avatar
      cputime: Prevent 32bit overflow in time[val|spec]_to_cputime() · ac021f91
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      ac021f91
    • James Hogan's avatar
      MIPS: Fix buffer overflow in syscall_get_arguments() · c584e533
      James Hogan authored
      commit f4dce1ff upstream.
      
      Since commit 4c21b8fd ("MIPS: seccomp: Handle indirect system calls
      (o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall
      arguments by incrementing both the start argument number and the number
      of arguments to fetch. However only the start argument number needs to
      be incremented. The number of arguments does not change, they're just
      shifted up by one, and in fact the output array is provided by the
      caller and is likely only n entries long, so reading more arguments
      overflows the output buffer.
      
      In the case of seccomp, this results in it fetching 7 arguments starting
      at the 2nd one, which overflows the unsigned long args[6] in
      populate_seccomp_data(). This clobbers the $s0 register from
      syscall_trace_enter() which __seccomp_phase1_filter() saved onto the
      stack, into which syscall_trace_enter() had placed its syscall number
      argument. This caused Chromium to crash.
      
      Credit goes to Milko for tracking it down as far as $s0 being clobbered.
      
      Fixes: 4c21b8fd ("MIPS: seccomp: Handle indirect system calls (o32)")
      Reported-by: default avatarMilko Leporis <milko.leporis@imgtec.com>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/12213/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c584e533
    • Tejun Heo's avatar
      libata: fix sff host state machine locking while polling · a7b79df7
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      a7b79df7
    • Takashi Iwai's avatar
      ALSA: timer: Fix link corruption due to double start or stop · 95cd42a4
      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>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      95cd42a4
    • Takashi Iwai's avatar
      ALSA: timer: Code cleanup · a293ce87
      Takashi Iwai authored
      commit c3b16813 upstream.
      
      This is a minor code cleanup without any functional changes:
      - Kill keep_flag argument from _snd_timer_stop(), as all callers pass
        only it false.
      - Remove redundant NULL check in _snd_timer_stop().
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a293ce87
    • Takashi Iwai's avatar
      ALSA: seq: Fix yet another races among ALSA timer accesses · 8af68e44
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      8af68e44
    • Takashi Iwai's avatar
      ALSA: pcm: Fix potential deadlock in OSS emulation · b9b54e19
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      b9b54e19
    • Takashi Iwai's avatar
      ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check · 7d9c7599
      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 avatarLuis Henriques <luis.henriques@canonical.com>
      7d9c7599
    • Takashi Iwai's avatar
      ALSA: seq: Fix race at closing in virmidi driver · 49edef6e
      Takashi Iwai authored
      commit 2d1b5c08 upstream.
      
      The virmidi driver has an open race at closing its assigned rawmidi
      device, and this may lead to use-after-free in
      snd_seq_deliver_single_event().
      
      Plug the hole by properly protecting the linked list deletion and
      calling in the right order in snd_virmidi_input_close().
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+Zd66+w12fNN85-425cVQT=K23kWbhnCEcMB8s3us-Frw@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 avatarLuis Henriques <luis.henriques@canonical.com>
      49edef6e
    • Dan Carpenter's avatar
      intel_scu_ipcutil: underflow in scu_reg_access() · 45c4556d
      Dan Carpenter authored
      commit b1d353ad upstream.
      
      "count" is controlled by the user and it can be negative.  Let's prevent
      that by making it unsigned.  You have to have CAP_SYS_RAWIO to call this
      function so the bug is not as serious as it could be.
      
      Fixes: 5369c02d ('intel_scu_ipc: Utility driver for intel scu ipc')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      45c4556d
    • Akinobu Mita's avatar
      iio: pressure: mpl115: fix temperature offset sign · f1da7f50
      Akinobu Mita authored
      commit 431386e7 upstream.
      
      According to the datasheet, the resolusion of temperature sensor is
      -5.35 counts/C. Temperature ADC is 472 counts at 25C.
      (https://www.sparkfun.com/datasheets/Sensors/Pressure/MPL115A1.pdf
      NOTE: This is older revision, but this information is removed from the
      latest datasheet from nxp somehow)
      
      Temp [C] = (Tadc - 472) / -5.35 + 25
               = (Tadc - 605.750000) * -0.186915888
      
      So the correct offset is -605.750000.
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: default avatarPeter Meerwald-Stadler <pmeerw@pmeerw.net>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f1da7f50
    • Dan Carpenter's avatar
      iio: inkern: fix a NULL dereference on error · c7fbe9e7
      Dan Carpenter authored
      commit d81dac3c upstream.
      
      In twl4030_bci_probe() there are some failure paths where we call
      iio_channel_release() with a NULL pointer.  (Apparently, that driver can
      opperate without a valid channel pointer).  Let's fix it by adding a
      NULL check in iio_channel_release().
      
      Fixes: 2202e1fc ('drivers: power: twl4030_charger: fix link problems when building as module')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c7fbe9e7
    • Wang, Rui Y's avatar
      crypto: algif_hash - wait for crypto_ahash_init() to complete · f5892ce3
      Wang, Rui Y authored
      commit fe097861 upstream.
      
      hash_sendmsg/sendpage() need to wait for the completion
      of crypto_ahash_init() otherwise it can cause panic.
      Signed-off-by: default avatarRui Wang <rui.y.wang@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f5892ce3
    • Mike Christie's avatar
      target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors · 7a2514f3
      Mike Christie authored
      commit 8a9ebe71 upstream.
      
      In a couple places we are not converting to/from the Linux
      block layer 512 bytes sectors.
      
      1.
      
      The request queue values and what we do are a mismatch of
      things:
      
      max_discard_sectors - This is in linux block layer 512 byte
      sectors. We are just copying this to max_unmap_lba_count.
      
      discard_granularity - This is in bytes. We are converting it
      to Linux block layer 512 byte sectors.
      
      discard_alignment - This is in bytes. We are just copying
      this over.
      
      The problem is that the core LIO code exports these values in
      spc_emulate_evpd_b0 and we use them to test request arguments
      in sbc_execute_unmap, but we never convert to the block size
      we export to the initiator. If we are not using 512 byte sectors
      then we are exporting the wrong values or are checks are off.
      And, for the discard_alignment/bytes case we are just plain messed
      up.
      
      2.
      
      blkdev_issue_discard's start and number of sector arguments
      are supposed to be in linux block layer 512 byte sectors. We are
      currently passing in the values we get from the initiator which
      might be based on some other sector size.
      
      There is a similar problem in iblock_execute_write_same where
      the bio functions want values in 512 byte sectors but we are
      passing in what we got from the initiator.
      Signed-off-by: default avatarMike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ luis: backported to 3.16:
        - dropped changes to attribute unmap_zeroes_data as 3.16 doesn't
          support LBPRZ
        - functions rename:
          * fd_execute_unmap -> fd_do_unmap
          * iblock_execute_unmap -> iblock_do_unmap
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7a2514f3
    • Jani Nikula's avatar
      drm/i915/dp: fall back to 18 bpp when sink capability is unknown · eba5acbe
      Jani Nikula authored
      commit 5efd4076 upstream.
      
      Per DP spec, the source device should fall back to 18 bpp, VESA range
      RGB when the sink capability is unknown. Fix the color depth
      clamping. 18 bpp color depth should ensure full color range in automatic
      mode.
      
      The clamping has been HDMI specific since its introduction in
      
      commit 996a2239
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Fri Apr 19 11:24:34 2013 +0200
      
          drm/i915: Disable high-bpc on pre-1.4 EDID screens
      Reported-and-tested-by: default avatarDihan Wickremasuriya <nayomal@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
      (cherry picked from commit 013dd9e0)
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      eba5acbe
    • Herbert Xu's avatar
      crypto: shash - Fix has_key setting · 7c684091
      Herbert Xu authored
      commit 00420a65 upstream.
      
      The has_key logic is wrong for shash algorithms as they always
      have a setkey function.  So we should instead be testing against
      shash_no_setkey.
      
      Fixes: a5596d63 ("crypto: hash - Add crypto_ahash_has_setkey")
      Reported-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7c684091
    • Johannes Berg's avatar
      rfkill: fix rfkill_fop_read wait_event usage · 61f0fc48
      Johannes Berg authored
      commit 6736fde9 upstream.
      
      The code within wait_event_interruptible() is called with
      !TASK_RUNNING, so mustn't call any functions that can sleep,
      like mutex_lock().
      
      Since we re-check the list_empty() in a loop after the wait,
      it's safe to simply use list_empty() without locking.
      
      This bug has existed forever, but was only discovered now
      because all userspace implementations, including the default
      'rfkill' tool, use poll() or select() to get a readable fd
      before attempting to read.
      
      Fixes: c64fb016 ("rfkill: create useful userspace interface")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      61f0fc48
    • Sachin Kulkarni's avatar
      mac80211: Requeue work after scan complete for all VIF types. · 587faa0e
      Sachin Kulkarni authored
      commit 4fa11ec7 upstream.
      
      During a sw scan ieee80211_iface_work ignores work items for all vifs.
      However after the scan complete work is requeued only for STA, ADHOC
      and MESH iftypes.
      
      This occasionally results in event processing getting delayed/not
      processed for iftype AP when it coexists with a STA. This can result
      in data halt and eventually disconnection on the AP interface.
      Signed-off-by: default avatarSachin Kulkarni <Sachin.Kulkarni@imgtec.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      587faa0e
    • Tejun Heo's avatar
      libata: disable forced PORTS_IMPL for >= AHCI 1.3 · 36f4a64b
      Tejun Heo authored
      commit 566d1827 upstream.
      
      Some early controllers incorrectly reported zero ports in PORTS_IMPL
      register and the ahci driver fabricates PORTS_IMPL from the number of
      ports in those cases.  This hasn't mattered but with the new nvme
      controllers there are cases where zero PORTS_IMPL is valid and should
      be honored.
      
      Disable the workaround for >= AHCI 1.3.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Link: http://lkml.kernel.org/g/CALCETrU7yMvXEDhjAUShoHEhDwifJGapdw--BKxsP0jmjKGmRw@mail.gmail.com
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      36f4a64b
    • Sebastian Andrzej Siewior's avatar
      PCI/AER: Flush workqueue on device remove to avoid use-after-free · 3a170fda
      Sebastian Andrzej Siewior authored
      commit 4ae2182b upstream.
      
      A Root Port's AER structure (rpc) contains a queue of events.  aer_irq()
      enqueues AER status information and schedules aer_isr() to dequeue and
      process it.  When we remove a device, aer_remove() waits for the queue to
      be empty, then frees the rpc struct.
      
      But aer_isr() references the rpc struct after dequeueing and possibly
      emptying the queue, which can cause a use-after-free error as in the
      following scenario with two threads, aer_isr() on the left and a
      concurrent aer_remove() on the right:
      
        Thread A                      Thread B
        --------                      --------
        aer_irq():
          rpc->prod_idx++
                                      aer_remove():
                                        wait_event(rpc->prod_idx == rpc->cons_idx)
                                        # now blocked until queue becomes empty
        aer_isr():                      # ...
          rpc->cons_idx++               # unblocked because queue is now empty
          ...                           kfree(rpc)
          mutex_unlock(&rpc->rpc_mutex)
      
      To prevent this problem, use flush_work() to wait until the last scheduled
      instance of aer_isr() has completed before freeing the rpc struct in
      aer_remove().
      
      I reproduced this use-after-free by flashing a device FPGA and
      re-enumerating the bus to find the new device.  With SLUB debug, this
      crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
      GPR25:
      
        pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
        Unable to handle kernel paging request for data at address 0x27ef9e3e
        Workqueue: events aer_isr
        GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
        NIP [602f5328] pci_walk_bus+0xd4/0x104
      
      [bhelgaas: changelog, stable tag]
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3a170fda
    • Tejun Heo's avatar
      cgroup: make sure a parent css isn't offlined before its children · d9892cc2
      Tejun Heo authored
      commit aa226ff4 upstream.
      
      There are three subsystem callbacks in css shutdown path -
      css_offline(), css_released() and css_free().  Except for
      css_released(), cgroup core didn't guarantee the order of invocation.
      css_offline() or css_free() could be called on a parent css before its
      children.  This behavior is unexpected and led to bugs in cpu and
      memory controller.
      
      This patch updates offline path so that a parent css is never offlined
      before its children.  Each css keeps online_cnt which reaches zero iff
      itself and all its children are offline and offline_css() is invoked
      only after online_cnt reaches zero.
      
      This fixes the memory controller bug and allows the fix for cpu
      controller.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Reported-by: default avatarBrian Christiansen <brian.o.christiansen@gmail.com>
      Link: http://lkml.kernel.org/g/5698A023.9070703@de.ibm.com
      Link: http://lkml.kernel.org/g/CAKB58ikDkzc8REt31WBkD99+hxNzjK4+FBmhkgS+NVrC9vjMSg@mail.gmail.com
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      [ luis: backported to 3.16:
        - file rename: cgroup-defs.h -> cgroup.h
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d9892cc2
    • Bard Liao's avatar
      ASoC: rt5645: fix the shift bit of IN1 boost · 65284f9e
      Bard Liao authored
      commit b28785fa upstream.
      
      The shift bit of IN1 boost gain control is 12.
      Signed-off-by: default avatarBard Liao <bardliao@realtek.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      65284f9e
    • Yong Li's avatar
      iio: dac: mcp4725: set iio name property in sysfs · d9c548d2
      Yong Li authored
      commit 97a249e9 upstream.
      
      Without this change, the name entity for mcp4725 is missing in
      /sys/bus/iio/devices/iio\:device*/name
      
      With this change, name is reported correctly
      Signed-off-by: default avatarYong Li <sdliyong@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d9c548d2
    • Vegard Nossum's avatar
      iio: add HAS_IOMEM dependency to VF610_ADC · ac9b5af6
      Vegard Nossum authored
      commit 005ce071 upstream.
      
      Ran into this on UML:
      
      drivers/built-in.o: In function `vf610_adc_probe':
      drivers/iio/adc/vf610_adc.c:744: undefined reference to `devm_ioremap_resource'
      
      devm_ioremap_resource() is defined only when HAS_IOMEM is selected.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.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>
      ac9b5af6
  2. 24 Feb, 2016 1 commit