vn_start_write(9) recursion ?

[Kostik Belousov]

On Fri, Apr 28, 2006 at 04:23:49PM +0200, Pawel Jakub Dawidek wrote:
> On Fri, Apr 28, 2006 at 05:16:17PM +0300, Kostik Belousov wrote:
> +> On Fri, Apr 28, 2006 at 04:02:05PM +0200, Pawel Jakub Dawidek wrote:
> +> > On Fri, Apr 28, 2006 at 03:08:55PM +0300, Kostik Belousov wrote:
> +> > +> vn_start_write(9) shall not be called recursively (at least, not without
> +> > +> V_NOWAIT flag). Otherwise, system may deadlock if vn_write_suspend(9)
> +> > +> is called between.
> +> > 
> +> > Yes, you are right. Nice catch, actually.
> +> > 
> +> > I hacked this patch to detect it:
> +> > 
> +> > 	http://people.freebsd.org/~pjd/patches/vn_start_write_recursion.patch
> +> > 
> +> > And it panics on boot.
> +> 
> +> Incredible ! Please, commit it !
> 
> Not sure if this is good idea to abuse td_pflags for debugging
> purpose... But we have plenty of room in there, so maybe its worth it.
> I'll ask few other guys what they think about it.
> 
> +> This would save me at least a day starring at struct mount with
> +> mnt_writeopcount and (still) no writers.
> +> 
> +> For instance, such situation occurs in quotactl/quotaoff case.
> 
> This could be the hang I'm chasing, btw:)

This deadlock manifests itself as bunch of processes in "suspfs" state
and (usually) mksnap_ffs in "suspwt" state, without any other blocks.
One of the "suspfs"-blocked processes called vn_start_write recursively.
It seems that for the main tree there is no other way to produce the
deadlock situation except running mksnap.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20060428/a4c69f44/attachment.pgp