Linux NFS development
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Peng Tao <tao.peng@primarydata.com>
Cc: linux-nfs@vger.kernel.org,
	Trond Myklebust <trond.myklebust@primarydata.com>
Subject: Re: [PATCH] nfs: fix dio deadlock when O_DIRECT flag is flipped
Date: Wed, 14 Jan 2015 07:48:38 -0800	[thread overview]
Message-ID: <20150114154838.GA15323@infradead.org> (raw)
In-Reply-To: <1421244543-32539-1-git-send-email-tao.peng@primarydata.com>

On Wed, Jan 14, 2015 at 10:09:03PM +0800, Peng Tao wrote:
> Running xfstest generic/036, we'll get following VM_BUG_ON in
> nfs_direct_IO(). 036 toggles O_DIRECT flag while IO is going on.
> So the VM_BUG_ON should not exist there. However, we have a deadlock
> in the code path as well, because inode->i_mutex is taken when calling
> into ->direct_IO. And nfs_file_direct_write() would grab inode->i_mutex
> again.
> 
> Meanwhile, nfs_file_direct_write() does a lot of things that is already
> done by vfs before ->direct_IO is called. So skip those duplicates. One
> exception is i_size_write. vfs does not take i_lock when setting i_size.
> But nfs appears to need i_lock when setting i_size.

But given that NFS implements direct I/O without ->direct_IO (except for
the horrible swap over NFS hack that is on it's way out) it shold
never be called.

The right fix is to determine the O_DIRECT flag in one place when
entering a write, and then pass it down on the stack.  We already do
this in XFS for example, it just needs to be expanded to filemap.c
so that more filesystems benefit from it.

  reply	other threads:[~2015-01-14 15:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14 14:09 [PATCH] nfs: fix dio deadlock when O_DIRECT flag is flipped Peng Tao
2015-01-14 15:48 ` Christoph Hellwig [this message]
     [not found]   ` <CAHQdGtQAqn9zh8UC-dn2s3nLmnRyyxeSNdk=+FZdYmj46ZEcXA@mail.gmail.com>
2015-01-14 16:21     ` Trond Myklebust
2015-01-14 16:55   ` Peng Tao
2015-01-15 15:17     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150114154838.GA15323@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tao.peng@primarydata.com \
    --cc=trond.myklebust@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox