kevans fb8c9ef833 kern_shm_open: push O_CLOEXEC into caller control
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.

Reviewed by:	kib, markj
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D21119
2019-07-31 15:16:51 +00:00
..
2019-07-30 16:01:16 +00:00
2019-01-27 00:46:06 +00:00
2019-05-20 19:14:07 +00:00
2019-06-24 20:52:21 +00:00
2019-05-30 16:11:20 +00:00
2018-12-05 16:43:03 +00:00
2019-06-03 15:23:37 +00:00
2017-12-13 16:30:39 +00:00
2019-03-12 05:10:41 +00:00
2018-10-12 00:32:45 +00:00
2019-07-24 23:04:59 +00:00
2018-08-18 19:45:56 +00:00
2018-06-01 13:26:45 +00:00
2019-02-20 09:38:19 +00:00
2019-06-19 13:30:50 +00:00
2019-07-24 23:04:59 +00:00
2018-11-20 14:58:41 +00:00
2019-07-30 17:09:58 +00:00
2018-06-01 13:26:45 +00:00
2019-07-23 20:59:36 +00:00
2018-10-23 21:43:41 +00:00
2019-07-28 16:07:27 +00:00