Re: [Xen-devel] [PATCH 1/2 linux-next] Revert "ufs: fix deadlocks introduced by sb mutex merge"

[Al Viro <viro@xxxxxxxxxxxxxxxxxx>]

On Wed, May 27, 2015 at 02:57:35PM -0700, Andrew Morton wrote:
> On Wed, 27 May 2015 21:15:30 +0200 Fabian Frederick <fabf@xxxxxxxxx> wrote:
> 
> > This reverts commit 9ef7db7f38d0
> > ("ufs: fix deadlocks introduced by sb mutex merge")
> > That patch tried to solve
> >     Commit 0244756edc4b98c
> >     ("ufs: sb mutex merge + mutex_destroy")
> > which is itself partially reverted due to multiple deadlocks
> 
> This is all very vague.  The changelogs are missing any description of
> the deadlocks: how they are triggered, why they occur.  And there's no
> description of how the patches fix these deadlocks.  And as we're
> reverting a bunch of things one wonders whether the problems which the
> now-reverted patches fixed are being reintroduced.
> 
> Has anyone (Ian?) confirmed that the fs works OK with these patches?

Folks, how about we figure out what's really being protected by that
mutex?  IIRC, the main irregularity about ufs is the need to deal with
growing the partial final block - unlike e.g ext2, ufs has differently-sized
blocks and fragments.  Basically, it's tail-packing - short files have
the last used direct pointer refer to a group of adjacent fragments that
doesn't have to be block-aligned or fill the entire block.  They can't
cross the disk block boundary and write might have to reallocate the partial
block.

So we need
        * per-page exclusion for reallocation time (normal page locks are
doing that)
        * per-fs exclusion for block and fragment allocations (->s_lock?)
        * per-fs exclusion for inode allocations (->s_lock?)
        * per-inode exclusion for mapping changes (a-la ext2 truncate_mutex)
        * per-directory exclusion for contents access (->i_mutex gives that)

Looks like we ought to add ->truncate_mutex and shove lock_ufs() calls
all way down into balloc.c (and ialloc.c for inode allocations)...

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel