[Bug 200681] [inline_data] read() does not see what write() has just written through different FD in the same thread

[Bug 200681] [inline_data] read() does not see what write() has just written through different FD in the same thread

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200681

--- Comment #6 from Anatoly Trosinenko (anatoly.trosinenko@gmail.com) ---
It looks like the difference was that I have specified 8M partition size. How
to reproduce it (I repeat parts of your documentation just to make sure I have
got it right):

1) Checkout master branch of torvalds/linux (tested on commit bab5c80b211)
2) Copy fstests/kernel-configs/x86_64-config-4.14 to .config and compile after
`make olddefconfig`
3) Take the attached repro.c and execute the following commands:

$ gcc --static repro.c -o repro # Inside /tmp/kvm-xfstest-$USER
$ kvm-xfstest shell
root@kvm-xfstests:~# mount /vtmp
root@kvm-xfstests:~# mke2fs -Fq -t ext4 -O inline_data -I 1024 /dev/vdc 8M
/dev/vdc contains a ext4 file system
        last mounted on /vdc on Sat Oct 13 15:59:40 2018
root@kvm-xfstests:~# mount /vdc
[    9.812236] EXT4-fs (vdc): mounted filesystem with ordered data mode. Opts:
(null)
root@kvm-xfstests:~# cd /vdc
root@kvm-xfstests:/vdc# /vtmp/repro
First write res = 48
Second write res = 17968
res1 = 17968 res2 = 48          first bytes of data are: 00 00 00...

When the full partition is used for the filesystem, the bug is not
reproducible, as expected.

Maybe with a 8M partition there is just not enough room for data, so maybe
everything is right except for the return codes saying everything was written
successfully instead of ENOSPC... (but the file size is 18016 as if all the
data were written to it).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 200681] [inline_data] read() does not see what write() has just written through different FD in the same thread

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200681

Anatoly Trosinenko (anatoly.trosinenko@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #277603|0                           |1
        is obsolete|                            |
 Attachment #277605|0                           |1
        is obsolete|                            |
 Attachment #277607|0                           |1
        is obsolete|                            |

--- Comment #7 from Anatoly Trosinenko (anatoly.trosinenko@gmail.com) ---
Created attachment 279013
  --> https://bugzilla.kernel.org/attachment.cgi?id=279013&action=edit
Reproducer

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 200681] [inline_data] read() does not see what write() has just written through different FD in the same thread

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200681

--- Comment #8 from Theodore Tso (tytso@mit.edu) ---
Thanks for the repro.   It looks like the critical factor is not the size of
the filesystem, but the blocksize.  It just so happens that using a file system
of size of 8M causes mke2fs to default to a 1k block size.  This can be seen by
trying testing with a file system created by:

mke2fs -Fq -t ext4 -O inline_data -I 1024 -b 1024 /dev/vdc 

I've done some initial investigation, and something really strange is going on.
 If an fsync(2) is forced write after the writes, the problem goes away.  By
changing the size of the reads, it's the second read which is returning all
zeros --- up to the point where when the first read is made to be larger than
16k, at which point it looks like it's the last 4k page which is all zeros.

Unfortuantely, it's not clear what is happening.   The best I can say at this
point is that it looks the problem is related to inline_data, where when doing
a large write which forces a conversion from an inline_data to normal file, and
where the blocksize is != the page size, something is going very wrong.

To date, I've been only testing inline_data with a blocksize of 4k, and that's
probably why I haven't seen any problems like this.

I'm curious how you found this bug; were you deliberately using a 1k block
size, or were you trying to use inline_data with very small file systems?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 200681] [inline_data] read() does not see what write() has just written through different FD in the same thread

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200681

--- Comment #9 from Anatoly Trosinenko (anatoly.trosinenko@gmail.com) ---
> I'm curious how you found this bug; were you deliberately using a 1k block
> size, or were you trying to use inline_data with very small file systems?

Frankly speaking, I have not stumbled upon this bug in real life --- just done
some FS fuzzing and for improving performance used smaller FS images. Maybe
smaller images have larger probability of triggering some bugs in my setup, too
(now I know why :) ). But inline_data (as well as other extended options) were
enabled deliberately, of course, supposing they are less stable than the core
features.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.