All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.com>
Cc: linux-ext4@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	ross.zwisler@linux.intel.com, willy@linux.intel.com
Subject: Re: [PATCH 3/9] ext4: Fix races between buffered IO and collapse / insert range
Date: Sat, 24 Oct 2015 00:59:26 -0400	[thread overview]
Message-ID: <20151024045926.GM7917@thunk.org> (raw)
In-Reply-To: <1445501761-14528-4-git-send-email-jack@suse.com>

On Thu, Oct 22, 2015 at 10:15:55AM +0200, Jan Kara wrote:
> Current code implementing FALLOC_FL_COLLAPSE_RANGE and
> FALLOC_FL_INSERT_RANGE is prove to races with buffered writes and page
> faults. If buffered write or write via mmap manages to squeeze between
> filemap_write_and_wait_range() and truncate_pagecache() in the fallocate
> implementations, the written data is simply discarded by
> truncate_pagecache() although it should have been shifted.
> 
> Fix the problem by moving filemap_write_and_wait_range() call inside
> i_mutex and i_mmap_sem. That way we are protected against races with
> both buffered writes and page faults.
> 
> Signed-off-by: Jan Kara <jack@suse.com>

This patch is causing generic/091 to fail with a 1k block size.

BEGIN TEST 1k: Ext4 1k block Sat Oct 24 00:41:32 EDT 2015
DEVICE: /dev/vdd
MK2FS OPTIONS: -q -b 1024
MOUNT OPTIONS: -o block_validity
FSTYP         -- ext4
PLATFORM      -- Linux/i686 kvm-xfstests 4.3.0-rc2ext4-00028-g53834d8
MKFS_OPTIONS  -- -q -b 1024 /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc

generic/091		[00:41:35][    8.942840] run fstests generic/091 at 2015-10-24 00:41:35
[    9.471531] xfs_io (3160) used greatest stack depth: 5636 bytes left
[   13.467847] fsx (3172) used greatest stack depth: 5632 bytes left
 [00:41:39] [failed, exit status 1] - output mismatch (see /results/results-1k/generic/091.out.bad)
    --- tests/generic/091.out	2015-10-18 23:46:49.000000000 -0400
    +++ /results/results-1k/generic/091.out.bad	2015-10-24 00:41:39.981112671 -0400
    @@ -1,7 +1,7124 @@
     QA output created by 091
     fsx -N 10000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
    -fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -W
    ...
    (Run 'diff -u tests/generic/091.out /results/results-1k/generic/091.out.bad'  to see the entire diff)

An examination of results-1k/generic/091.full finds:

fsx -N 10000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
mapped writes DISABLED
skipping insert range behind EOF
skipping insert range behind EOF
truncating to largest ever: 0x11e00
truncating to largest ever: 0x2fa00
zero_range to largest ever: 0x4e869
truncating to largest ever: 0x68000
truncating to largest ever: 0x6c000
truncating to largest ever: 0x70200
truncating to largest ever: 0x74400
truncating to largest ever: 0x74e00
fallocating to largest ever: 0x75f20
fallocating to largest ever: 0x7a120
skipping insert range behind EOF
skipping collapse range behind EOF
skipping zero length zero range
skipping zero length zero range
READ BAD DATA: offset = 0x28000, size = 0xb000, fname = /vdd/junk
OFFSET	GOOD	BAD	RANGE
0x28b0f	0x0000	0xa793	0x    0
operation# (mod 256) for the bad data may be 147
0x28b10	0x0000	0x9398	0x    1
operation# (mod 256) for the bad data may be 147
0x28b11	0x0000	0x9893	0x    2
operation# (mod 256) for the bad data may be 147
0x28b12	0x0000	0x93d4	0x    3
operation# (mod 256) for the bad data may be 147
0x28b13	0x0000	0xd493	0x    4
...

Could you take a look?

						- Ted
						

  parent reply	other threads:[~2015-10-24 10:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22  8:15 [PATCH 0/9 v2] ext4: Punch hole and DAX fixes Jan Kara
2015-10-22  8:15 ` [PATCH 1/9] ext4: Fix races between page faults and hole punching Jan Kara
2015-10-24  1:21   ` Theodore Ts'o
2015-10-25  4:58     ` Jan Kara
2015-10-22  8:15 ` [PATCH 2/9] ext4: Move unlocked dio protection from ext4_alloc_file_blocks() Jan Kara
2015-10-22  8:15 ` [PATCH 3/9] ext4: Fix races between buffered IO and collapse / insert range Jan Kara
2015-10-24  1:22   ` Theodore Ts'o
2015-10-24  4:59   ` Theodore Ts'o [this message]
2015-10-22  8:15 ` [PATCH 4/9] ext4: Fix races of writeback with punch hole and zero range Jan Kara
2015-10-22  8:15 ` [PATCH 5/9] ext4: Document lock ordering Jan Kara
2015-10-22  8:15 ` [PATCH 6/9] ext4: Get rid of EXT4_GET_BLOCKS_NO_LOCK flag Jan Kara
2015-10-22  8:15 ` [PATCH 7/9] ext4: Provide ext4_issue_zeroout() Jan Kara
2015-10-22  8:16 ` [PATCH 8/9] ext4: Implement allocation of pre-zeroed blocks Jan Kara
2015-10-22  8:16 ` [PATCH 9/9] ext4: Use pre-zeroed blocks for DAX page faults Jan Kara
2015-10-25  9:23   ` Theodore Ts'o
2015-10-22 18:09 ` [PATCH 0/9 v2] ext4: Punch hole and DAX fixes Ross Zwisler
2015-10-22 21:14   ` Jan Kara
2015-10-23  3:35   ` Eryu Guan
  -- strict thread matches above, loose matches on Subject: below --
2015-11-04 16:18 [PATCH 0/9 v3] " Jan Kara
2015-11-04 16:18 ` [PATCH 3/9] ext4: Fix races between buffered IO and collapse / insert range Jan Kara
2015-11-10 19:50 [PATCH 0/9 v4] ext4: Punch hole and DAX fixes Jan Kara
2015-11-10 19:50 ` [PATCH 3/9] ext4: Fix races between buffered IO and collapse / insert range Jan Kara
2015-11-18  1:39   ` Elliott, Robert (Persistent Memory)
2015-11-18 15:16     ` 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=20151024045926.GM7917@thunk.org \
    --to=tytso@mit.edu \
    --cc=dan.j.williams@intel.com \
    --cc=jack@suse.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=willy@linux.intel.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.