From: Jens Axboe <axboe@fb.com>
To: Jeff Layton <jlayton@kernel.org>, <linux-fsdevel@vger.kernel.org>,
<linux-block@vger.kernel.org>
Cc: <willy@infradead.org>, <darrick.wong@oracle.com>, <tytso@mit.edu>,
<bfoster@redhat.com>
Subject: Re: [PATCH] loop: clear wb_err in bd_inode when detaching backing file
Date: Mon, 21 May 2018 12:29:35 -0600 [thread overview]
Message-ID: <c9b3633d-160b-f9c3-8f67-a3182b1e5de2@fb.com> (raw)
In-Reply-To: <2282d2800f23af4678e82d1b7f40da35cdc8d406.camel@kernel.org>
On 5/21/18 12:26 PM, Jeff Layton wrote:
> On Mon, 2018-05-21 at 08:37 -0400, Jeff Layton wrote:
>> From: Jeff Layton <jlayton@redhat.com>
>>
>> When a loop block device encounters a writeback error, that error will
>> get propagated to the bd_inode's wb_err field. If we then detach the
>> backing file from it, attach another and fsync it, we'll get back the
>> writeback error that we had from the previous backing file.
>>
>> This is a bit of a grey area as POSIX doesn't cover loop devices, but it
>> is somewhat counterintuitive.
>>
>> If we detach a backing file from the loopdev while there are still
>> unreported errors, take it as a sign that we're no longer interested in
>> the previous file, and clear out the wb_err in the loop blockdev.
>>
>> Signed-off-by: Jeff Layton <jlayton@redhat.com>
>> ---
>> drivers/block/loop.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
>> index 5d4e31655d96..55cf554bc914 100644
>> --- a/drivers/block/loop.c
>> +++ b/drivers/block/loop.c
>> @@ -1068,6 +1068,7 @@ static int loop_clr_fd(struct loop_device *lo)
>> if (bdev) {
>> bdput(bdev);
>> invalidate_bdev(bdev);
>> + bdev->bd_inode->i_mapping->wb_err = 0;
>> }
>> set_capacity(lo->lo_disk, 0);
>> loop_sysfs_exit(lo);
>
> Jens,
>
> I sent this to the mailing lists earlier, but it occurs to me that
> loop.c changes should probably go through the block tree. Would you
> mind picking this up and feeding it to next and on to Linus?
>
> I think we probably want this in v4.17 if possible, as it is a
> regression from v4.16 (due to commit b4678df184b3) and was causing some
> failures in xfstests runs.
>
> Hmm, now that I think about it, we should probably also give Ted
> "Reported-and-Tested-by" credit here too. Let me know if you'd rather I
> resend with that added.
Yeah, I can funnel it for 4.17 - a quick resend with the right
attributions would be appreciated, thanks.
--
Jens Axboe
prev parent reply other threads:[~2018-05-21 18:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-21 12:37 [PATCH] loop: clear wb_err in bd_inode when detaching backing file Jeff Layton
2018-05-21 18:26 ` Jeff Layton
2018-05-21 18:29 ` Jens Axboe [this message]
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=c9b3633d-160b-f9c3-8f67-a3182b1e5de2@fb.com \
--to=axboe@fb.com \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).