This fixes a bug in wine when running on 9pfs where short reads would occur, causing binaries to be loaded incorrectly. All other filesystems on Linux ignore O_NONBLOCK for regular files, so this should not affect them.
Thanks to Paul Gofman for the advice on this fix.
---
Ref https://gitlab.winehq.org/wine/wine/-/merge_requests/3390 for my original attempt at fixing this, particularly https://gitlab.winehq.org/wine/wine/-/merge_requests/3390#note_40093 which describes the strange situation `O_NONBLOCK` finds itself in on filesystems.
The risk with this MR is that fifo, unix sockets or other special files opened via `open_unix_file` in ntdll will now have changed behaviour - but my quick look suggests that this is unlikely, as `open_unix_file` is only used for:
- `dlls/ntdll/unix/file.c`: `NtCreateFile` and `NtDeleteFile`
- `dlls/ntdll/unix/process.c`: loading PE information and getting a dirfd for the current directory
- `dlls/ntdll/unix/env.c`: `open_nls_data_file`
- `dlls/ntdll/unix/loader.c`: dll load functions
- `dlls/ntdll/unix/registry.c`: `NtLoadKeyEx`
cc @gofman
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3445
The read and pread syscalls are permitted to return fewer bytes than requested (unlike the fread libc call which will only perform a short read on error or EOF). This is most likely to occur when binaries are located on slower filesystems (e.g. NFS or 9pfs)
ffab9d9 is a relatively recent regression here, but a lot of the code appears to be much older (e.g. the read call in 341b7dc)
In this MR I've focused on ntdll, but I see a lot of similar mishandling of the pread return value in `server/`. I will raise a bug as I don't intend to create a follow up MR at this time.
--
v3: ntdll: Correctly handle pread short reads
https://gitlab.winehq.org/wine/wine/-/merge_requests/3390
On Fri Jul 28 02:22:22 2023 +0000, **** wrote:
> Marvin replied on the mailing list:
> ```
> Hi,
> It looks like your patch introduced the new failures shown below.
> Please investigate and fix them before resubmitting your patch.
> If they are not new, fixing them anyway would help a lot. Otherwise
> please ask for the known failures list to be updated.
> The tests also ran into some preexisting test failures. If you know how
> to fix them that would be helpful. See the TestBot job for the details:
> The full results can be found at:
> https://testbot.winehq.org/JobDetails.pl?Key=135341
> Your paranoid android.
> === debian11 (32 bit zh:CN report) ===
> Report validation errors:
> d3d11:d3d11 crashed (c0000005)
> ```
This looks like https://bugs.winehq.org/show_bug.cgi?id=53217 so I don't think it's new
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3431#note_40653