As recently pointed out:
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03133.html
code that blindly calls fcntl(fd, F_SETFD, 1) rather than performing a
read-modify-write when it intends to add FD_CLOEXEC is broken, in that
it can inadvertently clear other bits.

Thankfully, the culprits fixed in this series are unlikely to be
clearing either FD_CLOFORK (if Linux ever follows Solaris' lead in
adding that), or the new FD_32BIT_MODE being proposed (as the fds in
question are unlikely to have that set) - but it is still better to
write proper code than to set up a bad example prone to copy-and-paste
propagation.  And as these usages are not new to 5.0, I don't see any
reason against waiting until 5.1 to apply them.

Eric Blake (2):
  hax: Fix setting of FD_CLOEXEC
  tools: Fix use of fcntl(F_SETFD) during socket activation

 target/i386/hax-posix.c | 6 +++---
 util/systemd.c          | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.26.1

On Mon, 20 Apr 2020 at 18:53, Eric Blake <eblake@redhat.com> wrote:
>
> As recently pointed out:
> https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03133.html
> code that blindly calls fcntl(fd, F_SETFD, 1) rather than performing a
> read-modify-write when it intends to add FD_CLOEXEC is broken, in that
> it can inadvertently clear other bits.
>
> Thankfully, the culprits fixed in this series are unlikely to be
> clearing either FD_CLOFORK (if Linux ever follows Solaris' lead in
> adding that), or the new FD_32BIT_MODE being proposed (as the fds in
> question are unlikely to have that set) - but it is still better to
> write proper code than to set up a bad example prone to copy-and-paste
> propagation.  And as these usages are not new to 5.0, I don't see any
> reason against waiting until 5.1 to apply them.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM