• A
    i2c: suppress lockdep warning on delete_device · e9b526fe
    Alexander Sverdlin 提交于
    i2c: suppress lockdep warning on delete_device
    
    Since commit 846f9974 the following lockdep
    warning is thrown in case i2c device is removed (via delete_device sysfs
    attribute) which contains subdevices (e.g. i2c multiplexer):
    
    =============================================
    [ INFO: possible recursive locking detected ]
    3.8.7-0-sampleversion-fct #8 Tainted: G           O
    ---------------------------------------------
    bash/3743 is trying to acquire lock:
      (s_active#110){++++.+}, at: [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8
    
    but task is already holding lock:
      (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208
    
    other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(s_active#110);
       lock(s_active#110);
    
      *** DEADLOCK ***
    
      May be due to missing lock nesting notation
    
    4 locks held by bash/3743:
      #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff802b3c3c>] sysfs_write_file+0x4c/0x208
      #1:  (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208
      #2:  (&adap->userspace_clients_lock/1){+.+.+.}, at: [<ffffffff80454a18>] i2c_sysfs_delete_device+0x90/0x238
      #3:  (&__lockdep_no_validate__){......}, at: [<ffffffff803dcc24>] device_release_driver+0x24/0x48
    
    stack backtrace:
    Call Trace:
    [<ffffffff80575cc8>] dump_stack+0x8/0x34
    [<ffffffff801b50fc>] __lock_acquire+0x161c/0x2110
    [<ffffffff801b5c3c>] lock_acquire+0x4c/0x70
    [<ffffffff802b60cc>] sysfs_addrm_finish+0x19c/0x1e0
    [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8
    [<ffffffff802b7d8c>] sysfs_remove_group+0x64/0x148
    [<ffffffff803d990c>] device_remove_attrs+0x9c/0x1a8
    [<ffffffff803d9b1c>] device_del+0x104/0x1d8
    [<ffffffff803d9c18>] device_unregister+0x28/0x70
    [<ffffffff8045505c>] i2c_del_adapter+0x1cc/0x328
    [<ffffffff8045802c>] i2c_del_mux_adapter+0x14/0x38
    [<ffffffffc025c108>] pca954x_remove+0x90/0xe0 [pca954x]
    [<ffffffff804542f8>] i2c_device_remove+0x80/0xe8
    [<ffffffff803dca9c>] __device_release_driver+0x74/0xf8
    [<ffffffff803dcc2c>] device_release_driver+0x2c/0x48
    [<ffffffff803dbc14>] bus_remove_device+0x13c/0x1d8
    [<ffffffff803d9b24>] device_del+0x10c/0x1d8
    [<ffffffff803d9c18>] device_unregister+0x28/0x70
    [<ffffffff80454b08>] i2c_sysfs_delete_device+0x180/0x238
    [<ffffffff802b3cd4>] sysfs_write_file+0xe4/0x208
    [<ffffffff8023ddc4>] vfs_write+0xbc/0x160
    [<ffffffff8023df6c>] SyS_write+0x54/0xd8
    [<ffffffff8013d424>] handle_sys64+0x44/0x64
    
    The problem is already known for USB and PCI subsystems. The reason is that
    delete_device attribute is defined statically in i2c-core.c and used for all
    devices in i2c subsystem.
    
    Discussion of original USB problem:
    http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/01160.html
    
    Commit 356c05d5 introduced new macro to suppress
    lockdep warnings for this special case and included workaround for USB code.
    
    LKML discussion of the workaround:
    http://lkml.indiana.edu/hypermail/linux/kernel/1205.1/03634.html
    
    As i2c case is in principle the same, the same workaround could be used here.
    Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nsn.com>
    Acked-by: NAlan Stern <stern@rowland.harvard.edu>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
    e9b526fe
i2c-core.c 63.0 KB