| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 2/2] xfs: fix splice/direct-IO deadlock |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Wed, 10 Aug 2011 06:17:33 -0400 |
| Cc: | xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx |
| In-reply-to: | <1312785927-10662-3-git-send-email-david@xxxxxxxxxxxxx> |
| References: | <1312785927-10662-1-git-send-email-david@xxxxxxxxxxxxx> <1312785927-10662-3-git-send-email-david@xxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Mon, Aug 08, 2011 at 04:45:27PM +1000, Dave Chinner wrote: > From: Dave Chinner <dchinner@xxxxxxxxxx> > > lockdep reports splice vs direct-io write lock inversions due to > generic_file_splice_write() taking the inode->i_mutex inside > XFS_IOLOCK_EXCL context. These lock contexts are inverted, hence can > deadlock. Use splice_write_to_file() with an actor that does not > take the i_mutex to avoid these problems. I don't think the locking model is quite correct yet. We'll still hold the iolock and i_mutex over splice_from_pipe_begin/splice_from_pipe_next/splice_from_pipe_end, which call into the pipe code, and take other i_mutex instances that may deadlock against ours. It also means we hold the iolock over generic_write_sync which calls into ->fsync which takes the iolock with my latests changes. I think we'll have to take the locking and i_size updates into the actor, and behave like the other filesystems. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 1/2] vfs: split generic splice code from i_mutex locking, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 0/2] splice: i_mutex vs splice write deadlock V2, Christoph Hellwig |
| Previous by Thread: | [PATCH 2/2] xfs: fix splice/direct-IO deadlock, Dave Chinner |
| Next by Thread: | [PATCH 1/2] vfs: split generic splice code from i_mutex locking, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |