1. 21 12月, 2013 1 次提交
  2. 20 12月, 2013 3 次提交
  3. 19 12月, 2013 1 次提交
    • C
      TTY/n_gsm: Removing the wrong tty_unlock/lock() in gsm_dlci_release() · be706572
      Chuansheng Liu 提交于
      Commit 4d9b1090(tty: Prevent deadlock in n_gsm driver)
      tried to close all the virtual ports synchronously before closing the
      phycial ports, so the tty_vhangup() is used.
      
      But the tty_unlock/lock() is wrong:
      tty_release
       tty_ldisc_release
        tty_lock_pair(tty, o_tty)  < == Here the tty is for physical port
        tty_ldisc_kill
          gsmld_close
            gsm_cleanup_mux
              gsm_dlci_release
                tty = tty_port_tty_get(&dlci->port)
                                  < == Here the tty(s) are for virtual port
      
      They are different ttys, so before tty_vhangup(virtual tty), do not need
      to call the tty_unlock(virtual tty) at all which causes unbalanced unlock
      warning.
      
      When enabling mutex debugging option, we will hit the below warning also:
      [   99.276903] =====================================
      [   99.282172] [ BUG: bad unlock balance detected! ]
      [   99.287442] 3.10.20-261976-gaec5ba0 #44 Tainted: G           O
      [   99.293972] -------------------------------------
      [   99.299240] mmgr/152 is trying to release lock (&tty->legacy_mutex) at:
      [   99.306693] [<c1b2dcad>] mutex_unlock+0xd/0x10
      [   99.311669] but there are no more locks to release!
      [   99.317131]
      [   99.317131] other info that might help us debug this:
      [   99.324440] 3 locks held by mmgr/152:
      [   99.328542]  #0:  (&tty->legacy_mutex/1){......}, at: [<c1b30ab0>] tty_lock_nested+0x40/0x90
      [   99.338116]  #1:  (&tty->ldisc_mutex){......}, at: [<c15dbd02>] tty_ldisc_kill+0x22/0xd0
      [   99.347284]  #2:  (&gsm->mutex){......}, at: [<c15e3d83>] gsm_cleanup_mux+0x73/0x170
      [   99.356060]
      [   99.356060] stack backtrace:
      [   99.360932] CPU: 0 PID: 152 Comm: mmgr Tainted: G           O 3.10.20-261976-gaec5ba0 #44
      [   99.370086]  ef4a4de0 ef4a4de0 ef4c1d98 c1b27b91 ef4c1db8 c1292655 c1dd10f5 c1b2dcad
      [   99.378921]  c1b2dcad ef4a4de0 ef4a528c ffffffff ef4c1dfc c12930dd 00000246 00000000
      [   99.387754]  00000000 00000000 c15e1926 00000000 00000001 ddfa7530 00000003 c1b2dcad
      [   99.396588] Call Trace:
      [   99.399326]  [<c1b27b91>] dump_stack+0x16/0x18
      [   99.404307]  [<c1292655>] print_unlock_imbalance_bug+0xe5/0xf0
      [   99.410840]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
      [   99.416110]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
      [   99.421382]  [<c12930dd>] lock_release_non_nested+0x1cd/0x210
      [   99.427818]  [<c15e1926>] ? gsm_destroy_network+0x36/0x130
      [   99.433964]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
      [   99.439235]  [<c12931a2>] lock_release+0x82/0x1c0
      [   99.444505]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
      [   99.449776]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
      [   99.455047]  [<c1b2dc2f>] __mutex_unlock_slowpath+0x5f/0xd0
      [   99.461288]  [<c1b2dcad>] mutex_unlock+0xd/0x10
      [   99.466365]  [<c1b30bb1>] tty_unlock+0x21/0x50
      [   99.471345]  [<c15e3dd1>] gsm_cleanup_mux+0xc1/0x170
      [   99.476906]  [<c15e44d2>] gsmld_close+0x52/0x90
      [   99.481983]  [<c15db905>] tty_ldisc_close.isra.1+0x35/0x50
      [   99.488127]  [<c15dbd0c>] tty_ldisc_kill+0x2c/0xd0
      [   99.493494]  [<c15dc7af>] tty_ldisc_release+0x2f/0x50
      [   99.499152]  [<c15d572c>] tty_release+0x37c/0x4b0
      [   99.504424]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
      [   99.509695]  [<c1b2dcad>] ? mutex_unlock+0xd/0x10
      [   99.514967]  [<c1372f6e>] ? eventpoll_release_file+0x7e/0x90
      [   99.521307]  [<c1335849>] __fput+0xd9/0x200
      [   99.525996]  [<c133597d>] ____fput+0xd/0x10
      [   99.530685]  [<c125c731>] task_work_run+0x81/0xb0
      [   99.535957]  [<c12019e9>] do_notify_resume+0x49/0x70
      [   99.541520]  [<c1b30dc4>] work_notifysig+0x29/0x31
      [   99.546897] ------------[ cut here ]------------
      
      So here we can call tty_vhangup() directly which is for virtual port.
      Reviewed-by: NChao Bi <chao.bi@intel.com>
      Signed-off-by: NLiu, Chuansheng <chuansheng.liu@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be706572
  4. 18 12月, 2013 10 次提交
  5. 16 12月, 2013 2 次提交
    • M
      null_blk: mem garbage on NUMA systems during init · 57053d8c
      Matias Bjorling 提交于
      For NUMA systems, initializing the blk-mq layer and using per node hctx.
      We initialize submit queues to 1, while blk-mq nr_hw_queues is
      initialized to the number of NUMA nodes.
      
      This makes the null_init_hctx function overwrite memory outside of what
      it allocated.  In my case it lead to writing garbage into struct
      request_queue's mq_map.
      Signed-off-by: NMatias Bjorling <m@bjorling.me>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57053d8c
    • S
      radeon_pm: fix oops in hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh() · e4158f1b
      Sergey Senozhatsky 提交于
      Since commit ec39f64b ("drm/radeon/dpm: Convert to use
      devm_hwmon_register_with_groups") radeon_hwmon_init() is using
      hwmon_device_register_with_groups(), which sets `rdev' as a device
      private driver_data, while hwmon_attributes_visible() and
      radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'.
      
      Fix them by using dev_get_drvdata(), in order to avoid this oops:
      
        BUG: unable to handle kernel paging request at 0000000000001e28
        IP: [<ffffffffa02ae8b4>] hwmon_attributes_visible+0x18/0x3d [radeon]
        PGD 15057e067 PUD 151a8e067 PMD 0
        Oops: 0000 [#1] PREEMPT SMP
        Call Trace:
          internal_create_group+0x114/0x1d9
          sysfs_create_group+0xe/0x10
          sysfs_create_groups+0x22/0x5f
          device_add+0x34f/0x501
          device_register+0x15/0x18
          hwmon_device_register_with_groups+0xb5/0xed
          radeon_hwmon_init+0x56/0x7c [radeon]
          radeon_pm_init+0x134/0x7e5 [radeon]
          radeon_modeset_init+0x75f/0x8ed [radeon]
          radeon_driver_load_kms+0xc6/0x187 [radeon]
          drm_dev_register+0xf9/0x1b4 [drm]
          drm_get_pci_dev+0x98/0x129 [drm]
          radeon_pci_probe+0xa3/0xac [radeon]
          pci_device_probe+0x6e/0xcf
          driver_probe_device+0x98/0x1c4
          __driver_attach+0x5c/0x7e
          bus_for_each_dev+0x7b/0x85
          driver_attach+0x19/0x1b
          bus_add_driver+0x104/0x1ce
          driver_register+0x89/0xc5
          __pci_register_driver+0x58/0x5b
          drm_pci_init+0x86/0xea [drm]
          radeon_init+0x97/0x1000 [radeon]
          do_one_initcall+0x7f/0x117
          load_module+0x1583/0x1bb4
          SyS_init_module+0xa0/0xaf
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Alexander Deucher <Alexander.Deucher@amd.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4158f1b
  6. 15 12月, 2013 2 次提交
  7. 14 12月, 2013 2 次提交
    • J
      dm array: fix a reference counting bug in shadow_ablock · ed9571f0
      Joe Thornber 提交于
      An old array block could have its reference count decremented below
      zero when it is being replaced in the btree by a new array block.
      
      The fix is to increment the old ablock's reference count just before
      inserting a new ablock into the btree.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.9+
      ed9571f0
    • J
      dm space map: disallow decrementing a reference count below zero · 5b564d80
      Joe Thornber 提交于
      The old behaviour, returning -EINVAL if a ref_count of 0 would be
      decremented, was removed in commit f722063e ("dm space map: optimise
      sm_ll_dec and sm_ll_inc").  To fix this regression we return an error
      code from the mutator function pointer passed to sm_ll_mutate() and have
      dec_ref_count() return -EINVAL if the old ref_count is 0.
      
      Add a DMERR to reflect the potential seriousness of this error.
      
      Also, add missing dm_tm_unlock() to sm_ll_mutate()'s error path.
      
      With this fix the following dmts regression test now passes:
       dmtest run --suite cache -n /metadata_use_kernel/
      
      The next patch fixes the higher-level dm-array code that exposed this
      regression.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.12+
      5b564d80
  8. 13 12月, 2013 14 次提交
  9. 12 12月, 2013 5 次提交