[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2 linux-next] Revert "ufs: fix deadlocks introduced by sb mutex merge"
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |