❦ 15 août 2015 13:17 +0200, Vincent Bernat <bernat@xxxxxxxx> :
>> 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@xxxxxxxxxxxxxxxxxx>
> Date: Wed Apr 1 23:59:57 2015 -0400
>
> 9p: switch to ->read_iter/->write_iter
>
> Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
>
>
> 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.
After some more testing, I discovered that this bug also happens without
overlayfs (despite what I said in the first post). The fix is in fact
pretty easy (ret should be initialized to 0 in v9fs_file_read_iter). I
am sending a proper patch in a minute.
--
ROMEO: Courage, man; the hurt cannot be much.
MERCUTIO: No, 'tis not so deep as a well, nor so wide
as a church-door; but 'tis enough, 'twill serve.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
