<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/ext4/file.c, branch linux-3.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-04-03T04:22:07Z</updated>
<entry>
<title>ext4: fix data corruption caused by unaligned direct AIO</title>
<updated>2019-04-03T04:22:07Z</updated>
<author>
<name>Lukas Czerner</name>
</author>
<published>2019-03-15T03:20:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=068b08bc9e751ada6161c8aa1d5d3f342f15fe06'/>
<id>urn:sha1:068b08bc9e751ada6161c8aa1d5d3f342f15fe06</id>
<content type='text'>
commit 372a03e01853f860560eade508794dd274e9b390 upstream.

Ext4 needs to serialize unaligned direct AIO because the zeroing of
partial blocks of two competing unaligned AIOs can result in data
corruption.

However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still into the same block, it has
the potential of corrupting the previous unaligned write to the same
block.

This is (very simplified) reproducer from Frank

    // 41472 = (10 * 4096) + 512
    // 37376 = 41472 - 4096

    ftruncate(fd, 41472);
    io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
    io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);

    io_submit(io_ctx, 1, &amp;iocbs[1]);
    io_submit(io_ctx, 1, &amp;iocbs[2]);

    io_getevents(io_ctx, 2, 2, events, NULL);

Without this patch the 512B range from 40960 up to the start of the
second unaligned write (41472) is going to be zeroed overwriting the data
written by the first write. This is a data corruption.

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
*
00009200  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30
*
0000a000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
*
0000a200  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31

With this patch the data corruption is avoided because we will recognize
the unaligned_aio and wait for the unwritten extent conversion.

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
*
00009200  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30
*
0000a200  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31
*
0000b200

Reported-by: Frank Sorenson &lt;fsorenso@redhat.com&gt;
Signed-off-by: Lukas Czerner &lt;lczerner@redhat.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO")
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: fix off-by-one on max nr_pages in ext4_find_unwritten_pgoff()</title>
<updated>2018-04-13T17:52:15Z</updated>
<author>
<name>Eryu Guan</name>
</author>
<published>2017-05-24T22:02:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0c14ecf3e6ec376ae50f4bcfec7aa60ed8bdb9e3'/>
<id>urn:sha1:0c14ecf3e6ec376ae50f4bcfec7aa60ed8bdb9e3</id>
<content type='text'>
[ Upstream commit 624327f8794704c5066b11a52f9da6a09dce7f9a ]

ext4_find_unwritten_pgoff() is used to search for offset of hole or
data in page range [index, end] (both inclusive), and the max number
of pages to search should be at least one, if end == index.
Otherwise the only page is missed and no hole or data is found,
which is not correct.

When block size is smaller than page size, this can be demonstrated
by preallocating a file with size smaller than page size and writing
data to the last block. E.g. run this xfs_io command on a 1k block
size ext4 on x86_64 host.

  # xfs_io -fc "falloc 0 3k" -c "pwrite 2k 1k" \
  	    -c "seek -d 0" /mnt/ext4/testfile
  wrote 1024/1024 bytes at offset 2048
  1 KiB, 1 ops; 0.0000 sec (42.459 MiB/sec and 43478.2609 ops/sec)
  Whence  Result
  DATA    EOF

Data at offset 2k was missed, and lseek(2) returned ENXIO.

This is unconvered by generic/285 subtest 07 and 08 on ppc64 host,
where pagesize is 64k. Because a recent change to generic/285
reduced the preallocated file size to smaller than 64k.

Signed-off-by: Eryu Guan &lt;eguan@redhat.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: in ext4_seek_{hole,data}, return -ENXIO for negative offsets</title>
<updated>2017-10-18T07:15:15Z</updated>
<author>
<name>Darrick J. Wong</name>
</author>
<published>2017-08-24T17:22:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6d1c3f7ed291c3139eccc3248d908aa7e0ac9e91'/>
<id>urn:sha1:6d1c3f7ed291c3139eccc3248d908aa7e0ac9e91</id>
<content type='text'>
commit 1bd8d6cd3e413d64e543ec3e69ff43e75a1cf1ea upstream.

In the ext4 implementations of SEEK_HOLE and SEEK_DATA, make sure we
return -ENXIO for negative offsets instead of banging around inside
the extent code and returning -EFSCORRUPTED.

Reported-by: Mateusz S &lt;muttdini@gmail.com&gt;
Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: fix SEEK_HOLE/SEEK_DATA for blocksize &lt; pagesize</title>
<updated>2017-08-11T16:30:13Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2017-08-05T21:43:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8a3a235bac007057f1ca51206899287019b88369'/>
<id>urn:sha1:8a3a235bac007057f1ca51206899287019b88369</id>
<content type='text'>
commit fcf5ea10992fbac3c7473a1db33d56a139333cd1 upstream.

ext4_find_unwritten_pgoff() does not properly handle a situation when
starting index is in the middle of a page and blocksize &lt; pagesize. The
following command shows the bug on filesystem with 1k blocksize:

  xfs_io -f -c "falloc 0 4k" \
            -c "pwrite 1k 1k" \
            -c "pwrite 3k 1k" \
            -c "seek -a -r 0" foo

In this example, neither lseek(fd, 1024, SEEK_HOLE) nor lseek(fd, 2048,
SEEK_DATA) will return the correct result.

Fix the problem by neglecting buffers in a page before starting offset.

Reported-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: fix SEEK_HOLE</title>
<updated>2017-06-14T10:54:18Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2017-05-22T02:33:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=07e47097fb7ddf31ecff18e435d3ac3d996cf60d'/>
<id>urn:sha1:07e47097fb7ddf31ecff18e435d3ac3d996cf60d</id>
<content type='text'>
commit 7d95eddf313c88b24f99d4ca9c2411a4b82fef33 upstream.

Currently, SEEK_HOLE implementation in ext4 may both return that there's
a hole at some offset although that offset already has data and skip
some holes during a search for the next hole. The first problem is
demostrated by:

xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "seek -h 0" file
wrote 57344/57344 bytes at offset 0
56 KiB, 14 ops; 0.0000 sec (2.054 GiB/sec and 538461.5385 ops/sec)
Whence	Result
HOLE	0

Where we can see that SEEK_HOLE wrongly returned offset 0 as containing
a hole although we have written data there. The second problem can be
demonstrated by:

xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
       -c "seek -h 0" file

wrote 57344/57344 bytes at offset 0
56 KiB, 14 ops; 0.0000 sec (1.978 GiB/sec and 518518.5185 ops/sec)
wrote 8192/8192 bytes at offset 131072
8 KiB, 2 ops; 0.0000 sec (2 GiB/sec and 500000.0000 ops/sec)
Whence	Result
HOLE	139264

Where we can see that hole at offsets 56k..128k has been ignored by the
SEEK_HOLE call.

The underlying problem is in the ext4_find_unwritten_pgoff() which is
just buggy. In some cases it fails to update returned offset when it
finds a hole (when no pages are found or when the first found page has
higher index than expected), in some cases conditions for detecting hole
are just missing (we fail to detect a situation where indices of
returned pages are not contiguous).

Fix ext4_find_unwritten_pgoff() to properly detect non-contiguous page
indices and also handle all cases where we got less pages then expected
in one place and handle it properly there.

Fixes: c8c0df241cc2719b1262e627f999638411934f60
CC: Zheng Liu &lt;wenqing.lz@taobao.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: prevent bugon on race between write/fcntl</title>
<updated>2014-10-30T14:53:16Z</updated>
<author>
<name>Dmitry Monakhov</name>
</author>
<published>2014-10-30T14:53:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a41537e69b4aa43f0fea02498c2595a81267383b'/>
<id>urn:sha1:a41537e69b4aa43f0fea02498c2595a81267383b</id>
<content type='text'>
O_DIRECT flags can be toggeled via fcntl(F_SETFL). But this value checked
twice inside ext4_file_write_iter() and __generic_file_write() which
result in BUG_ON inside ext4_direct_IO.

Let's initialize iocb-&gt;private unconditionally.

TESTCASE: xfstest:generic/036  https://patchwork.ozlabs.org/patch/402445/

#TYPICAL STACK TRACE:
kernel BUG at fs/ext4/inode.c:2960!
invalid opcode: 0000 [#1] SMP
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
CPU: 6 PID: 5505 Comm: aio-dio-fcntl-r Not tainted 3.17.0-rc2-00176-gff5c017 #161
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
task: ffff88080e95a7c0 ti: ffff88080f908000 task.ti: ffff88080f908000
RIP: 0010:[&lt;ffffffff811fabf2&gt;]  [&lt;ffffffff811fabf2&gt;] ext4_direct_IO+0x162/0x3d0
RSP: 0018:ffff88080f90bb58  EFLAGS: 00010246
RAX: 0000000000000400 RBX: ffff88080fdb2a28 RCX: 00000000a802c818
RDX: 0000040000080000 RSI: ffff88080d8aeb80 RDI: 0000000000000001
RBP: ffff88080f90bbc8 R08: 0000000000000000 R09: 0000000000001581
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88080d8aeb80
R13: ffff88080f90bbf8 R14: ffff88080fdb28c8 R15: ffff88080fdb2a28
FS:  00007f23b2055700(0000) GS:ffff880818400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f23b2045000 CR3: 000000080cedf000 CR4: 00000000000407e0
Stack:
 ffff88080f90bb98 0000000000000000 7ffffffffffffffe ffff88080fdb2c30
 0000000000000200 0000000000000200 0000000000000001 0000000000000200
 ffff88080f90bbc8 ffff88080fdb2c30 ffff88080f90be08 0000000000000200
Call Trace:
 [&lt;ffffffff8112ca9d&gt;] generic_file_direct_write+0xed/0x180
 [&lt;ffffffff8112f2b2&gt;] __generic_file_write_iter+0x222/0x370
 [&lt;ffffffff811f495b&gt;] ext4_file_write_iter+0x34b/0x400
 [&lt;ffffffff811bd709&gt;] ? aio_run_iocb+0x239/0x410
 [&lt;ffffffff811bd709&gt;] ? aio_run_iocb+0x239/0x410
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810abd94&gt;] ? __lock_acquire+0x274/0x700
 [&lt;ffffffff811f4610&gt;] ? ext4_unwritten_wait+0xb0/0xb0
 [&lt;ffffffff811bd756&gt;] aio_run_iocb+0x286/0x410
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810ac359&gt;] ? lock_release_holdtime+0x29/0x190
 [&lt;ffffffff811bc05b&gt;] ? lookup_ioctx+0x4b/0xf0
 [&lt;ffffffff811bde3b&gt;] do_io_submit+0x55b/0x740
 [&lt;ffffffff811bdcaa&gt;] ? do_io_submit+0x3ca/0x740
 [&lt;ffffffff811be030&gt;] SyS_io_submit+0x10/0x20
 [&lt;ffffffff815ce192&gt;] system_call_fastpath+0x16/0x1b
Code: 01 48 8b 80 f0 01 00 00 48 8b 18 49 8b 45 10 0f 85 f1 01 00 00 48 03 45 c8 48 3b 43 48 0f 8f e3 01 00 00 49 83 7c
24 18 00 75 04 &lt;0f&gt; 0b eb fe f0 ff 83 ec 01 00 00 49 8b 44 24 18 8b 00 85 c0 89
RIP  [&lt;ffffffff811fabf2&gt;] ext4_direct_IO+0x162/0x3d0
 RSP &lt;ffff88080f90bb58&gt;

Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>ext4: remove readpage() check in ext4_mmap_file()</title>
<updated>2014-07-15T13:56:19Z</updated>
<author>
<name>Zhang Zhen</name>
</author>
<published>2014-07-15T13:56:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=590a141863f726216d452f26bdcc59d648fd7cb0'/>
<id>urn:sha1:590a141863f726216d452f26bdcc59d648fd7cb0</id>
<content type='text'>
There is no kind of file which does not supply a page reading function.

Signed-off-by: Zhang Zhen &lt;zhenzhang.zhang@huawei.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2014-06-12T17:30:18Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2014-06-12T17:30:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=16b9057804c02e2d351e9c8f606e909b43cbd9e7'/>
<id>urn:sha1:16b9057804c02e2d351e9c8f606e909b43cbd9e7</id>
<content type='text'>
Pull vfs updates from Al Viro:
 "This the bunch that sat in -next + lock_parent() fix.  This is the
  minimal set; there's more pending stuff.

  In particular, I really hope to get acct.c fixes merged this cycle -
  we need that to deal sanely with delayed-mntput stuff.  In the next
  pile, hopefully - that series is fairly short and localized
  (kernel/acct.c, fs/super.c and fs/namespace.c).  In this pile: more
  iov_iter work.  Most of prereqs for -&gt;splice_write with sane locking
  order are there and Kent's dio rewrite would also fit nicely on top of
  this pile"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (70 commits)
  lock_parent: don't step on stale -&gt;d_parent of all-but-freed one
  kill generic_file_splice_write()
  ceph: switch to iter_file_splice_write()
  shmem: switch to iter_file_splice_write()
  nfs: switch to iter_splice_write_file()
  fs/splice.c: remove unneeded exports
  ocfs2: switch to iter_file_splice_write()
  -&gt;splice_write() via -&gt;write_iter()
  bio_vec-backed iov_iter
  optimize copy_page_{to,from}_iter()
  bury generic_file_aio_{read,write}
  lustre: get rid of messing with iovecs
  ceph: switch to -&gt;write_iter()
  ceph_sync_direct_write: stop poking into iov_iter guts
  ceph_sync_read: stop poking into iov_iter guts
  new helper: copy_page_from_iter()
  fuse: switch to -&gt;write_iter()
  btrfs: switch to -&gt;write_iter()
  ocfs2: switch to -&gt;write_iter()
  xfs: switch to -&gt;write_iter()
  ...
</content>
</entry>
<entry>
<title>-&gt;splice_write() via -&gt;write_iter()</title>
<updated>2014-06-12T04:18:51Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2014-04-05T08:27:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8d0207652cbe27d1f962050737848e5ad4671958'/>
<id>urn:sha1:8d0207652cbe27d1f962050737848e5ad4671958</id>
<content type='text'>
iter_file_splice_write() - a -&gt;splice_write() instance that gathers the
pipe buffers, builds a bio_vec-based iov_iter covering those and feeds
it to -&gt;write_iter().  A bunch of simple cases coverted to that...

[AV: fixed the braino spotted by Cyrill]

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ext4: add missing BUFFER_TRACE before ext4_journal_get_write_access</title>
<updated>2014-05-13T02:06:43Z</updated>
<author>
<name>liang xie</name>
</author>
<published>2014-05-13T02:06:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5d60125530b0122f5a0a57481f3064a6250365dd'/>
<id>urn:sha1:5d60125530b0122f5a0a57481f3064a6250365dd</id>
<content type='text'>
Make them more consistently

Signed-off-by: xieliang &lt;xieliang@xiaomi.com&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
</content>
</entry>
</feed>
