> On 19. Aug 2018, at 20:30, David Holland <dholland-t...@netbsd.org> wrote: > > On Thu, Aug 16, 2018 at 10:03:11AM +0200, J. Hannken-Illjes wrote: >>> sleepq_block >>> cv_wait >>> fstrans_start >>> VOP_BWRITE >>> getnewbuf >>> getblk >>> bio_doread >>> bread >>> ffs_update.part.3 >>> ffs_sync >>> VFS_SYNC >>> sched_sync >>> >>> If I understand correctly, that means a n I/O that never completed, right? >> >> Looks like a deadlock where we sync a file system, need a new buffer >> and try to free a buffer on a currently suspending file system. >> >> VFS_SYNC and VOP_BWRITE should be on different mounts here. > > Side note: what if there isn't a second mount? Not sure that's a good > enough way to deal with this case...
This is just a guess -- if they were from the same mount sched_sync() did already call fstrans_start() through mountlist_iterator_trynext() and VOP_BWRITE would not sleep on fstrans_start() as it always succeeds on recursion. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)