linux(4): Implement close_range

[dchagin]

Summary

MFC after: 2 weeks

Test Plan

glibc tests suite io/tst-close_range

[mjg]

linux "fd unsharing" is *not* accurately modeled by fdunshare, which is why I said trying to provide one for native binaries would be weird. they unshare at thread level, while freebsd is doing it at process level. It's all legacy crap.

do you have a program which uses the flag? it would be rather cumbersome to implement and highly doubt it is worth any effort

that said, it is ackable modulo the unshare thing, which should einval or whatever linux did prior to the addition of the flag

[dchagin]

In D39398#896738, @mjg wrote:

linux "fd unsharing" is *not* accurately modeled by fdunshare, which is why I said trying to provide one for native binaries would be weird. they unshare at thread level, while freebsd is doing it at process level. It's all legacy crap.

ah, I completely forgot that the Linux kernel does not make distinction between processes and threads.
I have read only man page )) which is "Unshare the specified file descriptors from any other processes before closing them, avoiding races with other threads sharing the file descriptor table." I.e., it should be process-wide.
So, calling close_range(UNSHARE) from a thread in multi-threaded app can cause unexpected behavior? As that thread can open a new file for which the fd will be reused.

do you have a program which uses the flag? it would be rather cumbersome to implement and highly doubt it is worth any effort

No, only tests from glibc and kernel.org

that said, it is ackable modulo the unshare thing, which should einval or whatever linux did prior to the addition of the flag

Or we can check P_HADTHREADS and fdunshare if not, return EINVAL if p had threads. It will work in a mostly cases

[mjg]

that would introduce wtf in debugging, just don't try to mess with the feature

[dchagin]

done, 10x

[mjg]

sys/compat/linux/linux_file.c

2093

this block needs to start with a "A note about CLOSE_RANGE_UNSHARE" or similar, otherwise it is unclear what the fuss is about, and even then I don't think the comment adds any value. Personally I would just note that freebsd does not have compatible unsharing mechanism and it does not look like adding one here is worth any effort.

sys/compat/linux/linux_file.h

200

this should be added but commented out

200

with a note to take a look at linux_close_range for an explanation

[dchagin]

ok,
what if we simply ignore UNSHARE flag and call kern_close_range with flags = 0?
I dont see problem as file manipulation is under FILEDESC_XLOCK.

[mjg]

ignoring the flag would result in a massive wtf for the unlikely case where someone needs it

just error out

[dchagin]

In D39398#896979, @mjg wrote:

ignoring the flag would result in a massive wtf for the unlikely case where someone needs it

just error out

well, done exactly as you say, what else?

[mjg]

sys/compat/linux/linux_file.h

201

rnage