xfs
[Top] [All Lists]

Re: [PATCH] xfs: unlock i_mutex in xfs_break_layouts

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: unlock i_mutex in xfs_break_layouts
From: Christoph Hellwig <hch@xxxxxx>
Date: Wed, 8 Apr 2015 18:24:03 +0200
Cc: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150407221927.GD15810@dastard>
References: <1428420944-20965-1-git-send-email-hch@xxxxxx> <20150407221927.GD15810@dastard>
User-agent: Mutt/1.5.17 (2007-11-01)
On Wed, Apr 08, 2015 at 08:19:27AM +1000, Dave Chinner wrote:
> That's kinda nasty, and it has no documentation explaining when or
> why we'd need to drop the i_mutex. How are we supposed to know if we
> need to drop the i_mutex or not?

We need to drop it if we hold it, pretty easy.

> What happens if the upper VFS
> layers change or we have a multiple call paths that have different
> i_mutex contexts (i.e. one holds, another doesn't)?

We avoid this in the VFS, as everytime we had it filesystems were getting it
wrong.

However you have a point in that we should probably have asserts that the
right locks are held.

> Which makes me wonder - is this layout breaking stuff at the right
> layer?

We can't do it in the VFS as it needs to be atomic vs the lock that
protects write in ->write and ->fallocate, which is only taken in
the filesystem.  For ->setattr in theory we could do it in the VFS,
but if the other callers can't do it in the VFS that will just lead
to code duplication.

<Prev in Thread] Current Thread [Next in Thread>