Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> My main reason for wanting ksmbd is that it's tiny

That's a fine reason. Does it have to be in the kernel to be small though? From what I can see ksmpd is small because it delivers only a minimal SMB3, not because it's in-kernel. Why would a user space SMB3 be appreciably larger?

Also, the performance hopes for ksmbd don't appear valid either. By adopting io_uring and splice(2) Samba now outperforms[1] ksmbd by a wide margin. Those results are a year old and may be out of date, but still, I suspect we're getting so close to the limits of hardware that it doesn't matter.

Another argument for in-kernel is SMB Direct: SMB over RDMA. Yet here[2] we see io_uring is receiving the bits needed for that as well.

Finally, the license issue: I can't think of a reason a GPL2/Berkeley licensed SMB3 couldn't be in user space.

Where am I wrong? Is there a valid reason for this to be in kernel? I don't see one.

[1] https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-ser... [2] https://lwn.net/Articles/879724/

Edit: looks like the ksmbd SMB Direct work predates the io_uring RDMA capability by a few years, so at that time SMB Direct was a legitimate reason. On the other hand send(..., MSG_ZEROCOPY) predates ksmbd...



I think the biggest reason here, especially for GP, is that ksmb3 already exists now (and it existed for a few years), while your tiny smb3 does not exist yet.


Ok, so now that we've exhausted the regression of invalid reasons we're left with what? Someone made it so in it goes?

Enjoy the CVEs I guess.


It just means that a better solution that fulfill all their needs doesn't exist yet, and they decided to take one trade-off rather than another one. Maybe in that setup a possible RCE is not that dangerous.


Basically this. I would love a small uaerspace implementation. Even if it had worse performance that's not the most important thing for me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: