Deadlock in nullfs/zfs somewhere

[Konstantin Belousov]

On Sun, Jul 21, 2013 at 12:36:43PM +0300, Andriy Gapon wrote:
> on 21/07/2013 10:11 Konstantin Belousov said the following:
> > On Fri, Jul 19, 2013 at 10:33:11PM +0300, Andriy Gapon wrote:
> >> on 19/07/2013 21:42 Konstantin Belousov said the following:
> >>> Then, you cannot use VFS suspension.  Or, in other words, you are
> >>> directed to abuse the VFS interface.  I assure you that any changes to
> >>> the interface would not take into account such abuse and probably break
> >>> your hack.
> >> 
> >> So what would be your recommendation about this problem? Should we add
> >> another flavor of VFS suspension? The one that would mean "all external
> >> accesses to this fs must be put on hold", but would not imply "this fs is
> >> frozen".
> > 
> > Suspension is very complicated as it is. Adding another flavour would 
> > multiply the current mess^H^H^H^H collection of subtleties. IMO, the best
> > route is to use the KPI properly, i.e. adding the vn_start_write() braces
> > around the top-level entries in the mutating code paths.
> > 
> 
> So how will this help with doing a rollback in the thread that does the following?
> 
> vfs_write_suspend
> zfs rollback
> vfs_write_resume

I have no idea. I am answering to your proposal from the different
angle, as a person who spent some efforts maintaining VFS interfaces.
I object against interface abuse, and point out a fragility of the
approach.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20130721/e00b9ad3/attachment.sig>