On Wed, 11 Oct 2017 13:53:26 +0200 Martin Pieuchot <[email protected]> wrote:
> 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? > The reason is that ifuse_fill_readdir() sets d_fileno to the ino value returned by the file system but fuse otherwise uses its own generated ino. The Linux version of fuse has the use_ino and readdir_ino options to modify this behaviour. OpenBSD currently behaves as if the use_ino option was not set. i.e. don't use the file system ino values. I've attempted to fix this by calling get_vn_by_name_and_parent() inside the filler function and it works some of the time but not others. Any suggestions? -- Helg <[email protected]>
