kern_shm_open: push O_CLOEXEC into caller controller

[kevans]

Summary

The motivation for this change is to allow wrappers around shm to be written that don't set CLOEXEC. kern_shm_open currently accepts O_CLOEXEC but sets it unconditionally. kern_shm_open is used by the shm_open(2) syscall, which is mandated by POSIX to set CLOEXEC, and CloudABI's sys_fd_create1(). Presumably O_CLOEXEC is intended in the latter caller, but it's unclear from the context.

sys_shm_open() now unconditionally sets O_CLOEXEC to meet POSIX requirements, and a comment has been dropped in to kern_fd_open() to explain the situation and add a pointer to where O_CLOEXEC setting is maintained for shm_open(2) correctness. CloudABI's sys_fd_create1() also unconditionally sets O_CLOEXEC to match previous behavior.

This also has the side-effect of making flags correctly reflect the O_CLOEXEC status on this fd for the rest of kern_shm_open(), but a glance-over leads me to believe that it didn't really matter.

[markj]

What about cloudabi_sys_fd_create1()? There is no reference to CLOEXEC at all in the cloudabi code, so it's not clear to me whether it cares about this particular case.

[kevans]

In D21119#458582, @markj wrote:

What about cloudabi_sys_fd_create1()? There is no reference to CLOEXEC at all in the cloudabi code, so it's not clear to me whether it cares about this particular case.

Hmm... not sure how I missed this one, I thought I grepped all of sys/. I guess it must set O_CLOEXEC to remain compatible, but maybe @ed can provide some insight as to whether that's correct going forward -- I kind of suspect it is.

[kib]

sys/kern/uipc_shm.c

737 ↗

(On Diff #60306)

sys_shm_open()

[kevans]

• sys_shm_open -> sys_shm_open()
• update previously missed cloudabi caller to also unconditionally set O_CLOEXEC to maintain previous behavior