1. 14 7月, 2016 8 次提交
  2. 09 7月, 2016 14 次提交
  3. 22 6月, 2016 1 次提交
  4. 07 5月, 2016 5 次提交
  5. 11 3月, 2016 1 次提交
  6. 05 3月, 2016 1 次提交
  7. 03 3月, 2016 5 次提交
  8. 01 3月, 2016 2 次提交
  9. 16 2月, 2016 1 次提交
    • M
      [media] rc-core: don't lock device at rc_register_device() · c73bbaa4
      Mauro Carvalho Chehab 提交于
      The mutex lock at rc_register_device() was added by commit 08aeb7c9
      ("[media] rc: add locking to fix register/show race").
      
      It is meant to avoid race issues when trying to open a sysfs file while
      the RC register didn't complete.
      
      Adding a lock there causes troubles, as detected by the Kernel lock
      debug instrumentation at the Kernel:
      
          ======================================================
          [ INFO: possible circular locking dependency detected ]
          4.5.0-rc3+ #46 Not tainted
          -------------------------------------------------------
          systemd-udevd/2681 is trying to acquire lock:
           (s_active#171){++++.+}, at: [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0
      
          but task is already holding lock:
           (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]
      
          which lock already depends on the new lock.
      
          the existing dependency chain (in reverse order) is:
      
          -> #1 (&dev->lock){+.+.+.}:
                 [<ffffffff8124817d>] lock_acquire+0x13d/0x320
                 [<ffffffff822de966>] mutex_lock_nested+0xb6/0x860
                 [<ffffffffa0721f2b>] show_protocols+0x3b/0x3f0 [rc_core]
                 [<ffffffff81cdaba5>] dev_attr_show+0x45/0xc0
                 [<ffffffff8171f1b3>] sysfs_kf_seq_show+0x203/0x3c0
                 [<ffffffff8171a6a1>] kernfs_seq_show+0x121/0x1b0
                 [<ffffffff81617c71>] seq_read+0x2f1/0x1160
                 [<ffffffff8171c911>] kernfs_fop_read+0x321/0x460
                 [<ffffffff815abc20>] __vfs_read+0xe0/0x3d0
                 [<ffffffff815ae90e>] vfs_read+0xde/0x2d0
                 [<ffffffff815b1d01>] SyS_read+0x111/0x230
                 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76
      
          -> #0 (s_active#171){++++.+}:
                 [<ffffffff81244f24>] __lock_acquire+0x4304/0x5990
                 [<ffffffff8124817d>] lock_acquire+0x13d/0x320
                 [<ffffffff81717d3a>] __kernfs_remove+0x58a/0x810
                 [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0
                 [<ffffffff81721592>] remove_files.isra.0+0x72/0x190
                 [<ffffffff8172174b>] sysfs_remove_group+0x9b/0x150
                 [<ffffffff81721854>] sysfs_remove_groups+0x54/0xa0
                 [<ffffffff81cd97d0>] device_remove_attrs+0xb0/0x140
                 [<ffffffff81cdb27c>] device_del+0x38c/0x6b0
                 [<ffffffffa0724b8b>] rc_register_device+0x8cb/0x1450 [rc_core]
                 [<ffffffffa1326a7b>] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb]
                 [<ffffffffa1321c81>] dvb_usb_device_init+0xf21/0x1860 [dvb_usb]
                 [<ffffffffa13517dc>] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700]
                 [<ffffffff81dbb1dd>] usb_probe_interface+0x45d/0x940
                 [<ffffffff81ce7e7a>] driver_probe_device+0x21a/0xc30
                 [<ffffffff81ce89b1>] __driver_attach+0x121/0x160
                 [<ffffffff81ce21bf>] bus_for_each_dev+0x11f/0x1a0
                 [<ffffffff81ce6cdd>] driver_attach+0x3d/0x50
                 [<ffffffff81ce5df9>] bus_add_driver+0x4c9/0x770
                 [<ffffffff81cea39c>] driver_register+0x18c/0x3b0
                 [<ffffffff81db6e98>] usb_register_driver+0x1f8/0x440
                 [<ffffffffa074001e>] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700]
                 [<ffffffff810021b1>] do_one_initcall+0x141/0x300
                 [<ffffffff8144d8eb>] do_init_module+0x1d0/0x5ad
                 [<ffffffff812f27b6>] load_module+0x6666/0x9ba0
                 [<ffffffff812f5fe8>] SyS_finit_module+0x108/0x130
                 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76
      
          other info that might help us debug this:
      
           Possible unsafe locking scenario:
      
                 CPU0                    CPU1
                 ----                    ----
            lock(&dev->lock);
                                         lock(s_active#171);
                                         lock(&dev->lock);
            lock(s_active#171);
      
           *** DEADLOCK ***
      
          3 locks held by systemd-udevd/2681:
           #0:  (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160
           #1:  (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160
           #2:  (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]
      
      In this specific case, some error happened during device init,
      causing IR to be disabled.
      
      Let's fix it by adding a var that will tell when the device is
      initialized. Any calls before that will return a -EINVAL.
      
      That should prevent the race issues.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      c73bbaa4
  10. 03 2月, 2016 2 次提交