Since commit 0f9548ca1 ("lockdep: check that no locks held at freeze
time") I see the following backtrace in the file storage gadget [0]:
|=====================================
|[ BUG: file-storage/662 still has locks held! ]
|3.12.0-rc4+ #2 Not tainted
|-------------------------------------
|1 lock held by file-storage/662:
| #0: (&common->file_lock){+.+...}, at: [<f84cf3af>]
fsg_main_thread+0x34f/0x14b0 [g_multi]
|
|Call Trace:
| [<c14ef9c9>] dump_stack+0x4b/0x79
| [<c10a2ca1>] debug_check_no_locks_held+0x91/0xa0
| [<f84ce1b9>] sleep_thread.isra.29+0x79/0xc0 [g_multi]
| [<f84ceb53>] do_write+0x213/0x440 [g_multi]
| [<f84cf715>] fsg_main_thread+0x6b5/0x14b0 [g_multi]
The lock acquired in do_scsi_command() and do_write() calls sleep_thread()
until date is written (I guess).
Any recommendations on getting rid of this? Should sleep_thread() skip
calling try_to_freeze() if the lock is held and "just" scheduling away?
[0] drivers/usb/gadget/f_mass_storage.c
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
