1. 26 Jan, 2016 40 commits
    • Takashi Iwai's avatar
      ALSA: hda - Flush the pending probe work at remove · 62810ce3
      Takashi Iwai authored
      commit 991f86d7 upstream.
      
      As HD-audio driver does deferred probe internally via workqueue, the
      driver might go into the mixed state doing both probe and remove when
      the module gets unloaded during the probe work.  This eventually
      triggers an Oops, unsurprisingly.
      
      For avoiding this race, we just need to flush the pending probe work
      explicitly before actually starting the resource release.
      
      Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=960710Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      62810ce3
    • Herbert Xu's avatar
      crypto: algif_skcipher - sendmsg SG marking is off by one · 79e2ed0e
      Herbert Xu authored
      commit 202736d9 upstream.
      
      We mark the end of the SG list in sendmsg and sendpage and unmark
      it on the next send call.  Unfortunately the unmarking in sendmsg
      is off-by-one, leading to an SG list that is too short.
      
      Fixes: 0f477b65 ("crypto: algif - Mark sgl end at the end of data")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      79e2ed0e
    • Nicholas Bellinger's avatar
      iscsi-target: Fix potential dead-lock during node acl delete · 52c4e149
      Nicholas Bellinger authored
      commit 26a99c19 upstream.
      
      This patch is a iscsi-target specific bug-fix for a dead-lock
      that can occur during explicit struct se_node_acl->acl_group
      se_session deletion via configfs rmdir(2), when iscsi-target
      time2retain timer is still active.
      
      It changes iscsi-target to obtain se_portal_group->session_lock
      internally using spin_in_locked() to check for the specific
      se_node_acl configfs shutdown rmdir(2) case.
      
      Note this patch is intended for stable, and the subsequent
      v4.5-rc patch converts target_core_tpg.c to use proper
      se_sess->sess_kref reference counting for both se_node_acl
      deletion + se_node_acl->queue_depth se_session restart.
      Reported-by: default avatar: Sagi Grimberg <sagig@mellanox.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      52c4e149
    • Filipe Manana's avatar
      Btrfs: fix deadlock running delayed iputs at transaction commit time · 1d98db38
      Filipe Manana authored
      commit c2d6cb16 upstream.
      
      While running a stress test I ran into a deadlock when running the delayed
      iputs at transaction time, which produced the following report and trace:
      
      [  886.399989] =============================================
      [  886.400871] [ INFO: possible recursive locking detected ]
      [  886.401663] 4.4.0-rc6-btrfs-next-18+ #1 Not tainted
      [  886.402384] ---------------------------------------------
      [  886.403182] fio/8277 is trying to acquire lock:
      [  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
      [  886.403568]
      [  886.403568] but task is already holding lock:
      [  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
      [  886.403568]
      [  886.403568] other info that might help us debug this:
      [  886.403568]  Possible unsafe locking scenario:
      [  886.403568]
      [  886.403568]        CPU0
      [  886.403568]        ----
      [  886.403568]   lock(&fs_info->delayed_iput_sem);
      [  886.403568]   lock(&fs_info->delayed_iput_sem);
      [  886.403568]
      [  886.403568]  *** DEADLOCK ***
      [  886.403568]
      [  886.403568]  May be due to missing lock nesting notation
      [  886.403568]
      [  886.403568] 3 locks held by fio/8277:
      [  886.403568]  #0:  (sb_writers#11){.+.+.+}, at: [<ffffffff81174c4c>] __sb_start_write+0x5f/0xb0
      [  886.403568]  #1:  (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffffa054620d>] btrfs_file_write_iter+0x73/0x408 [btrfs]
      [  886.403568]  #2:  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
      [  886.403568]
      [  886.403568] stack backtrace:
      [  886.403568] CPU: 6 PID: 8277 Comm: fio Not tainted 4.4.0-rc6-btrfs-next-18+ #1
      [  886.403568] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
      [  886.403568]  0000000000000000 ffff88009f80f770 ffffffff8125d4fd ffffffff82af1fc0
      [  886.403568]  ffff88009f80f830 ffffffff8108e5f9 0000000200000000 ffff88009fd92290
      [  886.403568]  0000000000000000 ffffffff82af1fc0 ffffffff829cfb01 00042b216d008804
      [  886.403568] Call Trace:
      [  886.403568]  [<ffffffff8125d4fd>] dump_stack+0x4e/0x79
      [  886.403568]  [<ffffffff8108e5f9>] __lock_acquire+0xd42/0xf0b
      [  886.403568]  [<ffffffff810c22db>] ? __module_address+0xdf/0x108
      [  886.403568]  [<ffffffff8108eb77>] lock_acquire+0x10d/0x194
      [  886.403568]  [<ffffffff8108eb77>] ? lock_acquire+0x10d/0x194
      [  886.403568]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
      [  886.489542]  [<ffffffff8148556b>] down_read+0x3e/0x4d
      [  886.489542]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
      [  886.489542]  [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
      [  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
      [  886.489542]  [<ffffffffa0521d7a>] flush_space+0x435/0x44a [btrfs]
      [  886.489542]  [<ffffffffa052218b>] ? reserve_metadata_bytes+0x26a/0x384 [btrfs]
      [  886.489542]  [<ffffffffa05221ae>] reserve_metadata_bytes+0x28d/0x384 [btrfs]
      [  886.489542]  [<ffffffffa052256c>] ? btrfs_block_rsv_refill+0x58/0x96 [btrfs]
      [  886.489542]  [<ffffffffa0522584>] btrfs_block_rsv_refill+0x70/0x96 [btrfs]
      [  886.489542]  [<ffffffffa053d747>] btrfs_evict_inode+0x394/0x55a [btrfs]
      [  886.489542]  [<ffffffff81188e31>] evict+0xa7/0x15c
      [  886.489542]  [<ffffffff81189878>] iput+0x1d3/0x266
      [  886.489542]  [<ffffffffa053887c>] btrfs_run_delayed_iputs+0x8f/0xbf [btrfs]
      [  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
      [  886.489542]  [<ffffffff81085096>] ? signal_pending_state+0x31/0x31
      [  886.489542]  [<ffffffffa0521191>] btrfs_alloc_data_chunk_ondemand+0x1d7/0x288 [btrfs]
      [  886.489542]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
      [  886.489542]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
      [  886.489542]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
      [  886.489542]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
      [  886.489542]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
      [  886.489542]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
      [  886.489542]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
      [  886.489542]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
      [  886.489542]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
      [  886.489542]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
      [ 1081.852335] INFO: task fio:8244 blocked for more than 120 seconds.
      [ 1081.854348]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
      [ 1081.857560] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1081.863227] fio        D ffff880213f9bb28     0  8244   8240 0x00000000
      [ 1081.868719]  ffff880213f9bb28 00ffffff810fc6b0 ffffffff0000000a ffff88023ed55240
      [ 1081.872499]  ffff880206b5d400 ffff880213f9c000 ffff88020a4d5318 ffff880206b5d400
      [ 1081.876834]  ffffffff00000001 ffff880206b5d400 ffff880213f9bb40 ffffffff81482ba4
      [ 1081.880782] Call Trace:
      [ 1081.881793]  [<ffffffff81482ba4>] schedule+0x7f/0x97
      [ 1081.883340]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
      [ 1081.895525]  [<ffffffff8108d48d>] ? trace_hardirqs_on_caller+0x16/0x1ab
      [ 1081.897419]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
      [ 1081.899251]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
      [ 1081.901063]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
      [ 1081.902365]  [<ffffffff814855bd>] down_write+0x43/0x57
      [ 1081.903846]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
      [ 1081.906078]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
      [ 1081.908846]  [<ffffffff8108d461>] ? mark_held_locks+0x56/0x6c
      [ 1081.910409]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
      [ 1081.912482]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
      [ 1081.914597]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
      [ 1081.919037]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
      [ 1081.920754]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
      [ 1081.922496]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
      [ 1081.923922]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
      [ 1081.925275]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
      [ 1081.926584]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
      [ 1081.927968]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
      [ 1081.985293] INFO: lockdep is turned off.
      [ 1081.986132] INFO: task fio:8249 blocked for more than 120 seconds.
      [ 1081.987434]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
      [ 1081.988534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1081.990147] fio        D ffff880218febbb8     0  8249   8240 0x00000000
      [ 1081.991626]  ffff880218febbb8 00ffffff81486b8e ffff88020000000b ffff88023ed75240
      [ 1081.993258]  ffff8802120a9a00 ffff880218fec000 ffff88020a4d5318 ffff8802120a9a00
      [ 1081.994850]  ffffffff00000001 ffff8802120a9a00 ffff880218febbd0 ffffffff81482ba4
      [ 1081.996485] Call Trace:
      [ 1081.997037]  [<ffffffff81482ba4>] schedule+0x7f/0x97
      [ 1081.998017]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
      [ 1081.999241]  [<ffffffff810852a5>] ? finish_wait+0x6d/0x76
      [ 1082.000306]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
      [ 1082.001533]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
      [ 1082.002776]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
      [ 1082.003995]  [<ffffffff814855bd>] down_write+0x43/0x57
      [ 1082.005000]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
      [ 1082.007403]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
      [ 1082.008988]  [<ffffffffa0545064>] btrfs_fallocate+0x7c1/0xc2f [btrfs]
      [ 1082.010193]  [<ffffffff8108a1ba>] ? percpu_down_read+0x4e/0x77
      [ 1082.011280]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
      [ 1082.012265]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
      [ 1082.013021]  [<ffffffff811712e4>] vfs_fallocate+0x170/0x1ff
      [ 1082.013738]  [<ffffffff81181ebb>] ioctl_preallocate+0x89/0x9b
      [ 1082.014778]  [<ffffffff811822d7>] do_vfs_ioctl+0x40a/0x4ea
      [ 1082.015778]  [<ffffffff81176ea7>] ? SYSC_newfstat+0x25/0x2e
      [ 1082.016806]  [<ffffffff8118b4de>] ? __fget_light+0x4d/0x71
      [ 1082.017789]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
      [ 1082.018706]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
      
      This happens because we can recursively acquire the semaphore
      fs_info->delayed_iput_sem when attempting to allocate space to satisfy
      a file write request as shown in the first trace above - when committing
      a transaction we acquire (down_read) the semaphore before running the
      delayed iputs, and when running a delayed iput() we can end up calling
      an inode's eviction handler, which in turn commits another transaction
      and attempts to acquire (down_read) again the semaphore to run more
      delayed iput operations.
      This results in a deadlock because if a task acquires multiple times a
      semaphore it should invoke down_read_nested() with a different lockdep
      class for each level of recursion.
      
      Fix this by simplifying the implementation and use a mutex instead that
      is acquired by the cleaner kthread before it runs the delayed iputs
      instead of always acquiring a semaphore before delayed references are
      run from anywhere.
      
      Fixes: d7c15171 (btrfs: Fix NO_SPACE bug caused by delayed-iput)
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1d98db38
    • Josh Boyer's avatar
      ideapad-laptop: Add Lenovo ideapad Y700-17ISK to no_hw_rfkill dmi list · 74f81b87
      Josh Boyer authored
      commit edde316a upstream.
      
      One of the newest ideapad models also lacks a physical hw rfkill switch,
      and trying to read the hw rfkill switch through the ideapad module
      causes it to always reported blocking breaking wifi.
      
      Fix it by adding this model to the DMI list.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1286293Signed-off-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      74f81b87
    • Bart Van Assche's avatar
      IB/cm: Fix a recently introduced deadlock · 15236ba5
      Bart Van Assche authored
      commit 4bfdf635 upstream.
      
      ib_send_cm_drep() calls cm_enter_timewait() while holding a spinlock
      that can be locked from inside an interrupt handler. Hence do not
      enable interrupts inside cm_enter_timewait() if called with interrupts
      disabled.
      
      This patch fixes e.g. the following deadlock:
      Acked-by: default avatarErez Shitrit <erezsh@mellanox.com>
      
      =================================
      [ INFO: inconsistent lock state ]
      4.4.0-rc7+ #1 Tainted: G            E
      ---------------------------------
      inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
      swapper/8/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
      (&(&cm_id_priv->lock)->rlock){?.+...}, at: [<ffffffffa036eec4>] cm_establish+0x
      74/0x1b0 [ib_cm]
      {HARDIRQ-ON-W} state was registered at:
        [<ffffffff810a3c11>] mark_held_locks+0x71/0x90
        [<ffffffff810a3e87>] trace_hardirqs_on_caller+0xa7/0x1c0
        [<ffffffff810a3fad>] trace_hardirqs_on+0xd/0x10
        [<ffffffff8151c40b>] _raw_spin_unlock_irq+0x2b/0x40
        [<ffffffffa036ea8e>] cm_enter_timewait+0xae/0x100 [ib_cm]
        [<ffffffffa036ff76>] ib_send_cm_drep+0xb6/0x190 [ib_cm]
        [<ffffffffa052ed08>] srp_cm_handler+0x128/0x1a0 [ib_srp]
        [<ffffffffa0370340>] cm_process_work+0x20/0xf0 [ib_cm]
        [<ffffffffa0371335>] cm_dreq_handler+0x135/0x2c0 [ib_cm]
        [<ffffffffa03733c5>] cm_work_handler+0x75/0xd0 [ib_cm]
        [<ffffffff8107184d>] process_one_work+0x1bd/0x460
        [<ffffffff81073148>] worker_thread+0x118/0x420
        [<ffffffff81078454>] kthread+0xe4/0x100
        [<ffffffff8151cbbf>] ret_from_fork+0x3f/0x70
      irq event stamp: 1672286
      hardirqs last  enabled at (1672283): [<ffffffff81408ec0>] poll_idle+0x10/0x80
      hardirqs last disabled at (1672284): [<ffffffff8151d304>] common_interrupt+0x84/0x89
      softirqs last  enabled at (1672286): [<ffffffff8105b4dc>] _local_bh_enable+0x1c/0x50
      softirqs last disabled at (1672285): [<ffffffff8105b697>] irq_enter+0x47/0x70
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&cm_id_priv->lock)->rlock);
        <Interrupt>
          lock(&(&cm_id_priv->lock)->rlock);
      
       *** DEADLOCK ***
      
      no locks held by swapper/8/0.
      
      stack backtrace:
      CPU: 8 PID: 0 Comm: swapper/8 Tainted: G            E   4.4.0-rc7+ #1
      Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 11/17/2014
       ffff88045af5e950 ffff88046e503a88 ffffffff81251c1b 0000000000000007
       0000000000000006 0000000000000003 ffff88045af5ddc0 ffff88046e503ad8
       ffffffff810a32f4 0000000000000000 0000000000000000 0000000000000001
      Call Trace:
       <IRQ>  [<ffffffff81251c1b>] dump_stack+0x4f/0x74
       [<ffffffff810a32f4>] print_usage_bug+0x184/0x190
       [<ffffffff810a36e2>] mark_lock_irq+0xf2/0x290
       [<ffffffff810a3995>] mark_lock+0x115/0x1b0
       [<ffffffff810a3b8c>] mark_irqflags+0x15c/0x170
       [<ffffffff810a4fef>] __lock_acquire+0x1ef/0x560
       [<ffffffff810a53c2>] lock_acquire+0x62/0x80
       [<ffffffff8151bd33>] _raw_spin_lock_irqsave+0x43/0x60
       [<ffffffffa036eec4>] cm_establish+0x74/0x1b0 [ib_cm]
       [<ffffffffa036f031>] ib_cm_notify+0x31/0x100 [ib_cm]
       [<ffffffffa0637f24>] srpt_qp_event+0x54/0xd0 [ib_srpt]
       [<ffffffffa0196052>] mlx4_ib_qp_event+0x72/0xc0 [mlx4_ib]
       [<ffffffffa00775b9>] mlx4_qp_event+0x69/0xd0 [mlx4_core]
       [<ffffffffa006000e>] mlx4_eq_int+0x51e/0xd50 [mlx4_core]
       [<ffffffffa006084f>] mlx4_msi_x_interrupt+0xf/0x20 [mlx4_core]
       [<ffffffff810b67b0>] handle_irq_event_percpu+0x40/0x110
       [<ffffffff810b68bf>] handle_irq_event+0x3f/0x70
       [<ffffffff810ba7f9>] handle_edge_irq+0x79/0x120
       [<ffffffff81007f3d>] handle_irq+0x5d/0x130
       [<ffffffff810071fd>] do_IRQ+0x6d/0x130
       [<ffffffff8151d309>] common_interrupt+0x89/0x89
       <EOI>  [<ffffffff8140895f>] cpuidle_enter_state+0xcf/0x200
       [<ffffffff81408aa2>] cpuidle_enter+0x12/0x20
       [<ffffffff810990d6>] call_cpuidle+0x36/0x60
       [<ffffffff81099163>] cpuidle_idle_call+0x63/0x110
       [<ffffffff8109930a>] cpu_idle_loop+0xfa/0x130
       [<ffffffff8109934e>] cpu_startup_entry+0xe/0x10
       [<ffffffff8103c443>] start_secondary+0x83/0x90
      
      Fixes: commit be4b4993 ("IB/cm: Do not queue work to a device that's going away")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Erez Shitrit <erezsh@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      15236ba5
    • Leon Romanovsky's avatar
      IB/mlx5: Expose correct maximum number of CQE capacity · ff213268
      Leon Romanovsky authored
      commit 9f177686 upstream.
      
      Maximum number of EQE capacity per CQ was mistakenly exposed
      as CQE. Fix that.
      
      Fixes: 938fe83c ("net/mlx5_core: New device capabilities handling")
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ff213268
    • Vinit Agnihotri's avatar
      IB/qib: Support creating qps with GFP_NOIO flag · 2b29726e
      Vinit Agnihotri authored
      commit fbbeb863 upstream.
      
      The current code is problematic when the QP creation and ipoib is used to
      support NFS and NFS desires to do IO for paging purposes. In that case, the
      GFP_KERNEL allocation in qib_qp.c causes a deadlock in tight memory
      situations.
      
      This fix adds support to create queue pair with GFP_NOIO flag for connected
      mode only to cleanly fail the create queue pair in those situations.
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarVinit Agnihotri <vinit.abhay.agnihotri@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2b29726e
    • Mike Marciniszyn's avatar
      IB/qib: fix mcast detach when qp not attached · 334c4ae8
      Mike Marciniszyn authored
      commit 09dc9cd6 upstream.
      
      The code produces the following trace:
      
      [1750924.419007] general protection fault: 0000 [#3] SMP
      [1750924.420364] Modules linked in: nfnetlink autofs4 rpcsec_gss_krb5 nfsv4
      dcdbas rfcomm bnep bluetooth nfsd auth_rpcgss nfs_acl dm_multipath nfs lockd
      scsi_dh sunrpc fscache radeon ttm drm_kms_helper drm serio_raw parport_pc
      ppdev i2c_algo_bit lpc_ich ipmi_si ib_mthca ib_qib dca lp parport ib_ipoib
      mac_hid ib_cm i3000_edac ib_sa ib_uverbs edac_core ib_umad ib_mad ib_core
      ib_addr tg3 ptp dm_mirror dm_region_hash dm_log psmouse pps_core
      [1750924.420364] CPU: 1 PID: 8401 Comm: python Tainted: G D
      3.13.0-39-generic #66-Ubuntu
      [1750924.420364] Hardware name: Dell Computer Corporation PowerEdge
      860/0XM089, BIOS A04 07/24/2007
      [1750924.420364] task: ffff8800366a9800 ti: ffff88007af1c000 task.ti:
      ffff88007af1c000
      [1750924.420364] RIP: 0010:[<ffffffffa0131d51>] [<ffffffffa0131d51>]
      qib_mcast_qp_free+0x11/0x50 [ib_qib]
      [1750924.420364] RSP: 0018:ffff88007af1dd70  EFLAGS: 00010246
      [1750924.420364] RAX: 0000000000000001 RBX: ffff88007b822688 RCX:
      000000000000000f
      [1750924.420364] RDX: ffff88007b822688 RSI: ffff8800366c15a0 RDI:
      6764697200000000
      [1750924.420364] RBP: ffff88007af1dd78 R08: 0000000000000001 R09:
      0000000000000000
      [1750924.420364] R10: 0000000000000011 R11: 0000000000000246 R12:
      ffff88007baa1d98
      [1750924.420364] R13: ffff88003ecab000 R14: ffff88007b822660 R15:
      0000000000000000
      [1750924.420364] FS:  00007ffff7fd8740(0000) GS:ffff88007fc80000(0000)
      knlGS:0000000000000000
      [1750924.420364] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [1750924.420364] CR2: 00007ffff597c750 CR3: 000000006860b000 CR4:
      00000000000007e0
      [1750924.420364] Stack:
      [1750924.420364]  ffff88007b822688 ffff88007af1ddf0 ffffffffa0132429
      000000007af1de20
      [1750924.420364]  ffff88007baa1dc8 ffff88007baa0000 ffff88007af1de70
      ffffffffa00cb313
      [1750924.420364]  00007fffffffde88 0000000000000000 0000000000000008
      ffff88003ecab000
      [1750924.420364] Call Trace:
      [1750924.420364]  [<ffffffffa0132429>] qib_multicast_detach+0x1e9/0x350
      [ib_qib]
      [1750924.568035]  [<ffffffffa00cb313>] ? ib_uverbs_modify_qp+0x323/0x3d0
      [ib_uverbs]
      [1750924.568035]  [<ffffffffa0092d61>] ib_detach_mcast+0x31/0x50 [ib_core]
      [1750924.568035]  [<ffffffffa00cc213>] ib_uverbs_detach_mcast+0x93/0x170
      [ib_uverbs]
      [1750924.568035]  [<ffffffffa00c61f6>] ib_uverbs_write+0xc6/0x2c0 [ib_uverbs]
      [1750924.568035]  [<ffffffff81312e68>] ? apparmor_file_permission+0x18/0x20
      [1750924.568035]  [<ffffffff812d4cd3>] ? security_file_permission+0x23/0xa0
      [1750924.568035]  [<ffffffff811bd214>] vfs_write+0xb4/0x1f0
      [1750924.568035]  [<ffffffff811bdc49>] SyS_write+0x49/0xa0
      [1750924.568035]  [<ffffffff8172f7ed>] system_call_fastpath+0x1a/0x1f
      [1750924.568035] Code: 66 2e 0f 1f 84 00 00 00 00 00 31 c0 5d c3 66 2e 0f 1f
      84 00 00 00 00 00 66 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 10
      <f0> ff 8f 40 01 00 00 74 0e 48 89 df e8 8e f8 06 e1 5b 5d c3 0f
      [1750924.568035] RIP  [<ffffffffa0131d51>] qib_mcast_qp_free+0x11/0x50
      [ib_qib]
      [1750924.568035]  RSP <ffff88007af1dd70>
      [1750924.650439] ---[ end trace 73d5d4b3f8ad4851 ]
      
      The fix is to note the qib_mcast_qp that was found.   If none is found, then
      return EINVAL indicating the error.
      Reviewed-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Reported-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      334c4ae8
    • Jean Delvare's avatar
      crypto: crc32c - Fix crc32c soft dependency · 679243a7
      Jean Delvare authored
      commit fd7f6727 upstream.
      
      I don't think it makes sense for a module to have a soft dependency
      on itself. This seems quite cyclic by nature and I can't see what
      purpose it could serve.
      
      OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty
      much assumes that some incarnation of the "crc32c" hash algorithm has
      been loaded. Therefore it makes sense to have the soft dependency
      there (as crc-t10dif does.)
      
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      679243a7
    • Herbert Xu's avatar
      crypto: algif_skcipher - Load TX SG list after waiting · cf87aa5c
      Herbert Xu authored
      commit 4f0414e5 upstream.
      
      We need to load the TX SG list in sendmsg(2) after waiting for
      incoming data, not before.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cf87aa5c
    • Dave Chinner's avatar
      xfs: log mount failures don't wait for buffers to be released · 9273efcf
      Dave Chinner authored
      commit 85bec546 upstream.
      
      Recently I've been seeing xfs/051 fail on 1k block size filesystems.
      Trying to trace the events during the test lead to the problem going
      away, indicating that it was a race condition that lead to this
      ASSERT failure:
      
      XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 156
      .....
      [<ffffffff814e1257>] xfs_free_perag+0x87/0xb0
      [<ffffffff814e21b9>] xfs_mountfs+0x4d9/0x900
      [<ffffffff814e5dff>] xfs_fs_fill_super+0x3bf/0x4d0
      [<ffffffff811d8800>] mount_bdev+0x180/0x1b0
      [<ffffffff814e3ff5>] xfs_fs_mount+0x15/0x20
      [<ffffffff811d90a8>] mount_fs+0x38/0x170
      [<ffffffff811f4347>] vfs_kern_mount+0x67/0x120
      [<ffffffff811f7018>] do_mount+0x218/0xd60
      [<ffffffff811f7e5b>] SyS_mount+0x8b/0xd0
      
      When I finally caught it with tracing enabled, I saw that AG 2 had
      an elevated reference count and a buffer was responsible for it. I
      tracked down the specific buffer, and found that it was missing the
      final reference count release that would put it back on the LRU and
      hence be found by xfs_wait_buftarg() calls in the log mount failure
      handling.
      
      The last four traces for the buffer before the assert were (trimmed
      for relevance)
      
      kworker/0:1-5259   xfs_buf_iodone:        hold 2  lock 0 flags ASYNC
      kworker/0:1-5259   xfs_buf_ioerror:       hold 2  lock 0 error -5
      mount-7163	   xfs_buf_lock_done:     hold 2  lock 0 flags ASYNC
      mount-7163	   xfs_buf_unlock:        hold 2  lock 1 flags ASYNC
      
      This is an async write that is completing, so there's nobody waiting
      for it directly.  Hence we call xfs_buf_relse() once all the
      processing is complete. That does:
      
      static inline void xfs_buf_relse(xfs_buf_t *bp)
      {
      	xfs_buf_unlock(bp);
      	xfs_buf_rele(bp);
      }
      
      Now, it's clear that mount is waiting on the buffer lock, and that
      it has been released by xfs_buf_relse() and gained by mount. This is
      expected, because at this point the mount process is in
      xfs_buf_delwri_submit() waiting for all the IO it submitted to
      complete.
      
      The mount process, however, is waiting on the lock for the buffer
      because it is in xfs_buf_delwri_submit(). This waits for IO
      completion, but it doesn't wait for the buffer reference owned by
      the IO to go away. The mount process collects all the completions,
      fails the log recovery, and the higher level code then calls
      xfs_wait_buftarg() to free all the remaining buffers in the
      filesystem.
      
      The issue is that on unlocking the buffer, the scheduler has decided
      that the mount process has higher priority than the the kworker
      thread that is running the IO completion, and so immediately
      switched contexts to the mount process from the semaphore unlock
      code, hence preventing the kworker thread from finishing the IO
      completion and releasing the IO reference to the buffer.
      
      Hence by the time that xfs_wait_buftarg() is run, the buffer still
      has an active reference and so isn't on the LRU list that the
      function walks to free the remaining buffers. Hence we miss that
      buffer and continue onwards to tear down the mount structures,
      at which time we get find a stray reference count on the perag
      structure. On a non-debug kernel, this will be ignored and the
      structure torn down and freed. Hence when the kworker thread is then
      rescheduled and the buffer released and freed, it will access a
      freed perag structure.
      
      The problem here is that when the log mount fails, we still need to
      quiesce the log to ensure that the IO workqueues have returned to
      idle before we run xfs_wait_buftarg(). By synchronising the
      workqueues, we ensure that all IO completions are fully processed,
      not just to the point where buffers have been unlocked. This ensures
      we don't end up in the situation above.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9273efcf
    • Arnd Bergmann's avatar
      ARM: debug-ll: fix BCM63xx entry for multiplatform · 6773d12a
      Arnd Bergmann authored
      commit 6c548099 upstream.
      
      During my randconfig build testing, I found that a kernel with
      DEBUG_AT91_UART and ARCH_BCM_63XX fails to build:
      
      arch/arm/include/debug/at91.S:18:0: error: "CONFIG_DEBUG_UART_VIRT" redefined [-Werror]
      
      It turns out that the DEBUG_UART_BCM63XX option is enabled whenever
      the ARCH_BCM_63XX is, and that breaks multiplatform kernels because
      we then end up using the UART address from BCM63XX rather than the
      one we actually configured (if any).
      
      This changes the BCM63XX options to only have one Kconfig option,
      and only enable that if the user explicitly turns it on.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: b51312be ("ARM: BCM63XX: add low-level UART debug support")
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      6773d12a
    • Takashi Iwai's avatar
      ALSA: control: Avoid kernel warnings from tlv ioctl with numid 0 · 07c3e6b7
      Takashi Iwai authored
      commit c0bcdbdf upstream.
      
      When a TLV ioctl with numid zero is handled, the driver may spew a
      kernel warning with a stack trace at each call.  The check was
      intended obviously only for a kernel driver, but not for a user
      interaction.  Let's fix it.
      
      This was spotted by syzkaller fuzzer.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      07c3e6b7
    • Nicolas Boichat's avatar
      ALSA: seq: Fix snd_seq_call_port_info_ioctl in compat mode · cd64edfd
      Nicolas Boichat authored
      commit 9586495d upstream.
      
      This reverts one hunk of
      commit ef44a1ec ("ALSA: sound/core: use memdup_user()"), which
      replaced a number of kmalloc followed by memcpy with memdup calls.
      
      In this case, we are copying from a struct snd_seq_port_info32 to a
      struct snd_seq_port_info, but the latter is 4 bytes longer than the
      32-bit version, so we need to separate kmalloc and copy calls.
      
      Fixes: ef44a1ec ('ALSA: sound/core: use memdup_user()')
      Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cd64edfd
    • Nicolas Boichat's avatar
      ALSA: pcm: Fix snd_pcm_hw_params struct copy in compat mode · f3efb9c7
      Nicolas Boichat authored
      commit 43c54b8c upstream.
      
      This reverts one hunk of
      commit ef44a1ec ("ALSA: sound/core: use memdup_user()"), which
      replaced a number of kmalloc followed by memcpy with memdup calls.
      
      In this case, we are copying from a struct snd_pcm_hw_params32 to
      a struct snd_pcm_hw_params, but the latter is 4 bytes longer than
      the 32-bit version, so we need to separate kmalloc and copy calls.
      
      This actually leads to an out-of-bounds memory access later on
      in sound/soc/soc-pcm.c:soc_pcm_hw_params() (detected using KASan).
      
      Fixes: ef44a1ec ('ALSA: sound/core: use memdup_user()')
      Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f3efb9c7
    • Songjun Wu's avatar
      dmaengine: at_xdmac: fix resume for cyclic transfers · ac469ff8
      Songjun Wu authored
      commit 611dcadb upstream.
      
      When having cyclic transfers, the channel was paused when performing
      suspend but was not correctly resumed.
      Signed-off-by: default avatarSongjun Wu <songjun.wu@atmel.com>
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Fixes: e1f7c9ee ("dmaengine: at_xdmac: creation of the atmel
      eXtended DMA Controller driver")
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ac469ff8
    • Takashi Iwai's avatar
      ALSA: hrtimer: Fix stall by hrtimer_cancel() · b753a870
      Takashi Iwai authored
      commit 2ba1fe7a upstream.
      
      hrtimer_cancel() waits for the completion from the callback, thus it
      must not be called inside the callback itself.  This was already a
      problem in the past with ALSA hrtimer driver, and the early commit
      [fcfdebe7: ALSA: hrtimer - Fix lock-up] tried to address it.
      
      However, the previous fix is still insufficient: it may still cause a
      lockup when the ALSA timer instance reprograms itself in its callback.
      Then it invokes the start function even in snd_timer_interrupt() that
      is called in hrtimer callback itself, results in a CPU stall.  This is
      no hypothetical problem but actually triggered by syzkaller fuzzer.
      
      This patch tries to fix the issue again.  Now we call
      hrtimer_try_to_cancel() at both start and stop functions so that it
      won't fall into a deadlock, yet giving some chance to cancel the queue
      if the functions have been called outside the callback.  The proper
      hrtimer_cancel() is called in anyway at closing, so this should be
      enough.
      Reported-and-tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b753a870
    • Herbert Xu's avatar
      crypto: algif_skcipher - Fix race condition in skcipher_check_key · 1fd55b28
      Herbert Xu authored
      commit 1822793a upstream.
      
      We need to lock the child socket in skcipher_check_key as otherwise
      two simultaneous calls can cause the parent socket to be freed.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1fd55b28
    • Herbert Xu's avatar
      crypto: algif_hash - Fix race condition in hash_check_key · c0eae304
      Herbert Xu authored
      commit ad46d7e3 upstream.
      
      We need to lock the child socket in hash_check_key as otherwise
      two simultaneous calls can cause the parent socket to be freed.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c0eae304
    • Arnd Bergmann's avatar
      lib: sw842: select crc32 · 8e322fbe
      Arnd Bergmann authored
      commit 5b571677 upstream.
      
      The sw842 library code was merged in linux-4.1 and causes a very rare randconfig
      failure when CONFIG_CRC32 is not set:
      
          lib/built-in.o: In function `sw842_compress':
          oid_registry.c:(.text+0x12ddc): undefined reference to `crc32_be'
          lib/built-in.o: In function `sw842_decompress':
          oid_registry.c:(.text+0x137e4): undefined reference to `crc32_be'
      
      This adds an explict 'select CRC32' statement, similar to what the other users
      of the crc32 code have. In practice, CRC32 is always enabled anyway because
      over 100 other symbols select it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 2da572c9 ("lib: add software 842 compression/decompression")
      Acked-by: default avatarDan Streetman <ddstreet@ieee.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8e322fbe
    • Herbert Xu's avatar
      crypto: af_alg - Forbid bind(2) when nokey child sockets are present · af097589
      Herbert Xu authored
      commit a6a48c56 upstream.
      
      This patch forbids the calling of bind(2) when there are child
      sockets created by accept(2) in existence, even if they are created
      on the nokey path.
      
      This is needed as those child sockets have references to the tfm
      object which bind(2) will destroy.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      af097589
    • Herbert Xu's avatar
      crypto: algif_skcipher - Remove custom release parent function · de268e1c
      Herbert Xu authored
      commit d7b65aee upstream.
      
      This patch removes the custom release parent function as the
      generic af_alg_release_parent now works for nokey sockets too.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      de268e1c
    • Herbert Xu's avatar
      crypto: algif_hash - Remove custom release parent function · 68aefbd9
      Herbert Xu authored
      commit f1d84af1 upstream.
      
      This patch removes the custom release parent function as the
      generic af_alg_release_parent now works for nokey sockets too.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      68aefbd9
    • Herbert Xu's avatar
      crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path · c9e5b7f4
      Herbert Xu authored
      commit 6a935170 upstream.
      
      This patch allows af_alg_release_parent to be called even for
      nokey sockets.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c9e5b7f4
    • Herbert Xu's avatar
      crypto: algif_hash - Require setkey before accept(2) · 867b5898
      Herbert Xu authored
      commit 6de62f15 upstream.
      
      Hash implementations that require a key may crash if you use
      them without setting a key.  This patch adds the necessary checks
      so that if you do attempt to use them without a key that we return
      -ENOKEY instead of proceeding.
      
      This patch also adds a compatibility path to support old applications
      that do acept(2) before setkey.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      867b5898
    • Herbert Xu's avatar
      crypto: hash - Add crypto_ahash_has_setkey · ada29b97
      Herbert Xu authored
      commit a5596d63 upstream.
      
      This patch adds a way for ahash users to determine whether a key
      is required by a crypto_ahash transform.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ada29b97
    • Herbert Xu's avatar
      crypto: algif_skcipher - Add nokey compatibility path · cfc72d1e
      Herbert Xu authored
      commit a0fa2d03 upstream.
      
      This patch adds a compatibility path to support old applications
      that do acept(2) before setkey.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cfc72d1e
    • Herbert Xu's avatar
      crypto: af_alg - Add nokey compatibility path · 169a184a
      Herbert Xu authored
      commit 37766586 upstream.
      
      This patch adds a compatibility path to support old applications
      that do acept(2) before setkey.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      169a184a
    • Herbert Xu's avatar
      crypto: af_alg - Fix socket double-free when accept fails · 9942c446
      Herbert Xu authored
      commit a383292c upstream.
      
      When we fail an accept(2) call we will end up freeing the socket
      twice, once due to the direct sk_free call and once again through
      newsock.
      
      This patch fixes this by removing the sk_free call.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9942c446
    • Herbert Xu's avatar
      crypto: af_alg - Disallow bind/setkey/... after accept(2) · 15c9658b
      Herbert Xu authored
      commit c840ac6a upstream.
      
      Each af_alg parent socket obtained by socket(2) corresponds to a
      tfm object once bind(2) has succeeded.  An accept(2) call on that
      parent socket creates a context which then uses the tfm object.
      
      Therefore as long as any child sockets created by accept(2) exist
      the parent socket must not be modified or freed.
      
      This patch guarantees this by using locks and a reference count
      on the parent socket.  Any attempt to modify the parent socket will
      fail with EBUSY.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      15c9658b
    • Herbert Xu's avatar
      crypto: algif_skcipher - Require setkey before accept(2) · f3d74470
      Herbert Xu authored
      commit dd504589 upstream.
      
      Some cipher implementations will crash if you try to use them
      without calling setkey first.  This patch adds a check so that
      the accept(2) call will fail with -ENOKEY if setkey hasn't been
      done on the socket yet.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      [ kamal: backport to 4.2-stable: crypto_alloc_ablkcipher API ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f3d74470
    • Takashi Iwai's avatar
      ALSA: hda - Fix bass pin fixup for ASUS N550JX · 425552b0
      Takashi Iwai authored
      commit db8948e6 upstream.
      
      ASUS N550JX (PCI SSID 1043:13df) requires the same fixup for a bass
      speaker output pin as other N550 models.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110001Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      425552b0
    • Tejun Heo's avatar
      printk: do cond_resched() between lines while outputting to consoles · 8e78fe16
      Tejun Heo authored
      commit 8d91f8b1 upstream.
      
      @console_may_schedule tracks whether console_sem was acquired through
      lock or trylock.  If the former, we're inside a sleepable context and
      console_conditional_schedule() performs cond_resched().  This allows
      console drivers which use console_lock for synchronization to yield
      while performing time-consuming operations such as scrolling.
      
      However, the actual console outputting is performed while holding
      irq-safe logbuf_lock, so console_unlock() clears @console_may_schedule
      before starting outputting lines.  Also, only a few drivers call
      console_conditional_schedule() to begin with.  This means that when a
      lot of lines need to be output by console_unlock(), for example on a
      console registration, the task doing console_unlock() may not yield for
      a long time on a non-preemptible kernel.
      
      If this happens with a slow console devices, for example a serial
      console, the outputting task may occupy the cpu for a very long time.
      Long enough to trigger softlockup and/or RCU stall warnings, which in
      turn pile more messages, sometimes enough to trigger the next cycle of
      warnings incapacitating the system.
      
      Fix it by making console_unlock() insert cond_resched() between lines if
      @console_may_schedule.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarCalvin Owens <calvinowens@fb.com>
      Acked-by: default avatarJan Kara <jack@suse.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Kyle McMartin <kyle@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8e78fe16
    • Vitaly Kuznetsov's avatar
      kernel/panic.c: turn off locks debug before releasing console lock · 0a50f55b
      Vitaly Kuznetsov authored
      commit 7625b3a0 upstream.
      
      Commit 08d78658 ("panic: release stale console lock to always get the
      logbuf printed out") introduced an unwanted bad unlock balance report when
      panic() is called directly and not from OOPS (e.g.  from out_of_memory()).
      The difference is that in case of OOPS we disable locks debug in
      oops_enter() and on direct panic call nobody does that.
      
      Fixes: 08d78658 ("panic: release stale console lock to always get the logbuf printed out")
      Reported-by: default avatarkernel test robot <ying.huang@linux.intel.com>
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Xie XiuQi <xiexiuqi@huawei.com>
      Cc: Seth Jennings <sjenning@redhat.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ kamal: 4.2-stable prereq for
        8d91f8b1 printk: do cond_resched() between lines while outputting to consoles ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0a50f55b
    • Vitaly Kuznetsov's avatar
      panic: release stale console lock to always get the logbuf printed out · 2716163d
      Vitaly Kuznetsov authored
      commit 08d78658 upstream.
      
      In some cases we may end up killing the CPU holding the console lock
      while still having valuable data in logbuf. E.g. I'm observing the
      following:
      
      - A crash is happening on one CPU and console_unlock() is being called on
        some other.
      
      - console_unlock() tries to print out the buffer before releasing the lock
        and on slow console it takes time.
      
      - in the meanwhile crashing CPU does lots of printk()-s with valuable data
        (which go to the logbuf) and sends IPIs to all other CPUs.
      
      - console_unlock() finishes printing previous chunk and enables interrupts
        before trying to print out the rest, the CPU catches the IPI and never
        releases console lock.
      
      This is not the only possible case: in VT/fb subsystems we have many other
      console_lock()/console_unlock() users.  Non-masked interrupts (or
      receiving NMI in case of extreme slowness) will have the same result.
      Getting the whole console buffer printed out on crash should be top
      priority.
      
      [akpm@linux-foundation.org: tweak comment text]
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Xie XiuQi <xiexiuqi@huawei.com>
      Cc: Seth Jennings <sjenning@redhat.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ kamal: 4.2-stable prereq for
        8d91f8b1 printk: do cond_resched() between lines while outputting to consoles ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2716163d
    • Martijn Coenen's avatar
      memcg: only free spare array when readers are done · 65f46bf6
      Martijn Coenen authored
      commit 6611d8d7 upstream.
      
      A spare array holding mem cgroup threshold events is kept around to make
      sure we can always safely deregister an event and have an array to store
      the new set of events in.
      
      In the scenario where we're going from 1 to 0 registered events, the
      pointer to the primary array containing 1 event is copied to the spare
      slot, and then the spare slot is freed because no events are left.
      However, it is freed before calling synchronize_rcu(), which means
      readers may still be accessing threshold->primary after it is freed.
      
      Fixed by only freeing after synchronize_rcu().
      Signed-off-by: default avatarMartijn Coenen <maco@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      65f46bf6
    • Jerome Marchand's avatar
      zram: don't call idr_remove() from zram_remove() · 133c5bd1
      Jerome Marchand authored
      commit 17ec4cd9 upstream.
      
      The use of idr_remove() is forbidden in the callback functions of
      idr_for_each().  It is therefore unsafe to call idr_remove in
      zram_remove().
      
      This patch moves the call to idr_remove() from zram_remove() to
      hot_remove_store().  In the detroy_devices() path, idrs are removed by
      idr_destroy().  This solves an use-after-free detected by KASan.
      
      [akpm@linux-foundation.org: fix coding stype, per Sergey]
      Signed-off-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Acked-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      133c5bd1
    • Naoya Horiguchi's avatar
      mm: soft-offline: check return value in second __get_any_page() call · 7e7fa2a6
      Naoya Horiguchi authored
      commit d96b339f upstream.
      
      I saw the following BUG_ON triggered in a testcase where a process calls
      madvise(MADV_SOFT_OFFLINE) on thps, along with a background process that
      calls migratepages command repeatedly (doing ping-pong among different
      NUMA nodes) for the first process:
      
         Soft offlining page 0x60000 at 0x700000600000
         __get_any_page: 0x60000 free buddy page
         page:ffffea0001800000 count:0 mapcount:-127 mapping:          (null) index:0x1
         flags: 0x1fffc0000000000()
         page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
         ------------[ cut here ]------------
         kernel BUG at /src/linux-dev/include/linux/mm.h:342!
         invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
         Modules linked in: cfg80211 rfkill crc32c_intel serio_raw virtio_balloon i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi
         CPU: 3 PID: 3035 Comm: test_alloc_gene Tainted: G           O    4.4.0-rc8-v4.4-rc8-160107-1501-00000-rc8+ #74
         Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
         task: ffff88007c63d5c0 ti: ffff88007c210000 task.ti: ffff88007c210000
         RIP: 0010:[<ffffffff8118998c>]  [<ffffffff8118998c>] put_page+0x5c/0x60
         RSP: 0018:ffff88007c213e00  EFLAGS: 00010246
         Call Trace:
           put_hwpoison_page+0x4e/0x80
           soft_offline_page+0x501/0x520
           SyS_madvise+0x6bc/0x6f0
           entry_SYSCALL_64_fastpath+0x12/0x6a
         Code: 8b fc ff ff 5b 5d c3 48 89 df e8 b0 fa ff ff 48 89 df 31 f6 e8 c6 7d ff ff 5b 5d c3 48 c7 c6 08 54 a2 81 48 89 df e8 a4 c5 01 00 <0f> 0b 66 90 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b 47
         RIP  [<ffffffff8118998c>] put_page+0x5c/0x60
          RSP <ffff88007c213e00>
      
      The root cause resides in get_any_page() which retries to get a refcount
      of the page to be soft-offlined.  This function calls
      put_hwpoison_page(), expecting that the target page is putback to LRU
      list.  But it can be also freed to buddy.  So the second check need to
      care about such case.
      
      Fixes: af8fae7c ("mm/memory-failure.c: clean up soft_offline_page()")
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7e7fa2a6
    • Hans de Goede's avatar
      ACPI / video: Add disable_backlight_sysfs_if quirk for the Toshiba Satellite R830 · 7049428f
      Hans de Goede authored
      commit b21f2e81 upstream.
      
      The Toshiba Satellite R830 needs disable_backlight_sysfs_if=1, just like
      the Toshiba Portege R830. Add a quirk for this.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=21012Tested-by: default avatarTo Do <entodoays@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7049428f