On 11/10/17(Wed) 11:25, Helg Bredow wrote: > I initially noticed this on a modified kernel that returns EBADF when > the fusefs_readdir() code you modified is encountered.
Yes, there's a bug in the current code. A functionality is not implemented and no error is returned. What's the relevant part of ktrace/kdump with this modified kernel? > I then > downloaded the latest snapshot to see if I could replicate it and > noticed that it "hangs" the kernel (due to an endless loop). This bug > is not present in 6.1. You should be able to enter ddb(4) and use the new "kill" command to get out of the hang. > I used ktrace to see what system calls are being made and narrowed it > down to getcwd(3). I've noticed that there is no call to VOP_OPEN in > vfs_getcwd.c. Is that the correct behaviour? Yes it is. > I've tried your patch and had to modify it a bit so it compiles but it > doesn't solve the problem. The fusefs_file_open() call succeeds. > However, any call to getcwd(3) now fails with "No such file or > directory". I tested by creating a small test program that just makes > this function call. You need to figure out why vfs_getcwd_scandir() returns ENOENT. What's failing inside fuse_readdir() and why?
