| commit | 28e211700a81b0a934b6c7a4b8e7dda843634d2f | |
| author | Christoph Hellwig <hch@infradead.org> | |
| Tue, 24 Feb 2009 13:39:02 +0000 (24 08:39 -0500) | ||
| committer | Felix Blyakher <felixb@sgi.com> | |
| Thu, 30 Apr 2009 05:29:02 +0000 (30 00:29 -0500) | ||
| tree | 234d0754b9a5c9bc3b0ae890eeef57aa7d1ee29e | treesnapshot (tar.gz zip) |
| parent | 5f79ed685fc6122018c4b5826e2e5bdb7bc6f109 | commitdiff |
xfs: fix getbmap vs mmap deadlock
xfs_getbmap (or rather the formatters called by it) copy out the getbmap
structures under the ilock, which can deadlock against mmap. This has
been reported via bugzilla a while ago (#717) and has recently also
shown up via lockdep.
So allocate a temporary buffer to format the kernel getbmap structures
into and then copy them out after dropping the locks.
A little problem with this is that we limit the number of extents we
can copy out by the maximum allocation size, but I see no real way
around that.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Felix Blyakher <felixb@sgi.com>
Signed-off-by: Felix Blyakher <felixb@sgi.com>
xfs_getbmap (or rather the formatters called by it) copy out the getbmap
structures under the ilock, which can deadlock against mmap. This has
been reported via bugzilla a while ago (#717) and has recently also
shown up via lockdep.
So allocate a temporary buffer to format the kernel getbmap structures
into and then copy them out after dropping the locks.
A little problem with this is that we limit the number of extents we
can copy out by the maximum allocation size, but I see no real way
around that.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Felix Blyakher <felixb@sgi.com>
Signed-off-by: Felix Blyakher <felixb@sgi.com>
| fs/xfs/xfs_bmap.c | diffblobblamehistory |