1. 13 Jan, 2017 35 commits
    • Eric Sandeen's avatar
      xfs: set AGI buffer type in xlog_recover_clear_agi_bucket · 93f5b2b5
      Eric Sandeen authored
      [ Upstream commit 6b10b23c ]
      
      xlog_recover_clear_agi_bucket didn't set the
      type to XFS_BLFT_AGI_BUF, so we got a warning during log
      replay (or an ASSERT on a debug build).
      
          XFS (md0): Unknown buffer type 0!
          XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
      
      Fix this, as was done in f19b872b for 2 other locations
      with the same problem.
      
      cc: <stable@vger.kernel.org> # 3.10 to current
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      93f5b2b5
    • Rabin Vincent's avatar
      block: protect iterate_bdevs() against concurrent close · 73e7d7ae
      Rabin Vincent authored
      [ Upstream commit af309226 ]
      
      If a block device is closed while iterate_bdevs() is handling it, the
      following NULL pointer dereference occurs because bdev->b_disk is NULL
      in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
      turn called by the mapping_cap_writeback_dirty() call in
      __filemap_fdatawrite_range()):
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
       IP: [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
       PGD 9e62067 PUD 9ee8067 PMD 0
       Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in:
       CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
       task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
       RIP: 0010:[<ffffffff81314790>]  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
       RSP: 0018:ffff880009f5fe68  EFLAGS: 00010246
       RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
       RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
       RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
       R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
       FS:  00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
       Stack:
        ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
        0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
        ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
       Call Trace:
        [<ffffffff8112e7f5>] __filemap_fdatawrite_range+0x85/0x90
        [<ffffffff8112e81f>] filemap_fdatawrite+0x1f/0x30
        [<ffffffff811b25d6>] fdatawrite_one_bdev+0x16/0x20
        [<ffffffff811bc402>] iterate_bdevs+0xf2/0x130
        [<ffffffff811b2763>] sys_sync+0x63/0x90
        [<ffffffff815d4272>] entry_SYSCALL_64_fastpath+0x12/0x76
       Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
       RIP  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
        RSP <ffff880009f5fe68>
       CR2: 0000000000000508
       ---[ end trace 2487336ceb3de62d ]---
      
      The crash is easily reproducible by running the following command, if an
      msleep(100) is inserted before the call to func() in iterate_devs():
      
       while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done
      
      Fix it by holding the bd_mutex across the func() call and only calling
      func() if the bdev is opened.
      
      Cc: stable@vger.kernel.org
      Fixes: 5c0d6b60 ("vfs: Create function for iterating over block devices")
      Reported-and-tested-by: default avatarWei Fang <fangwei1@huawei.com>
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      73e7d7ae
    • Takashi Iwai's avatar
      ASoC: intel: Fix crash at suspend/resume without card registration · a6d0744b
      Takashi Iwai authored
      [ Upstream commit 2fc995a8 ]
      
      When ASoC Intel SST Medfield driver is probed but without codec / card
      assigned, it causes an Oops and freezes the kernel at suspend/resume,
      
       PM: Suspending system (freeze)
       Suspending console(s) (use no_console_suspend to debug)
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
       IP: [<ffffffffc09d9409>] sst_soc_prepare+0x19/0xa0 [snd_soc_sst_mfld_platform]
       Oops: 0000 [#1] PREEMPT SMP
       CPU: 0 PID: 1552 Comm: systemd-sleep Tainted: G W 4.9.0-rc6-1.g5f5c2ad-default #1
       Call Trace:
        [<ffffffffb45318f9>] dpm_prepare+0x209/0x460
        [<ffffffffb4531b61>] dpm_suspend_start+0x11/0x60
        [<ffffffffb40d3cc2>] suspend_devices_and_enter+0xb2/0x710
        [<ffffffffb40d462e>] pm_suspend+0x30e/0x390
        [<ffffffffb40d2eba>] state_store+0x8a/0x90
        [<ffffffffb43c670f>] kobj_attr_store+0xf/0x20
        [<ffffffffb42b0d97>] sysfs_kf_write+0x37/0x40
        [<ffffffffb42b02bc>] kernfs_fop_write+0x11c/0x1b0
        [<ffffffffb422be68>] __vfs_write+0x28/0x140
        [<ffffffffb43728a8>] ? apparmor_file_permission+0x18/0x20
        [<ffffffffb433b2ab>] ? security_file_permission+0x3b/0xc0
        [<ffffffffb422d095>] vfs_write+0xb5/0x1a0
        [<ffffffffb422e3d6>] SyS_write+0x46/0xa0
        [<ffffffffb4719fbb>] entry_SYSCALL_64_fastpath+0x1e/0xad
      
      Add proper NULL checks in the PM code of mdfld driver.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a6d0744b
    • Robbie Ko's avatar
      Btrfs: fix tree search logic when replaying directory entry deletes · 90604ed2
      Robbie Ko authored
      [ Upstream commit 2a7bf53f ]
      
      If a log tree has a layout like the following:
      
      leaf N:
              ...
              item 240 key (282 DIR_LOG_ITEM 0) itemoff 8189 itemsize 8
                      dir log end 1275809046
      leaf N + 1:
              item 0 key (282 DIR_LOG_ITEM 3936149215) itemoff 16275 itemsize 8
                      dir log end 18446744073709551615
              ...
      
      When we pass the value 1275809046 + 1 as the parameter start_ret to the
      function tree-log.c:find_dir_range() (done by replay_dir_deletes()), we
      end up with path->slots[0] having the value 239 (points to the last item
      of leaf N, item 240). Because the dir log item in that position has an
      offset value smaller than *start_ret (1275809046 + 1) we need to move on
      to the next leaf, however the logic for that is wrong since it compares
      the current slot to the number of items in the leaf, which is smaller
      and therefore we don't lookup for the next leaf but instead we set the
      slot to point to an item that does not exist, at slot 240, and we later
      operate on that slot which has unexpected content or in the worst case
      can result in an invalid memory access (accessing beyond the last page
      of leaf N's extent buffer).
      
      So fix the logic that checks when we need to lookup at the next leaf
      by first incrementing the slot and only after to check if that slot
      is beyond the last item of the current leaf.
      Signed-off-by: default avatarRobbie Ko <robbieko@synology.com>
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Fixes: e02119d5 (Btrfs: Add a write ahead tree log to optimize synchronous operations)
      Cc: stable@vger.kernel.org  # 2.6.29+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      [Modified changelog for clarity and correctness]
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      90604ed2
    • Robbie Ko's avatar
      Btrfs: fix deadlock caused by fsync when logging directory entries · 575b6edd
      Robbie Ko authored
      [ Upstream commit ec125cfb ]
      
      While logging new directory entries, at tree-log.c:log_new_dir_dentries(),
      after we call btrfs_search_forward() we get a leaf with a read lock on it,
      and without unlocking that leaf we can end up calling btrfs_iget() to get
      an inode pointer. The later (btrfs_iget()) can end up doing a read-only
      search on the same tree again, if the inode is not in memory already, which
      ends up causing a deadlock if some other task in the meanwhile started a
      write search on the tree and is attempting to write lock the same leaf
      that btrfs_search_forward() locked while holding write locks on upper
      levels of the tree blocking the read search from btrfs_iget(). In this
      scenario we get a deadlock.
      
      So fix this by releasing the search path before calling btrfs_iget() at
      tree-log.c:log_new_dir_dentries().
      
      Example trace of such deadlock:
      
      [ 4077.478852] kworker/u24:10  D ffff88107fc90640     0 14431      2 0x00000000
      [ 4077.486752] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
      [ 4077.494346]  ffff880ffa56bad0 0000000000000046 0000000000009000 ffff880ffa56bfd8
      [ 4077.502629]  ffff880ffa56bfd8 ffff881016ce21c0 ffffffffa06ecb26 ffff88101a5d6138
      [ 4077.510915]  ffff880ebb5173b0 ffff880ffa56baf8 ffff880ebb517410 ffff881016ce21c0
      [ 4077.519202] Call Trace:
      [ 4077.528752]  [<ffffffffa06ed5ed>] ? btrfs_tree_lock+0xdd/0x2f0 [btrfs]
      [ 4077.536049]  [<ffffffff81053680>] ? wake_up_atomic_t+0x30/0x30
      [ 4077.542574]  [<ffffffffa068cc1f>] ? btrfs_search_slot+0x79f/0xb10 [btrfs]
      [ 4077.550171]  [<ffffffffa06a5073>] ? btrfs_lookup_file_extent+0x33/0x40 [btrfs]
      [ 4077.558252]  [<ffffffffa06c600b>] ? __btrfs_drop_extents+0x13b/0xdf0 [btrfs]
      [ 4077.566140]  [<ffffffffa06fc9e2>] ? add_delayed_data_ref+0xe2/0x150 [btrfs]
      [ 4077.573928]  [<ffffffffa06fd629>] ? btrfs_add_delayed_data_ref+0x149/0x1d0 [btrfs]
      [ 4077.582399]  [<ffffffffa06cf3c0>] ? __set_extent_bit+0x4c0/0x5c0 [btrfs]
      [ 4077.589896]  [<ffffffffa06b4a64>] ? insert_reserved_file_extent.constprop.75+0xa4/0x320 [btrfs]
      [ 4077.599632]  [<ffffffffa06b206d>] ? start_transaction+0x8d/0x470 [btrfs]
      [ 4077.607134]  [<ffffffffa06bab57>] ? btrfs_finish_ordered_io+0x2e7/0x600 [btrfs]
      [ 4077.615329]  [<ffffffff8104cbc2>] ? process_one_work+0x142/0x3d0
      [ 4077.622043]  [<ffffffff8104d729>] ? worker_thread+0x109/0x3b0
      [ 4077.628459]  [<ffffffff8104d620>] ? manage_workers.isra.26+0x270/0x270
      [ 4077.635759]  [<ffffffff81052b0f>] ? kthread+0xaf/0xc0
      [ 4077.641404]  [<ffffffff81052a60>] ? kthread_create_on_node+0x110/0x110
      [ 4077.648696]  [<ffffffff814a9ac8>] ? ret_from_fork+0x58/0x90
      [ 4077.654926]  [<ffffffff81052a60>] ? kthread_create_on_node+0x110/0x110
      
      [ 4078.358087] kworker/u24:15  D ffff88107fcd0640     0 14436      2 0x00000000
      [ 4078.365981] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
      [ 4078.373574]  ffff880ffa57fad0 0000000000000046 0000000000009000 ffff880ffa57ffd8
      [ 4078.381864]  ffff880ffa57ffd8 ffff88103004d0a0 ffffffffa06ecb26 ffff88101a5d6138
      [ 4078.390163]  ffff880fbeffc298 ffff880ffa57faf8 ffff880fbeffc2f8 ffff88103004d0a0
      [ 4078.398466] Call Trace:
      [ 4078.408019]  [<ffffffffa06ed5ed>] ? btrfs_tree_lock+0xdd/0x2f0 [btrfs]
      [ 4078.415322]  [<ffffffff81053680>] ? wake_up_atomic_t+0x30/0x30
      [ 4078.421844]  [<ffffffffa068cc1f>] ? btrfs_search_slot+0x79f/0xb10 [btrfs]
      [ 4078.429438]  [<ffffffffa06a5073>] ? btrfs_lookup_file_extent+0x33/0x40 [btrfs]
      [ 4078.437518]  [<ffffffffa06c600b>] ? __btrfs_drop_extents+0x13b/0xdf0 [btrfs]
      [ 4078.445404]  [<ffffffffa06fc9e2>] ? add_delayed_data_ref+0xe2/0x150 [btrfs]
      [ 4078.453194]  [<ffffffffa06fd629>] ? btrfs_add_delayed_data_ref+0x149/0x1d0 [btrfs]
      [ 4078.461663]  [<ffffffffa06cf3c0>] ? __set_extent_bit+0x4c0/0x5c0 [btrfs]
      [ 4078.469161]  [<ffffffffa06b4a64>] ? insert_reserved_file_extent.constprop.75+0xa4/0x320 [btrfs]
      [ 4078.478893]  [<ffffffffa06b206d>] ? start_transaction+0x8d/0x470 [btrfs]
      [ 4078.486388]  [<ffffffffa06bab57>] ? btrfs_finish_ordered_io+0x2e7/0x600 [btrfs]
      [ 4078.494561]  [<ffffffff8104cbc2>] ? process_one_work+0x142/0x3d0
      [ 4078.501278]  [<ffffffff8104a507>] ? pwq_activate_delayed_work+0x27/0x40
      [ 4078.508673]  [<ffffffff8104d729>] ? worker_thread+0x109/0x3b0
      [ 4078.515098]  [<ffffffff8104d620>] ? manage_workers.isra.26+0x270/0x270
      [ 4078.522396]  [<ffffffff81052b0f>] ? kthread+0xaf/0xc0
      [ 4078.528032]  [<ffffffff81052a60>] ? kthread_create_on_node+0x110/0x110
      [ 4078.535325]  [<ffffffff814a9ac8>] ? ret_from_fork+0x58/0x90
      [ 4078.541552]  [<ffffffff81052a60>] ? kthread_create_on_node+0x110/0x110
      
      [ 4079.355824] user-space-program D ffff88107fd30640     0 32020      1 0x00000000
      [ 4079.363716]  ffff880eae8eba10 0000000000000086 0000000000009000 ffff880eae8ebfd8
      [ 4079.372003]  ffff880eae8ebfd8 ffff881016c162c0 ffffffffa06ecb26 ffff88101a5d6138
      [ 4079.380294]  ffff880fbed4b4c8 ffff880eae8eba38 ffff880fbed4b528 ffff881016c162c0
      [ 4079.388586] Call Trace:
      [ 4079.398134]  [<ffffffffa06ed595>] ? btrfs_tree_lock+0x85/0x2f0 [btrfs]
      [ 4079.405431]  [<ffffffff81053680>] ? wake_up_atomic_t+0x30/0x30
      [ 4079.411955]  [<ffffffffa06876fb>] ? btrfs_lock_root_node+0x2b/0x40 [btrfs]
      [ 4079.419644]  [<ffffffffa068ce83>] ? btrfs_search_slot+0xa03/0xb10 [btrfs]
      [ 4079.427237]  [<ffffffffa06aba52>] ? btrfs_buffer_uptodate+0x52/0x70 [btrfs]
      [ 4079.435041]  [<ffffffffa0689b60>] ? generic_bin_search.constprop.38+0x80/0x190 [btrfs]
      [ 4079.443897]  [<ffffffffa068ea44>] ? btrfs_insert_empty_items+0x74/0xd0 [btrfs]
      [ 4079.451975]  [<ffffffffa072c443>] ? copy_items+0x128/0x850 [btrfs]
      [ 4079.458890]  [<ffffffffa072da10>] ? btrfs_log_inode+0x629/0xbf3 [btrfs]
      [ 4079.466292]  [<ffffffffa06f34a1>] ? btrfs_log_inode_parent+0xc61/0xf30 [btrfs]
      [ 4079.474373]  [<ffffffffa06f45a9>] ? btrfs_log_dentry_safe+0x59/0x80 [btrfs]
      [ 4079.482161]  [<ffffffffa06c298d>] ? btrfs_sync_file+0x20d/0x330 [btrfs]
      [ 4079.489558]  [<ffffffff8112777c>] ? do_fsync+0x4c/0x80
      [ 4079.495300]  [<ffffffff81127a0a>] ? SyS_fdatasync+0xa/0x10
      [ 4079.501422]  [<ffffffff814a9b72>] ? system_call_fastpath+0x16/0x1b
      
      [ 4079.508334] user-space-program D ffff88107fc30640     0 32021      1 0x00000004
      [ 4079.516226]  ffff880eae8efbf8 0000000000000086 0000000000009000 ffff880eae8effd8
      [ 4079.524513]  ffff880eae8effd8 ffff881030279610 ffffffffa06ecb26 ffff88101a5d6138
      [ 4079.532802]  ffff880ebb671d88 ffff880eae8efc20 ffff880ebb671de8 ffff881030279610
      [ 4079.541092] Call Trace:
      [ 4079.550642]  [<ffffffffa06ed595>] ? btrfs_tree_lock+0x85/0x2f0 [btrfs]
      [ 4079.557941]  [<ffffffff81053680>] ? wake_up_atomic_t+0x30/0x30
      [ 4079.564463]  [<ffffffffa068cc1f>] ? btrfs_search_slot+0x79f/0xb10 [btrfs]
      [ 4079.572058]  [<ffffffffa06bb7d8>] ? btrfs_truncate_inode_items+0x168/0xb90 [btrfs]
      [ 4079.580526]  [<ffffffffa06b04be>] ? join_transaction.isra.15+0x1e/0x3a0 [btrfs]
      [ 4079.588701]  [<ffffffffa06b206d>] ? start_transaction+0x8d/0x470 [btrfs]
      [ 4079.596196]  [<ffffffffa0690ac6>] ? block_rsv_add_bytes+0x16/0x50 [btrfs]
      [ 4079.603789]  [<ffffffffa06bc2e9>] ? btrfs_truncate+0xe9/0x2e0 [btrfs]
      [ 4079.610994]  [<ffffffffa06bd00b>] ? btrfs_setattr+0x30b/0x410 [btrfs]
      [ 4079.618197]  [<ffffffff81117c1c>] ? notify_change+0x1dc/0x680
      [ 4079.624625]  [<ffffffff8123c8a4>] ? aa_path_perm+0xd4/0x160
      [ 4079.630854]  [<ffffffff810f4fcb>] ? do_truncate+0x5b/0x90
      [ 4079.636889]  [<ffffffff810f59fa>] ? do_sys_ftruncate.constprop.15+0x10a/0x160
      [ 4079.644869]  [<ffffffff8110d87b>] ? SyS_fcntl+0x5b/0x570
      [ 4079.650805]  [<ffffffff814a9b72>] ? system_call_fastpath+0x16/0x1b
      
      [ 4080.410607] user-space-program D ffff88107fc70640     0 32028  12639 0x00000004
      [ 4080.418489]  ffff880eaeccbbe0 0000000000000086 0000000000009000 ffff880eaeccbfd8
      [ 4080.426778]  ffff880eaeccbfd8 ffff880f317ef1e0 ffffffffa06ecb26 ffff88101a5d6138
      [ 4080.435067]  ffff880ef7e93928 ffff880f317ef1e0 ffff880eaeccbc08 ffff880f317ef1e0
      [ 4080.443353] Call Trace:
      [ 4080.452920]  [<ffffffffa06ed15d>] ? btrfs_tree_read_lock+0xdd/0x190 [btrfs]
      [ 4080.460703]  [<ffffffff81053680>] ? wake_up_atomic_t+0x30/0x30
      [ 4080.467225]  [<ffffffffa06876bb>] ? btrfs_read_lock_root_node+0x2b/0x40 [btrfs]
      [ 4080.475400]  [<ffffffffa068cc81>] ? btrfs_search_slot+0x801/0xb10 [btrfs]
      [ 4080.482994]  [<ffffffffa06b2df0>] ? btrfs_clean_one_deleted_snapshot+0xe0/0xe0 [btrfs]
      [ 4080.491857]  [<ffffffffa06a70a6>] ? btrfs_lookup_inode+0x26/0x90 [btrfs]
      [ 4080.499353]  [<ffffffff810ec42f>] ? kmem_cache_alloc+0xaf/0xc0
      [ 4080.505879]  [<ffffffffa06bd905>] ? btrfs_iget+0xd5/0x5d0 [btrfs]
      [ 4080.512696]  [<ffffffffa06caf04>] ? btrfs_get_token_64+0x104/0x120 [btrfs]
      [ 4080.520387]  [<ffffffffa06f341f>] ? btrfs_log_inode_parent+0xbdf/0xf30 [btrfs]
      [ 4080.528469]  [<ffffffffa06f45a9>] ? btrfs_log_dentry_safe+0x59/0x80 [btrfs]
      [ 4080.536258]  [<ffffffffa06c298d>] ? btrfs_sync_file+0x20d/0x330 [btrfs]
      [ 4080.543657]  [<ffffffff8112777c>] ? do_fsync+0x4c/0x80
      [ 4080.549399]  [<ffffffff81127a0a>] ? SyS_fdatasync+0xa/0x10
      [ 4080.555534]  [<ffffffff814a9b72>] ? system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarRobbie Ko <robbieko@synology.com>
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Fixes: 2f2ff0ee (Btrfs: fix metadata inconsistencies after directory fsync)
      Cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      [Modified changelog for clarity and correctness]
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      575b6edd
    • Geoff Levand's avatar
      powerpc/ps3: Fix system hang with GCC 5 builds · 32a27da2
      Geoff Levand authored
      [ Upstream commit 6dff5b67 ]
      
      GCC 5 generates different code for this bootwrapper null check that
      causes the PS3 to hang very early in its bootup. This check is of
      limited value, so just get rid of it.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGeoff Levand <geoff@infradead.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      32a27da2
    • Johan Hovold's avatar
      USB: serial: kl5kusb105: fix open error path · 07340eaf
      Johan Hovold authored
      [ Upstream commit 6774d5f5 ]
      
      Kill urbs and disable read before returning from open on failure to
      retrieve the line state.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      07340eaf
    • Krzysztof Kozlowski's avatar
      thermal: hwmon: Properly report critical temperature in sysfs · b4fa7414
      Krzysztof Kozlowski authored
      [ Upstream commit f37fabb8 ]
      
      In the critical sysfs entry the thermal hwmon was returning wrong
      temperature to the user-space.  It was reporting the temperature of the
      first trip point instead of the temperature of critical trip point.
      
      For example:
      	/sys/class/hwmon/hwmon0/temp1_crit:50000
      	/sys/class/thermal/thermal_zone0/trip_point_0_temp:50000
      	/sys/class/thermal/thermal_zone0/trip_point_0_type:active
      	/sys/class/thermal/thermal_zone0/trip_point_3_temp:120000
      	/sys/class/thermal/thermal_zone0/trip_point_3_type:critical
      
      Since commit e68b16ab ("thermal: add hwmon sysfs I/F") the driver
      have been registering a sysfs entry if get_crit_temp() callback was
      provided.  However when accessed, it was calling get_trip_temp() instead
      of the get_crit_temp().
      
      Fixes: e68b16ab ("thermal: add hwmon sysfs I/F")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b4fa7414
    • Konstantin Khlebnikov's avatar
      md/raid5: limit request size according to implementation limits · 3225aec9
      Konstantin Khlebnikov authored
      [ Upstream commit e8d7c332 ]
      
      Current implementation employ 16bit counter of active stripes in lower
      bits of bio->bi_phys_segments. If request is big enough to overflow
      this counter bio will be completed and freed too early.
      
      Fortunately this not happens in default configuration because several
      other limits prevent that: stripe_cache_size * nr_disks effectively
      limits count of active stripes. And small max_sectors_kb at lower
      disks prevent that during normal read/write operations.
      
      Overflow easily happens in discard if it's enabled by module parameter
      "devices_handle_discard_safely" and stripe_cache_size is set big enough.
      
      This patch limits requests size with 256Mb - 8Kb to prevent overflows.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Neil Brown <neilb@suse.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3225aec9
    • Yves-Alexis Perez's avatar
      firmware: fix usermode helper fallback loading · 93da0de1
      Yves-Alexis Perez authored
      [ Upstream commit 2e700f8d ]
      
      When you use the firmware usermode helper fallback with a timeout value set to a
      value greater than INT_MAX (2147483647) a cast overflow issue causes the
      timeout value to go negative and breaks all usermode helper loading. This
      regression was introduced through commit 68ff2a00 ("firmware_loader:
      handle timeout via wait_for_completion_interruptible_timeout()") on kernel
      v4.0.
      
      The firmware_class drivers relies on the firmware usermode helper
      fallback as a mechanism to look for firmware if the direct filesystem
      search failed only if:
      
        a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):
      
        Then all of these callers will rely on the fallback mechanism in case
        the firmware is not found through an initial direct filesystem lookup:
      
        o request_firmware()
        o request_firmware_into_buf()
        o request_firmware_nowait()
      
        b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):
      
        Then only callers using request_firmware_nowait() with the second
        argument set to false, this explicitly is requesting the UMH firmware
        fallback to be relied on in case the first filesystem lookup fails.
      
        Using Coccinelle SmPL grammar we have identified only two drivers
        explicitly requesting the UMH firmware fallback mechanism:
      
        - drivers/firmware/dell_rbu.c
        - drivers/leds/leds-lp55xx-common.c
      
      Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
      biggest impact of this regression are users of the dell_rbu and
      leds-lp55xx-common device driver which required the UMH to find their
      respective needed firmwares.
      
      The default timeout for the UMH is set to 60 seconds always, as of
      commit 68ff2a00 ("firmware_loader: handle timeout via
      wait_for_completion_interruptible_timeout()") the timeout was bumped
      to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
      value was also used if the timeout was configured by a user to 0.
      
      The following works:
      
      echo 2147483647 > /sys/class/firmware/timeout
      
      But both of the following set the timeout to MAX_JIFFY_OFFSET even if
      we display 0 back to userspace:
      
      echo 2147483648 > /sys/class/firmware/timeout
      cat /sys/class/firmware/timeout
      0
      
      echo 0> /sys/class/firmware/timeout
      cat /sys/class/firmware/timeout
      0
      
      A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
      another cast with simple_strtol().
      
      This fixes the secondary cast (the first one is simple_strtol() but its an
      issue only by forcing an implicit limit) by re-using the timeout variable and
      only setting retval in appropriate cases.
      
      Lastly worth noting systemd had ripped out the UMH firmware fallback
      mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
      ("udev: remove userspace firmware loading support"), so as of systemd v217.
      Signed-off-by: default avatarYves-Alexis Perez <corsac@corsac.net>
      Fixes: 68ff2a00 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
      Cc: Luis R. Rodriguez <mcgrof@kernel.org>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      [mcgrof@kernel.org: gave commit log a whole lot of love]
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      93da0de1
    • Boris Ostrovsky's avatar
      xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing · d7a1bfa5
      Boris Ostrovsky authored
      [ Upstream commit 30faaafd ]
      
      Commit 9c17d965 ("xen/gntdev: Grant maps should not be subject to
      NUMA balancing") set VM_IO flag to prevent grant maps from being
      subjected to NUMA balancing.
      
      It was discovered recently that this flag causes get_user_pages() to
      always fail with -EFAULT.
      
      check_vma_flags
      __get_user_pages
      __get_user_pages_locked
      __get_user_pages_unlocked
      get_user_pages_fast
      iov_iter_get_pages
      dio_refill_pages
      do_direct_IO
      do_blockdev_direct_IO
      do_blockdev_direct_IO
      ext4_direct_IO_read
      generic_file_read_iter
      aio_run_iocb
      
      (which can happen if guest's vdisk has direct-io-safe option).
      
      To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
      NUMA balancing just as VM_IO does and has no effect on
      check_vma_flags().
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarOlaf Hering <olaf@aepfle.de>
      Suggested-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Tested-by: default avatarOlaf Hering <olaf@aepfle.de>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d7a1bfa5
    • Jason Gunthorpe's avatar
      tpm xen: Remove bogus tpm_chip_unregister · 31541953
      Jason Gunthorpe authored
      [ Upstream commit 1f0f30e4 ]
      
      tpm_chip_unregister can only be called after tpm_chip_register.
      devm manages the allocation so no unwind is needed here.
      
      Cc: stable@vger.kernel.org
      Fixes: afb5abc2 ("tpm: two-phase chip management functions")
      Reviewed-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      31541953
    • Nicolai Stange's avatar
      f2fs: set ->owner for debugfs status file's file_operations · fee2ddae
      Nicolai Stange authored
      [ Upstream commit 05e6ea26 ]
      
      The struct file_operations instance serving the f2fs/status debugfs file
      lacks an initialization of its ->owner.
      
      This means that although that file might have been opened, the f2fs module
      can still get removed. Any further operation on that opened file, releasing
      included,  will cause accesses to unmapped memory.
      
      Indeed, Mike Marshall reported the following:
      
        BUG: unable to handle kernel paging request at ffffffffa0307430
        IP: [<ffffffff8132a224>] full_proxy_release+0x24/0x90
        <...>
        Call Trace:
         [] __fput+0xdf/0x1d0
         [] ____fput+0xe/0x10
         [] task_work_run+0x8e/0xc0
         [] do_exit+0x2ae/0xae0
         [] ? __audit_syscall_entry+0xae/0x100
         [] ? syscall_trace_enter+0x1ca/0x310
         [] do_group_exit+0x44/0xc0
         [] SyS_exit_group+0x14/0x20
         [] do_syscall_64+0x61/0x150
         [] entry_SYSCALL64_slow_path+0x25/0x25
        <...>
        ---[ end trace f22ae883fa3ea6b8 ]---
        Fixing recursive fault but reboot is needed!
      
      Fix this by initializing the f2fs/status file_operations' ->owner with
      THIS_MODULE.
      
      This will allow debugfs to grab a reference to the f2fs module upon any
      open on that file, thus preventing it from getting removed.
      
      Fixes: 902829aa ("f2fs: move proc files to debugfs")
      Reported-by: default avatarMike Marshall <hubcap@omnibond.com>
      Reported-by: default avatarMartin Brandenburg <martin@omnibond.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      fee2ddae
    • Hui Wang's avatar
      ALSA: hda - fix headset-mic problem on a Dell laptop · f52d4399
      Hui Wang authored
      [ Upstream commit 989dbe4a ]
      
      This group of new pins is not in the pin quirk table yet, adding
      them to the pin quirk table to fix the headset-mic problem.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f52d4399
    • Ondrej Kozina's avatar
      dm crypt: mark key as invalid until properly loaded · 506d7d52
      Ondrej Kozina authored
      [ Upstream commit 265e9098 ]
      
      In crypt_set_key(), if a failure occurs while replacing the old key
      (e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag
      set.  Otherwise, the crypto layer would have an invalid key that still
      has DM_CRYPT_KEY_VALID flag set.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarOndrej Kozina <okozina@redhat.com>
      Reviewed-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      506d7d52
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT · 4a703680
      Paul Mackerras authored
      [ Upstream commit f064a0de ]
      
      The hashed page table MMU in POWER processors can update the R
      (reference) and C (change) bits in a HPTE at any time until the
      HPTE has been invalidated and the TLB invalidation sequence has
      completed.  In kvmppc_h_protect, which implements the H_PROTECT
      hypercall, we read the HPTE, modify the second doubleword,
      invalidate the HPTE in memory, do the TLB invalidation sequence,
      and then write the modified value of the second doubleword back
      to memory.  In doing so we could overwrite an R/C bit update done
      by hardware between when we read the HPTE and when the TLB
      invalidation completed.  To fix this we re-read the second
      doubleword after the TLB invalidation and OR in the (possibly)
      new values of R and C.  We can use an OR since hardware only ever
      sets R and C, never clears them.
      
      This race was found by code inspection.  In principle this bug could
      cause occasional guest memory corruption under host memory pressure.
      
      Fixes: a8606e20 ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29)
      Cc: stable@vger.kernel.org # v3.19+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      4a703680
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state · ec05ce11
      Paul Mackerras authored
      [ Upstream commit 0d808df0 ]
      
      When switching from/to a guest that has a transaction in progress,
      we need to save/restore the checkpointed register state.  Although
      XER is part of the CPU state that gets checkpointed, the code that
      does this saving and restoring doesn't save/restore XER.
      
      This fixes it by saving and restoring the XER.  To allow userspace
      to read/write the checkpointed XER value, we also add a new ONE_REG
      specifier.
      
      The visible effect of this bug is that the guest may see its XER
      value being corrupted when it uses transactions.
      
      Fixes: e4e38121 ("KVM: PPC: Book3S HV: Add transactional memory support")
      Fixes: 0a8eccef ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ec05ce11
    • Theodore Ts'o's avatar
      ext4: add sanity checking to count_overhead() · b1a75800
      Theodore Ts'o authored
      [ Upstream commit c48ae41b ]
      
      The commit "ext4: sanity check the block and cluster size at mount
      time" should prevent any problems, but in case the superblock is
      modified while the file system is mounted, add an extra safety check
      to make sure we won't overrun the allocated buffer.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b1a75800
    • Theodore Ts'o's avatar
      ext4: use more strict checks for inodes_per_block on mount · 31eb998a
      Theodore Ts'o authored
      [ Upstream commit cd6bb35b ]
      
      Centralize the checks for inodes_per_block and be more strict to make
      sure the inodes_per_block_group can't end up being zero.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      31eb998a
    • Theodore Ts'o's avatar
      ext4: sanity check the block and cluster size at mount time · 526cfeda
      Theodore Ts'o authored
      [ Upstream commit 9e47a4c9 ]
      
      If the block size or cluster size is insane, reject the mount.  This
      is important for security reasons (although we shouldn't be just
      depending on this check).
      
      Ref: http://www.securityfocus.com/archive/1/539661
      Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Reported-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      526cfeda
    • Mathias Nyman's avatar
      usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices · c2404d06
      Mathias Nyman authored
      [ Upstream commit 37be6676 ]
      
      USB-3 does not have any link state that will avoid negotiating a connection
      with a plugged-in cable but will signal the host when the cable is
      unplugged.
      
      For USB-3 we used to first set the link to Disabled, then to RxDdetect to
      be able to detect cable connects or disconnects. But in RxDetect the
      connected device is detected again and eventually enabled.
      
      Instead set the link into U3 and disable remote wakeups for the device.
      This is what Windows does, and what Alan Stern suggested.
      
      Cc: stable@vger.kernel.org
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      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 avatarSasha Levin <alexander.levin@verizon.com>
      c2404d06
    • Larry Finger's avatar
      ssb: Fix error routine when fallback SPROM fails · 2861b336
      Larry Finger authored
      [ Upstream commit 8052d724 ]
      
      When there is a CRC error in the SPROM read from the device, the code
      attempts to handle a fallback SPROM. When this also fails, the driver
      returns zero rather than an error code.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2861b336
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards. · 44ef4064
      Vittorio Gambaletta (VittGam) authored
      [ Upstream commit 79e57dd1 ]
      
      The active_high LED of my Wistron DNMA-92 is still being recognized as
      active_low on 4.7.6 mainline. When I was preparing my former commit
      0f9edcdd ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
      cards.") to fix that I must have somehow messed up with testing, because
      I tested the final version of that patch before sending it, and it was
      apparently working; but now it is not working on 4.7.6 mainline.
      
      I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
      PCI_VDEVICE section for 0x0029; but then I moved the former below the
      latter after seeing how 0x002A sections were sorted in the file.
      
      This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
      both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
      specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
      match first and will be used.
      
      With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
      
      While I'm at it, let's fix 0x002A too by also moving its generic definition
      below its specific ones.
      
      Fixes: 0f9edcdd ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.")
      Cc: <stable@vger.kernel.org> #4.7+
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      [kvalo@qca.qualcomm.com: improve the commit log based on email discussions]
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      44ef4064
    • Ian Abbott's avatar
      staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask · be733405
      Ian Abbott authored
      [ Upstream commit 655c4d44 ]
      
      For NI M Series cards, the Comedi `insn_read` handler for the AI
      subdevice is broken due to ANDing the value read from the AI FIFO data
      register with an incorrect mask.  The incorrect mask clears all but the
      most significant bit of the sample data.  It should preserve all the
      sample data bits.  Correct it.
      
      Fixes: 817144ae ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'")
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      be733405
    • Chandan Rajendra's avatar
      ext4: fix stack memory corruption with 64k block size · 9d45d2e7
      Chandan Rajendra authored
      [ Upstream commit 30a9d7af ]
      
      The number of 'counters' elements needed in 'struct sg' is
      super_block->s_blocksize_bits + 2. Presently we have 16 'counters'
      elements in the array. This is insufficient for block sizes >= 32k. In
      such cases the memcpy operation performed in ext4_mb_seq_groups_show()
      would cause stack memory corruption.
      
      Fixes: c9de560dSigned-off-by: default avatarChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9d45d2e7
    • Chandan Rajendra's avatar
      ext4: fix mballoc breakage with 64k block size · d6ddc9cf
      Chandan Rajendra authored
      [ Upstream commit 69e43e8c ]
      
      'border' variable is set to a value of 2 times the block size of the
      underlying filesystem. With 64k block size, the resulting value won't
      fit into a 16-bit variable. Hence this commit changes the data type of
      'border' to 'unsigned int'.
      
      Fixes: c9de560dSigned-off-by: default avatarChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d6ddc9cf
    • Omar Sandoval's avatar
      loop: return proper error from loop_queue_rq() · b3409ef1
      Omar Sandoval authored
      [ Upstream commit b4a567e8 ]
      
      ->queue_rq() should return one of the BLK_MQ_RQ_QUEUE_* constants, not
      an errno.
      
      f4aa4c7b ("block: loop: convert to per-device workqueue")
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b3409ef1
    • Alex Porosanu's avatar
      crypto: caam - fix AEAD givenc descriptors · 9e19c284
      Alex Porosanu authored
      [ Upstream commit d128af17 ]
      
      The AEAD givenc descriptor relies on moving the IV through the
      output FIFO and then back to the CTX2 for authentication. The
      SEQ FIFO STORE could be scheduled before the data can be
      read from OFIFO, especially since the SEQ FIFO LOAD needs
      to wait for the SEQ FIFO LOAD SKIP to finish first. The
      SKIP takes more time when the input is SG than when it's
      a contiguous buffer. If the SEQ FIFO LOAD is not scheduled
      before the STORE, the DECO will hang waiting for data
      to be available in the OFIFO so it can be transferred to C2.
      In order to overcome this, first force transfer of IV to C2
      by starting the "cryptlen" transfer first and then starting to
      store data from OFIFO to the output buffer.
      
      Fixes: 1acebad3 ("crypto: caam - faster aead implementation")
      Cc: <stable@vger.kernel.org> # 3.2+
      Signed-off-by: default avatarAlex Porosanu <alexandru.porosanu@nxp.com>
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9e19c284
    • Linus Walleij's avatar
      regulator: stw481x-vmmc: fix ages old enable error · 332086b8
      Linus Walleij authored
      [ Upstream commit 295070e9 ]
      
      The regulator has never been properly enabled, it has been
      dormant all the time. It's strange that MMC was working
      at all, but it likely worked by the signals going through
      the levelshifter and reaching the card anyways.
      
      Fixes: 3615a34e ("regulator: add STw481x VMMC driver")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      332086b8
    • Alan Stern's avatar
      USB: UHCI: report non-PME wakeup signalling for Intel hardware · 9e4033f5
      Alan Stern authored
      [ Upstream commit ccdb6be9 ]
      
      The UHCI controllers in Intel chipsets rely on a platform-specific non-PME
      mechanism for wakeup signalling.  They can generate wakeup signals even
      though they don't support PME.
      
      We need to let the USB core know this so that it will enable runtime
      suspend for UHCI controllers.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9e4033f5
    • Alan Stern's avatar
      PCI: Check for PME in targeted sleep state · 257cb82e
      Alan Stern authored
      [ Upstream commit 6496ebd7 ]
      
      One some systems, the firmware does not allow certain PCI devices to be put
      in deep D-states.  This can cause problems for wakeup signalling, if the
      device does not support PME# in the deepest allowed suspend state.  For
      example, Pierre reports that on his system, ACPI does not permit his xHCI
      host controller to go into D3 during runtime suspend -- but D3 is the only
      state in which the controller can generate PME# signals.  As a result, the
      controller goes into runtime suspend but never wakes up, so it doesn't work
      properly.  USB devices plugged into the controller are never detected.
      
      If the device relies on PME# for wakeup signals but is not capable of
      generating PME# in the target state, the PCI core should accurately report
      that it cannot do wakeup from runtime suspend.  This patch modifies the
      pci_dev_run_wake() routine to add this check.
      Reported-by: default avatarPierre de Villemereuil <flyos@mailoo.org>
      Tested-by: default avatarPierre de Villemereuil <flyos@mailoo.org>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: stable@vger.kernel.org
      CC: Lukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      257cb82e
    • Kashyap Desai's avatar
      scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset · 78ef3e71
      Kashyap Desai authored
      [ Upstream commit 18e1c7f6 ]
      
      For SRIOV enabled firmware, if there is a OCR(online controller reset)
      possibility driver set the convert flag to 1, which is not happening if
      there are outstanding commands even after 180 seconds.  As driver does
      not set convert flag to 1 and still making the OCR to run, VF(Virtual
      function) driver is directly writing on to the register instead of
      waiting for 30 seconds. Setting convert flag to 1 will cause VF driver
      will wait for 30 secs before going for reset.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarKiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      78ef3e71
    • Patrik Jakobsson's avatar
      drm/gma500: Add compat ioctl · 28a8e88f
      Patrik Jakobsson authored
      [ Upstream commit 0a97c81a ]
      
      Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels.
      It turns out that N2600 and N2800 comes with 64-bit enabled. We
      previously assumed there where no such systems out there.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.comSigned-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      28a8e88f
    • Felipe Balbi's avatar
      usb: gadget: composite: correctly initialize ep->maxpacket · 6ec54b06
      Felipe Balbi authored
      [ Upstream commit e8f29bb7 ]
      
      usb_endpoint_maxp() returns wMaxPacketSize in its
      raw form. Without taking into consideration that it
      also contains other bits reserved for isochronous
      endpoints.
      
      This patch fixes one occasion where this is a
      problem by making sure that we initialize
      ep->maxpacket only with lower 10 bits of the value
      returned by usb_endpoint_maxp(). Note that seperate
      patches will be necessary to audit all call sites of
      usb_endpoint_maxp() and make sure that
      usb_endpoint_maxp() only returns lower 10 bits of
      wMaxPacketSize.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6ec54b06
    • Chris Wilson's avatar
      drm/i915: Unalias obj->phys_handle and obj->userptr · 33166482
      Chris Wilson authored
      [ Upstream commit 5f12b80a ]
      
      We use obj->phys_handle to choose the pread/pwrite path, but as
      obj->phys_handle is a union with obj->userptr, we then mistakenly use
      the phys_handle path for userptr objects within pread/pwrite.
      
      Testcase: igt/gem_userptr_blits/forbidden-operations
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-2-chris@chris-wilson.co.ukSigned-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      33166482
  2. 12 Jan, 2017 1 commit
  3. 24 Dec, 2016 1 commit
  4. 23 Dec, 2016 3 commits
    • Sumit Saxena's avatar
      scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression · c27edfb6
      Sumit Saxena authored
      [ Upstream commit 5e5ec175 ]
      
      This patch will fix regression caused by commit 1e793f6f ("scsi:
      megaraid_sas: Fix data integrity failure for JBOD (passthrough)
      devices").
      
      The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
      and as a result the driver ended up exposing a lot of non-existing SCSI
      devices (all SCSI commands to channels 1,2,3 were returned as
      SUCCESS-DID_OK by driver).
      
      [mkp: clarified patch description]
      
      Fixes: 1e793f6fReported-by: default avatarJens Axboe <axboe@kernel.dk>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarKashyap Desai <kashyap.desai@broadcom.com>
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Tested-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Tested-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c27edfb6
    • Michal Kubeček's avatar
      tipc: check minimum bearer MTU · 016d0298
      Michal Kubeček authored
      [ Upstream commit 3de81b75 ]
      
      Qian Zhang (张谦) reported a potential socket buffer overflow in
      tipc_msg_build() which is also known as CVE-2016-8632: due to
      insufficient checks, a buffer overflow can occur if MTU is too short for
      even tipc headers. As anyone can set device MTU in a user/net namespace,
      this issue can be abused by a regular user.
      
      As agreed in the discussion on Ben Hutchings' original patch, we should
      check the MTU at the moment a bearer is attached rather than for each
      processed packet. We also need to repeat the check when bearer MTU is
      adjusted to new device MTU. UDP case also needs a check to avoid
      overflow when calculating bearer MTU.
      
      References: CVE-2016-8632
      Fixes: b97bf3fd ("[TIPC] Initial merge")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Reported-by: default avatarQian Zhang (张谦) <zhangqian-c@360.cn>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      
      Conflicts:
      	net/tipc/bearer.c
      	net/tipc/bearer.h
      due to 1a90632d: tipc: eliminate remnants of hungarian notation
      and b1c29f6b tipc: simplify resetting and disabling of bearers
      Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      016d0298
    • Kees Cook's avatar
      net: ping: check minimum size on ICMP header length · efcf38bd
      Kees Cook authored
      [ Upstream commit 0eab121e ]
      
      Prior to commit c0371da6 ("put iov_iter into msghdr") in v3.19, there
      was no check that the iovec contained enough bytes for an ICMP header,
      and the read loop would walk across neighboring stack contents. Since the
      iov_iter conversion, bad arguments are noticed, but the returned error is
      EFAULT. Returning EINVAL is a clearer error and also solves the problem
      prior to v3.19.
      
      This was found using trinity with KASAN on v3.18:
      
      BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0
      Read of size 8 by task trinity-c2/9623
      page:ffffffbe034b9a08 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x0()
      page dumped because: kasan: bad access detected
      CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G    BU         3.18.0-dirty #15
      Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
      Call trace:
      [<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
      [<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
      [<     inline     >] __dump_stack lib/dump_stack.c:15
      [<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
      [<     inline     >] print_address_description mm/kasan/report.c:147
      [<     inline     >] kasan_report_error mm/kasan/report.c:236
      [<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
      [<     inline     >] check_memory_region mm/kasan/kasan.c:264
      [<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
      [<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
      [<     inline     >] memcpy_from_msg include/linux/skbuff.h:2667
      [<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
      [<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
      [<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
      [<     inline     >] __sock_sendmsg_nosec net/socket.c:624
      [<     inline     >] __sock_sendmsg net/socket.c:632
      [<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643
      [<     inline     >] SYSC_sendto net/socket.c:1797
      [<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761
      
      CVE-2016-8399
      Reported-by: default avatarQidan He <i@flanker017.me>
      Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarPhilipp Hahn <hahn@univention.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      efcf38bd