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

[Al Viro <viro@xxxxxxxxxxxxxxxxxx>]

On Fri, Jun 05, 2015 at 07:50:18PM +0100, Al Viro wrote:
> Basically, we have
>       i_mutex: file size changes, contents-affecting syscalls.  Per-inode.
>       truncate_mutex: block pointers changes.  Per-inode.
>       s_lock: block and inode bitmaps changes.  Per-filesystem.
> 
> For UFS it's slightly more complicated due to tail packing they are doing for
> short files, but most of that complexity is due to having that stuff handled
> way too deep in call chain.

Oh, lovely... commit 10e5dc
Author: Evgeniy Dushistov <dushistov@xxxxxxx>
Date:   Sat Jul 1 04:36:24 2006 -0700

    [PATCH] ufs: truncate should allocate block for last byte

had removed ->truncate() method and missed the fact that vmtrucate() had
callers outside of ->setattr(), such as handling of ->prepare_write() partial
failures and short copies on write(2) in general.

Then we had a long and convoluted series of conversions that ended up with
vmtruncate() lifted into ufs_write_failed() and replaced with
truncate_pagecache() in there.

Through all that, everybody (me included) had not noticed that we *still*
do not free blocks allocated by ufs_write_begin() failing halfway through.
While we are at it, ufs_write_end() ought to call ufs_write_failed() in
case when we'd been called after a short copy (and do the same block freeing).

Joy...  Folks, is anybody actively maintaining fs/ufs these days?

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