On 09/17, Aaron Tomlin wrote: > > Since do_sync_work() is a deferred function it can block indefinitely by > design. At present do_sync_work() is added to the global system_wq. > As such a deadlock is theoretically possible between sys_unmount() and > sync_filesystems(): > > * The current work fn on the system_wq (do_sync_work()) is blocked > waiting to aquire a sb's s_umount for reading. > > * The "umount" task is the current owner of the s_umount in > question but is waiting for do_sync_work() to continue. > Thus we hit a deadlock situation. > I can't comment the patches in this area, but I am just curious... Could you explain this deadlock in more details? I simply can't understand what "waiting for do_sync_work()" actually means. > This patch introduces a separate workqueue for do_sync_work() to avoid a > the described deadlock. The subject and the changelog do not match the patch, it doesn't add/use another workqueue. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
