Change Details

kern_shm_open currently accepts O_CLOEXEC but sets it unconditionally. The only in-tree consumer of kern_shm_open is the shm_open(2) syscall, which is mandated by POSIX to set CLOEXEC, so this is OK. The motivation here is to allow wrappers around shm to be written that don't set CLOEXEC. Push setting of O_CLOEXEC into the caller. Unconditionally set O_CLOEXEC in sys_shm_open to meet POSIX requirements, and drop a comment explaining the situation to make it clear that it's intentional. This also has the side-effect of making flags correctly reflect the 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.

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.

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. The only in-tree consumer of kern_shm_open iskern_shm_open is used by the shm_open(2) syscall, which is mandated by POSIX to set CLOEXEC, and CloudABI's sys_fd_create1(). so this is OK.Presumably O_CLOEXEC is intended in the latter caller, The motivation here is to allow wrappers around shm to be written that don't set CLOEXECbut it's unclear from the context. Push setting ofsys_shm_open() now unconditionally sets O_CLOEXEC into the caller.to meet POSIX requirements, Unconditionally set O_CLOEXEC in sys_shm_open 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. and drop a comment explaining the situaCloudABI's sys_fd_create1() also uncondition to make it clear that it's intentionalally 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.