On Sat, 2017-10-21 at 17:59 +0000, Bart Van Assche wrote: > On Sat, 2017-10-21 at 19:21 +0200, Oleksandr Natalenko wrote: > > I've cherry-picked this series for current upstream/master branch, and got > > this while performing another suspend try: > > > > === > > [ 62.415890] Freezing of tasks failed after 20.007 seconds (1 tasks refusing > > to freeze, wq_busy=0): > > [ 62.421150] xfsaild/dm-7 D 0 289 2 0x80000000 > > [ 62.425800] Call Trace: > > [ 62.428902] __schedule+0x239/0x870 > > [ 62.431834] schedule+0x33/0x90 > > [ 62.434156] _xfs_log_force+0x143/0x280 [xfs] > > [ 62.438767] ? schedule_timeout+0x188/0x390 > > [ 62.443592] ? wake_up_q+0x80/0x80 > > [ 62.446545] ? xfsaild+0x18d/0x780 [xfs] > > [ 62.449702] xfs_log_force+0x2c/0x90 [xfs] > > [ 62.453217] xfsaild+0x18d/0x780 [xfs] > > [ 62.456717] kthread+0x124/0x140 > > [ 62.459237] ? kthread+0x124/0x140 > > [ 62.461818] ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs] > > [ 62.465146] ? kthread_create_on_node+0x70/0x70 > > [ 62.467331] ret_from_fork+0x25/0x30 > > [ 62.474386] Restarting kernel threads ... done. > > === > > Thank you for having tested v10 of this patch series. This patch series only > changes the behavior of suspending devices but not the behavior of freezing > the XFS kernel threads. During suspend task freezing occurs *before* > suspending devices. In other words, the lockup occurred before the code was > reached that is modified by this patch series. So I think you ran into a bug > in the XFS code and not into a bug in this patch series. On second thought, I want to take back what I wrote about XFS. Since xfsaild() can submit I/O, what may have happened is that the md kernel thread got frozen before the XFS kernel thread. I will see what I can do to avoid freeze failures like the one you reported. Bart.
