From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>,
linux-ext4@vger.kernel.org, Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH 3/3] ext4: Gracefully handle ext4_break_layouts() failure during truncate
Date: Fri, 24 May 2019 10:13:08 +0200 [thread overview]
Message-ID: <20190524081308.GB28972@quack2.suse.cz> (raw)
In-Reply-To: <20190524041829.GD2532@mit.edu>
On Fri 24-05-19 00:18:29, Theodore Ts'o wrote:
> On Wed, May 22, 2019 at 11:03:17AM +0200, Jan Kara wrote:
> > ext4_break_layouts() may fail e.g. due to a signal being delivered.
> > Thus we need to handle its failure gracefully and not by taking the
> > filesystem down. Currently ext4_break_layouts() failure is rare but it
> > may become more common once RDMA uses layout leases for handling
> > long-term page pins for DAX mappings.
> >
> > To handle the failure we need to move ext4_break_layouts() earlier
> > during setattr handling before we do hard to undo changes such as
> > modifying inode sizhe. To be able to do that we also have to move some
> > other checks which are better done uwithout holding i_mmap_sem earlier.
> >
> > Reported-and-tested-by: Ira Weiny <ira.weiny@intel.com>
> > Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Jan Kara <jack@suse.cz>hh
>
> Thanks, applied.
>
> What do people think about adding marking this for stable? My take is
> that DAX is still not that common for most stable kernel users, and
> the patch moves enough stuff around that it's borderline for stable.
> I'm going to leave off marking for stable unless someone wants to make
> a case that we should so mark it.
Yeah, my take was that I'd care about backporting this patch for stable once
somebody complains that he has actually hit the problem...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2019-05-24 8:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 9:03 [PATCH 0/3 v2] ext4: Fix issues in ext4 truncate handling Jan Kara
2019-05-22 9:03 ` [PATCH 1/3] ext4: Wait for outstanding dio during truncate in nojournal mode Jan Kara
2019-05-24 3:46 ` Theodore Ts'o
2019-05-22 9:03 ` [PATCH 2/3] ext4: Do not delete unlinked inode from orphan list on failed truncate Jan Kara
2019-05-24 3:47 ` Theodore Ts'o
2019-05-22 9:03 ` [PATCH 3/3] ext4: Gracefully handle ext4_break_layouts() failure during truncate Jan Kara
2019-05-24 4:18 ` Theodore Ts'o
2019-05-24 8:13 ` Jan Kara [this message]
2019-05-25 3:32 ` Theodore Ts'o
2019-05-27 14:53 ` Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2019-05-21 7:43 [PATCH 0/3] ext4: Fix issues in ext4 truncate handling Jan Kara
2019-05-21 7:43 ` [PATCH 3/3] ext4: Gracefully handle ext4_break_layouts() failure during truncate Jan Kara
2019-05-21 18:27 ` Ira Weiny
2019-05-22 8:57 ` Jan Kara
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=20190524081308.GB28972@quack2.suse.cz \
--to=jack@suse.cz \
--cc=ira.weiny@intel.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).