"non-user-cloneable kernel area" KDL when copying files over sshfs

[v.vill]

Greetings,
I'm using @jessicah's SSH-over-UserlandFS haiku port, built for x86_64 (hrev52347). It works quite well, I can edit and access any file over it but whenever I'm copying local files on my remote mountpoint, I get a KDL such as:

PANIC: attempting to clone non-user-cloneable kernel area!
[stack trace]
panic + 0xba
vm_clone_area + 0x253
_user_clone_area + 0xb3
x86_64_syscall_entry + 0xfb
vector: 0x63, error code: 0x0
<libroot.so> _kern_clone_area + 0x0c

(see attached)

Fortunately, this KDL is continueable and I can then transfer the files using rsync over ssh, but it would certainly be nicer if that could be avoided :-)

[v.vill]

KDL

[waddlesplash]

Probably ​this one. Will take a look later.

[waddlesplash]

Please retest after hrev52355; that commit will not fix the panic but it will add some additional information which will more clearly identify what's going on.

[waddlesplash]

Fixed in hrev52363.

[v.vill]

Thanks! I'm unable to verify it, unfortunately, because sshfs appears to be broken since the userlandFS update (even though I rebuilt it with haikuporter). The mount command gives me something along the lines of

FUSEVolume::Mount()
fuse_main_real(3, 0x212d94d2ea0, 0xb1f7d22240, 304, (nil))
mount: General system error

(no KDL though, so: yay!)
I hesitate to open a new tracker page about it, since I'm not sure this thing is officially supported by the Haiku project.

[diver]

Users report that hrev52363. seems to break FuseSMB - shares visible but they are all empty in Tracker. However files are there in other file managers. Very odd.

[v.vill]

Interesting; perhaps that could also explain why sshfs (as patched in the haikuporter tree) has been broken as well since this bugfix? (Although in my case it doesn’t merely affect the Tracker, but actually prevents the remote server from being mounted in userlandfs.)

[waddlesplash]

Possibly? Note that if you are on the beta1 branch, the panic will not occur.

[waddlesplash]

Turns out my "fix" was the cause of that. It should work properly again after hrev52548.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone