Re: 9p/overlayfs: read error when reading an empty file

[Vincent Bernat <bernat@luffy.cx>]

 ❦ 15 août 2015 09:37 +0200, Vincent Bernat <bernat@luffy.cx> :

> I have found a regression which was introduced after 4.0 in
> 9p/overlayfs. This regression happens when the lower directory is a 9p
> mount, the upperdir is an empty tmpfs and we try to read 0 bytes from an
> empty file (something than gcc is doing when trying to read an include).
>
> The following program can be used to trigger the problem:
>
> #v+
> #include <assert.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
>
> int main(int argc, const char **argv)
> {
>     assert(argc == 2);
>     char buffer[256];
>     int fd = open(argv[1], O_RDONLY|O_NOCTTY);
>     assert(fd >= 0);
>     assert(read(fd, buffer, 0) == 0);
>     return 0;
> }
> #v-
>
> read() returns -30720.
>
> This works fine with a 4.0 kernel and breaks with a 4.1 kernel.

It took me some time to bissect this one because I also run into an
infinite loop caused by 070b36 and fixed by 8e3c50. Finally, the culprit
for the above bug seems to be:

commit e494b6b5e1034db00571c44e089e6fe3845b6e8c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Apr 1 23:59:57 2015 -0400

    9p: switch to ->read_iter/->write_iter

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>


This commit + 8e3c50 triggers the bug. This commit~1 + 8e3c50
doesn't. Unfortunately, it is far too extensive to try to revert it on
top of 4.1.
-- 
When in doubt, tell the truth.
		-- Mark Twain