On Fri, 13 Oct 2017 12:54:31 +0000 Helg Bredow <[email protected]> wrote:
> 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? > Just in case anyone else is working on this. I've found the cause and am working on a patch. -- Helg <[email protected]>
