All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Jan Kara <jack@suse.cz>, stable@vger.kernel.org
Cc: xfs@oss.sgi.com
Subject: Re: XFS hole punch races
Date: Sat, 04 Jun 2016 18:11:10 +0100	[thread overview]
Message-ID: <1465060270.2847.149.camel@decadent.org.uk> (raw)
In-Reply-To: <20160322155740.GB28772@quack.suse.cz>


[-- Attachment #1.1: Type: text/plain, Size: 1325 bytes --]

On Tue, 2016-03-22 at 16:57 +0100, Jan Kara wrote:

Hi,

similarly to ext4 also XFS had races between hole punching and page faults
which could result in data corruption. The fixes were merged in 4.1-rc1 but
it might make sense to backport them to older stable releases given the
nature of the issue.

Relevant fixes are:

de0e8c20ba3a65b0f15040aabbefdc1999876e6b
075a924d45cc69c75a35f20b4912b85aa98b180a
e8e9ad42c1f1e1bfbe0e8c32c8cac02e9ebfb7ef
0f9160b444e4de33b65dfcd3b901358a3129461a
723cac48473358939759885a18e8df113ea96138
ec56b1f1fdc69599963574ce94cc5693d535dd64


You missed the first in that sequence:

653c60b633a9 xfs: introduce mmap/truncate lock

For 3.16, I've queued up all those fixes with one further prerequisite:

812176832169 xfs: fix swapext ilock deadlock

For 3.2, I've queued up all but 723cac484733, with these additional
prerequisites:

f38996f57687 xfs: reduce ilock hold times in xfs_setattr_size
bc4010ecb8f4 xfs: use iolock on XFS_IOC_ALLOCSP calls
76ca4c238cf5 xfs: always take the iolock around xfs_setattr_size
5f8aca8b43f4 xfs: always hold the iolock when calling xfs_change_file_space
I realise I'll need to check for regressions with xfstests.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Ben Hutchings <ben@decadent.org.uk>
To: Jan Kara <jack@suse.cz>, stable@vger.kernel.org
Cc: xfs@oss.sgi.com, Dave Chinner <david@fromorbit.com>
Subject: Re: XFS hole punch races
Date: Sat, 04 Jun 2016 18:11:10 +0100	[thread overview]
Message-ID: <1465060270.2847.149.camel@decadent.org.uk> (raw)
In-Reply-To: <20160322155740.GB28772@quack.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

On Tue, 2016-03-22 at 16:57 +0100, Jan Kara wrote:

Hi,

similarly to ext4 also XFS had races between hole punching and page faults
which could result in data corruption. The fixes were merged in 4.1-rc1 but
it might make sense to backport them to older stable releases given the
nature of the issue.

Relevant fixes are:

de0e8c20ba3a65b0f15040aabbefdc1999876e6b
075a924d45cc69c75a35f20b4912b85aa98b180a
e8e9ad42c1f1e1bfbe0e8c32c8cac02e9ebfb7ef
0f9160b444e4de33b65dfcd3b901358a3129461a
723cac48473358939759885a18e8df113ea96138
ec56b1f1fdc69599963574ce94cc5693d535dd64


You missed the first in that sequence:

653c60b633a9 xfs: introduce mmap/truncate lock

For 3.16, I've queued up all those fixes with one further prerequisite:

812176832169 xfs: fix swapext ilock deadlock

For 3.2, I've queued up all but 723cac484733, with these additional
prerequisites:

f38996f57687 xfs: reduce ilock hold times in xfs_setattr_size
bc4010ecb8f4 xfs: use iolock on XFS_IOC_ALLOCSP calls
76ca4c238cf5 xfs: always take the iolock around xfs_setattr_size
5f8aca8b43f4 xfs: always hold the iolock when calling xfs_change_file_space
I realise I'll need to check for regressions with xfstests.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2016-06-04 17:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22 15:57 XFS hole punch races Jan Kara
2016-03-22 15:57 ` Jan Kara
2016-05-02 23:44 ` Greg KH
2016-05-02 23:44   ` Greg KH
2016-05-15 22:23 ` Ben Hutchings
2016-05-15 22:23   ` Ben Hutchings
2016-06-04 17:11 ` Ben Hutchings [this message]
2016-06-04 17:11   ` Ben Hutchings
2016-06-04 23:28   ` Dave Chinner
2016-06-04 23:28     ` Dave Chinner
2016-06-05  1:19     ` Ben Hutchings
2016-06-05  1:19       ` Ben Hutchings
2016-06-05  2:16       ` Dave Chinner
2016-06-05  2:16         ` Dave Chinner
2016-06-05  5:16         ` Willy Tarreau
2016-06-05  5:16           ` Willy Tarreau

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=1465060270.2847.149.camel@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=jack@suse.cz \
    --cc=stable@vger.kernel.org \
    --cc=xfs@oss.sgi.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 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.