From: "J. Bruce Fields" <bfields@fieldses.org>
To: linux-nfs@vger.kernel.org
Cc: hch@infradead.org
Subject: Re: spurious sillyrename after O_DIRECT writes get ENOSPC
Date: Wed, 13 Dec 2017 12:18:15 -0500 [thread overview]
Message-ID: <20171213171815.GB9205@fieldses.org> (raw)
In-Reply-To: <20171208221626.GB22508@fieldses.org>
On Fri, Dec 08, 2017 at 05:16:26PM -0500, J. Bruce Fields wrote:
> Last year Christoph noticed a bug that could result in a file being
> unnecessarily sillyrenamed after O_DIRECT writes get ENOSPC:
>
> http://lkml.kernel.org/r/20160616150146.GA14015@infradead.org
>
> It's reproduceable on upstream, over v3 or v4.
>
> I looked into it some more, and it seems to reproduce whenever a write
> system call results in multiple WRITE calls, only some of which receive
> ENOSPC. I think that's resulting in a leak of the wb_kref on some
> nfs_pages (possibly the ones corresponding to the ENOSPC failures?).
> Those nfs_pages in turn hold references on nfs_{lock,open}_contexts. So
> a "rm" on the client (even after the file is closed) results in a
> sillyrename.
>
> I'll keep looking at this, but the relevant code is pretty opaque to me
> so far. Any ideas welcomed.
Actually it looks like a leak of dreq->io_count? That prevents commits
from being sent (which I'm also seeing in network traces--the succesfull
WRITEs are unstable but never get committed), which means
nfs_direct_commit_complete() is never called, and the reference taken on
wb_kref in the request_commit case of nfs_direct_write_completion is
never put.
--b.
next prev parent reply other threads:[~2017-12-13 17:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-08 22:16 spurious sillyrename after O_DIRECT writes get ENOSPC J. Bruce Fields
2017-12-13 17:18 ` J. Bruce Fields [this message]
2017-12-14 13:08 ` Benjamin Coddington
2017-12-14 16:36 ` J. Bruce Fields
2017-12-14 18:55 ` J. Bruce Fields
2017-12-19 16:56 ` J. Bruce Fields
2018-01-16 15:08 ` [PATCH] NFS: commit direct writes even if they fail partially J. Bruce Fields
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=20171213171815.GB9205@fieldses.org \
--to=bfields@fieldses.org \
--cc=hch@infradead.org \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.