On Fri, 24 Apr 2020 at 22:33, Eric Blake <ebl...@redhat.com> wrote: > I don't think this is quite correct. target_to_host_bitmask() silently > ignores unknown bits, and a user that was relying on bit 0x40000000 to > cause an EINVAL will not fail with this change (unless bit 0x40000000 > happens to be one of the bits translated by fcntl_flags_tbl). The > open() syscall is notorious for ignoring unknown bits rather than > failing with EINVAL, and it is has come back to haunt kernel developers; > newer syscalls like dup3() learned from the mistake, and we really do > want to catch unsupported bits up to make it easier for future kernels > to define meanings to those bits without them being silently swallowed > when run on older systems that did not know what those bits meant.
The other reason linux-user sometimes has this sort of manual check of input values is that it can affect which errno value is returned if a call has multiple wrong things (eg a bad address to a pointer parameter and a bad flags value), and some test suites care about the difference. I'm not sure that's the case here, though. I didn't write out my reasoning back in 2017 when I made this page and don't remember it now, but my guess is that it's just that dup3 is only supposed to permit O_CLOEXEC, not any of the other flags that the fcntl_flags_tbl permits and translates. thanks -- PMM
