Comment 66 for bug 2056461

Ok, so what I was missing was how eofcat works.

Let's simplify the reproducer for real. I assume this used to work on older kernels, can someone confirm?

0/ some random 9p mount in a VM
1/ create 'foo' empty file (either host or VM doesn't matter)
    : > foo
2/ in VM, keep reading it until content appears:
    while true; do read content; if [ -n "$content" ]; then echo $content; break; fi; done < foo
3/ on host, write some data:
    echo foo >> foo

This doesn't get any data in VM, and I assume it used to work, and it'll likely work with your patch -- just doing a stat or anything in the vm unblocks it.

As said in the previous comment, read shouldn't assume the file size and that'll solve the problem.

v9fs_file_read_iter() is called with an appropriate size... So is netfs_unbuffered_read_iter() and netfs_begin_read() but the problem is that netfs_begin_read() skips the read altogether as it doesn't match its assumption for i_size

In unbuffered mode, it shouldn't match i_size and just stop when read returns 0.

the netfs read request was allocated with netfs_alloc_request(NETFS_DIO_READ) so at that point we still know it's uncached, but that information seems to be lost for netfs_begin_read() and I'm not sure what is best to check.

@David -- now we have a simpler reproducer & know exactly what's wrong, could you look at this this week?