January 2024 - wine-devel

Mailing list traffic
by Francois Gouget 19 Apr '24

19 Apr '24

With GitLab and the spinning off of commit messages to wine-gitlab I think the traffic estimates on the mailing list page need to be updated... at least for wine-devel: it no longer has 50 messages per day. https://www.winehq.org/forums (unfortunately there is no unit on the little per mailing-list graph) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

4 3

Wine staging 9.0 release
by Alistair Leslie-Hughes 10 Feb '24

10 Feb '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0 (505 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

4 5

kernelbase: adding support for callback in CopyFileEx, and implementing CopyFile2
by sendtokartavya＠gmail.com 08 Feb '24

08 Feb '24

context: https://bugs.winehq.org/show_bug.cgi?id=55897 While implementing CopyFile2, I noticed that CopyFileEx does not respect the progress callback and never calls it. The tests too assume that it will not be invoked other than in the case of a file having multiple streams, which is not something that Wine supports. There seem to have been multiple efforts to implement this functionality (in 2022 and 2013) but I can't tell find any reasoning for why they were not successful. Would implementing this be a desirable contribution? I don't know how to get assigned to an issue on Bugzilla. I read the Wine Developers Wiki but it doesn't seem to have the information, so I left a comment in the bug log itself.

4 3

[RFC PATCH v2 00/29] NT synchronization primitive driver
by Elizabeth Figura 31 Jan '24

31 Jan '24

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 29/29 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize wait-for-any at the expense of wait-for-all as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_KILL_OWNER, which will mark mutexes owned by that thread (if any) as abandoned. * This implementation uses a misc device mostly because it seemed like the simplest and least obtrusive option. Besides simplicitly of implementation, the only particularly interesting advantage is the ability to create an arbitrary number of "contexts" (corresponding to Windows virtual machines) which are self-contained and shareable across multiple processes; this maps nicely to file descriptions (i.e. struct file). This is not impossible with syscalls of course but would require an extra argument. On the other hand, there is no reason to forbid using ntsync by default from user-mode processes, and (as far as I understand) to do so with a char device requires explicit configuration by e.g. udev or init. Since this is done with e.g. fuse, I assume this is the model to follow, but I may have chosen something deprecated. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. It is not a hard requirement, though. == Previous versions == Changes in v2: * Send the whole series instead of just the first few patches. * Try to add more description to each patch, as a short documentation of the functions to be implemented. A more complete documentation of all aspects of the driver is provided in the contents of the last patch. * Objects are now files rather than indices into a table. This prevents a process from changing the state of an object which it should not have access to. Suggested by Andy Lutorminski. * Because the device no longer inherently has a table of all objects, marking a thread's owned mutexes as abandoned is now done through an ioctl on the mutex. * Change the names of a couple ioctls to be a bit less odd (PUT_SEM -> SEM_POST, PUT_MUTEX -> MUTEX_UNLOCK), and to reflect that they are ioctls on an object rather than on the device. * Pass the timeout for wait functions as a bare u64 (in ns), per Arnd Bergmann, with U64_MAX used to indicate no timeout. I originally indicated that I would change the timeout to be relative, but on reflection ended up keeping it as absolute, as this results in the least number of calls to get the current time (i.e. one). * Use compat_ptr_ioctl(), per Arnd Bergmann. * Remove the fixed minor number and module alias, per Greg Kroah-Hartman. * Allocate the fds array on stack in setup_wait(). This array takes up 260 bytes. * Link to v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (29): ntsync: Introduce the ntsync driver and character device. ntsync: Introduce NTSYNC_IOC_CREATE_SEM. ntsync: Introduce NTSYNC_IOC_SEM_POST. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. Documentation/userspace-api/index.rst | 1 + .../userspace-api/ioctl/ioctl-number.rst | 2 + Documentation/userspace-api/ntsync.rst | 390 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 1132 ++++++++++++++ include/uapi/linux/ntsync.h | 58 + tools/testing/selftests/Makefile | 1 + .../testing/selftests/drivers/ntsync/Makefile | 8 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1300 +++++++++++++++++ 12 files changed, 2912 insertions(+) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c -- 2.43.0

1 29

The future of WineConf
by Alexandre Julliard 27 Jan '24

27 Jan '24

Folks, As you may have noticed, we haven't been making any plans for WineConf this year. Jeremy has been busy preparing his retirement, and I haven't been pushing it either, mostly because I'm not convinced that we want to continue the traditional WineConf model. Even though we skipped a few years because of the pandemic, attendance at last year's WineConf wasn't great. We also suggested meeting at FOSDEM in February, like we did in previous years, but essentially no one showed up. So I'm wondering whether there is still enough interest for a traditional WineConf, or whether we should try a different approach, to maybe capture some of the recent excitement around gaming and downstream uses of Wine in general. I'd like to hear your thoughts. Should we do a Proton conference, or join some kind of gaming-related event? Do people even want to travel to conferences anymore? What kind of event would you be interested in, particularly those of you who don't show up to the traditional WineConf? -- Alexandre Julliard julliard(a)winehq.org

14 19

Wine staging 9.1 release
by Alistair Leslie-Hughes 27 Jan '24

27 Jan '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.1 (508 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * include: Add more D3D_FEATURE_LEVEL_ defines. * oleaut32: Do not reimplement OleLoadPicture in OleLoadPicturePath. * oleaut32: Factor out stream creation from OleLoadPicturePath. * oleaut32: Implement OleLoadPictureFile. (v2) * user32/tests: Add tests for clicking through layered window. * user32/tests: Add tests for window region of layered windows. Added: * [50148] msi: Process cabinet files only when one is supplied. * [51965] msxml3: IMXWrite::output to support DOMDocument. * [52128] scrrun: Implement IFileSystem3 MoveFolder. Updated: * vkd3d-latest * user32-Mouse_Message_Hwnd (Rebased and enabled) * wined3d-bindless-texture (Rebased and enabled) * ddraw-version-check (Rebased and enabled) * vcomp_for_dynamic_init_i8 Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

Staging patchset update
by DodoGTA GT 27 Jan '24

27 Jan '24

Hello, I just updated the vkd3d-latest staging patchset with the latest vkd3d commit (attached below) Hopefully someone can push this to wine-staging Thanks, Aida/Echo (DodoGTA)

2 1

[RFC PATCH 0/9] NT synchronization primitive driver
by Elizabeth Figura 25 Jan '24

25 Jan '24

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuills, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == This is the first part of a 32-patch series. The series comprises 17 patches which contain the actual implementation, 13 which provide self-tests, 1 to update the MAINTAINERS file, and 1 to add API documentation. The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. Since I do not expect familiarity with Windows syscalls, however, and especially not with some of the more subtle or unspecified behaviour that they provide, the documentation patch included in the series also describes the intended behaviour in detail, and can be used as a specification for the rest of the series. The entire series can be retrieved or browsed here: https://repo.or.cz/linux/zf.git/shortlog/refs/heads/ntsync4 The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync4 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize the wait-for-any pattern at the expense of the wait-for-all pattern as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_KILL_OWNER, which will mark mutexes owned by that thread (if any) as abandoned. * This implementation uses a misc device mostly because it seemed like the simplest and least obtrusive option. Besides simplicitly of implementation, the only particularly interesting advantage is the ability to create an arbitrary number of "contexts" (corresponding to Windows virtual machines) which are self-contained and shareable across multiple processes; this maps nicely to file descriptions (i.e. struct file). This is not impossible with syscalls of course but would require an extra argument. On the other hand, there is no reason to forbid using ntsync by default from user-mode processes, and (as far as I understand) to do so with a char device requires explicit configuration by e.g. udev or init. Since this is done with e.g. fuse, I assume this is the model to follow, but I may have chosen something deprecated. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. I am not aware of any reason why being a module is required, though. * The misc minor number has not been reserved with LANANA. I am not sure at what point in the process this makes the most sense, but since this is still only an RFC I've abstained from doing so yet. Elizabeth Figura (9): ntsync: Introduce the ntsync driver and character device. ntsync: Reserve a minor device number and ioctl range. ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE. ntsync: Introduce NTSYNC_IOC_PUT_SEM. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_PUT_MUTEX. ntsync: Introduce NTSYNC_IOC_KILL_OWNER. Documentation/admin-guide/devices.txt | 3 +- .../userspace-api/ioctl/ioctl-number.rst | 2 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 916 ++++++++++++++++++ include/linux/miscdevice.h | 1 + include/uapi/linux/ntsync.h | 53 + 7 files changed, 984 insertions(+), 1 deletion(-) create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d -- 2.43.0

3 15

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 25 Jan '24

25 Jan '24

On Thursday, 25 January 2024 11:02:26 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 23:28, Elizabeth Figura wrote: > > On Wednesday, 24 January 2024 13:52:52 CST Arnd Bergmann wrote: > >> On Wed, Jan 24, 2024, at 19:02, Elizabeth Figura wrote: > >> > That'd be nicer in general. I think there was some documentation that > >> > advised using timespec64 for new ioctl interfaces but it may have been > >> > outdated or misread. > >> > >> It's probably something I wrote. It depends a bit on > >> whether you have an absolute or relative timeout. If > >> the timeout is relative to the current time as I understand > >> it is here, a 64-bit number seems more logical to me. > >> > >> For absolute times, I would usually use a __kernel_timespec, > >> especially if it's CLOCK_REALTIME. In this case you would > >> also need to specify the time domain. > > > > Currently the interface does pass it as an absolute time, with the > > domain implicitly being MONOTONIC. This particular choice comes from > > process/botching-up-ioctls.rst, which is admittedly focused around GPU > > ioctls, but the rationale of having easily restartable ioctls applies > > here too. > > Ok, I was thinking of Documentation/driver-api/ioctl.rst, which > has similar recommendations. > > > (E.g. Wine does play games with signals, so we do want to be able to > > interrupt arbitrary waits with EINTR. The "usual" fast path for ntsync > > waits won't hit that, but we want to have it work.) > > > > On the other hand, if we can pass the timeout as relative, and write it > > back on exit like ppoll() does [assuming that's not proscribed], that > > would presumably be slightly better for performance. > > I've seen arguments go either way between absolute and relative > times, just pick whatever works best for you here. > > > When writing the patch I just picked the recommended option, and didn't > > bother doing any micro-optimizations afterward. > > > > What's the rationale for using timespec for absolute or written-back > > timeouts, instead of dealing in ns directly? I'm afraid it's not > > obvious to me. > > There is no hard rule either way, I mainly didn't like the > indirect pointer to the timespec that you have here. For > traditional unix-style interfaces, a timespec with CLOCK_REALTIME > times usually makes sense since that is what user space is > already using elsewhere, but you probably don't need to > worry about that. In theory, the single u64 CLOCK_REALTIME > nanoseconds have the problem of no longer working after year > 2262, but with CLOCK_MONOTONIC that is not a concern anyway. > > Between embedding a __u64 nanosecond value and embedding > a __kernel_timespec, I would pick whichever avoids converting > a __u64 back into a timespec, as that is an expensive > operation at least on 32-bit code. Makes sense. I'll probably switch to using a relative and written-back u64 then, thanks!

1 0

Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.
by Elizabeth Figura 25 Jan '24

25 Jan '24

On Thursday, 25 January 2024 10:47:49 CST Arnd Bergmann wrote: > On Thu, Jan 25, 2024, at 04:42, Elizabeth Figura wrote: > > On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote: > >> On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote: > >> > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > >> [There is also a potential problem where some broken applications > >> create a million (literally) sync objects. Making these into files runs > >> into NOFILE. We did specifically push distributions and systemd to > >> increase those limits because an older solution *did* use eventfds and > >> *did* run into those limits. Since that push was successful I don't > >> know if this is *actually* a concern anymore, but avoiding files is > >> probably not a bad thing either.] > > > > Of course, looking at it from a kernel maintainer's perspective, it > > wouldn't be insane to do this anyway. If we at some point do start to > > care about cross- process isolation in this way, or if another NT > > emulator wants to use this interface and does care about cross-process > > isolation, it'll be necessary. At least it'd make sense to make them > > separate files even if we don't implement granular permission handling > > just yet. > > I can think of a few other possible benefits of going with > per-mutex file descriptors: > > - being able to use poll() for waiting on them individually in > combination with other file descriptor based events (socket, > signalfd, pidfd, ...) I can say for sure this isn't going to be useful for Wine, at least not with the current design. It also doesn't really mesh well with the NT design in the first place. NTSYNC_IOC_WAIT_ANY differs from poll() in two major ways: it consumes state of most object types, and (as coded here) it needs the owner thread ID to be specifically passed for mutexes. Anyway, as Alexandre has informed me I clearly have misunderstood our requirements, so I'm going to try to put together something using files instead.

1 0

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 13:52:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 19:02, Elizabeth Figura wrote: > > On Wednesday, 24 January 2024 01:56:52 CST Arnd Bergmann wrote: > >> On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > >> > >> > + if (args->timeout) { > >> > + struct timespec64 to; > >> > + > >> > + if (get_timespec64(&to, u64_to_user_ptr(args->timeout))) > >> > + return -EFAULT; > >> > + if (!timespec64_valid(&to)) > >> > + return -EINVAL; > >> > + > >> > + timeout = timespec64_to_ns(&to); > >> > + } > >> > >> Have you considered just passing the nanosecond value here? > >> Since you do not appear to write it back, that would avoid > >> the complexities of dealing with timespec layout differences > >> and indirection. > > > > That'd be nicer in general. I think there was some documentation that advised > > using timespec64 for new ioctl interfaces but it may have been outdated or > > misread. > > It's probably something I wrote. It depends a bit on > whether you have an absolute or relative timeout. If > the timeout is relative to the current time as I understand > it is here, a 64-bit number seems more logical to me. > > For absolute times, I would usually use a __kernel_timespec, > especially if it's CLOCK_REALTIME. In this case you would > also need to specify the time domain. Currently the interface does pass it as an absolute time, with the domain implicitly being MONOTONIC. This particular choice comes from process/botching-up-ioctls.rst, which is admittedly focused around GPU ioctls, but the rationale of having easily restartable ioctls applies here too. (E.g. Wine does play games with signals, so we do want to be able to interrupt arbitrary waits with EINTR. The "usual" fast path for ntsync waits won't hit that, but we want to have it work.) On the other hand, if we can pass the timeout as relative, and write it back on exit like ppoll() does [assuming that's not proscribed], that would presumably be slightly better for performance. When writing the patch I just picked the recommended option, and didn't bother doing any micro-optimizations afterward. What's the rationale for using timespec for absolute or written-back timeouts, instead of dealing in ns directly? I'm afraid it's not obvious to me. --Zeb

1 0

Re: [RFC PATCH 8/9] ntsync: Introduce NTSYNC_IOC_PUT_MUTEX.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:42:19 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > @@ -738,6 +803,8 @@ static long ntsync_char_ioctl(struct file *file, > > diff --git a/include/uapi/linux/ntsync.h b/include/uapi/linux/ntsync.h > > index 26d1b3d4847f..2e44e7e77776 100644 > > --- a/include/uapi/linux/ntsync.h > > +++ b/include/uapi/linux/ntsync.h > > @@ -46,5 +46,7 @@ struct ntsync_wait_args { > > struct ntsync_wait_args) > > #define NTSYNC_IOC_CREATE_MUTEX _IOWR(NTSYNC_IOC_BASE, 5, \ > > struct ntsync_mutex_args) > > +#define NTSYNC_IOC_PUT_MUTEX _IOWR(NTSYNC_IOC_BASE, 6, \ > > + struct ntsync_mutex_args) > > > > In your implementation, this argument is not written back to > user space, so I think this should be _IOW rather than than _IORW. > > Again, no practical difference here. Hm, but there is a put_user() at the end of the function, or am I missing something?

1 0

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:56:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > > + if (args->timeout) { > > + struct timespec64 to; > > + > > + if (get_timespec64(&to, u64_to_user_ptr(args->timeout))) > > + return -EFAULT; > > + if (!timespec64_valid(&to)) > > + return -EINVAL; > > + > > + timeout = timespec64_to_ns(&to); > > + } > > Have you considered just passing the nanosecond value here? > Since you do not appear to write it back, that would avoid > the complexities of dealing with timespec layout differences > and indirection. That'd be nicer in general. I think there was some documentation that advised using timespec64 for new ioctl interfaces but it may have been outdated or misread. > > > + ids = kmalloc_array(count, sizeof(*ids), GFP_KERNEL); > > + if (!ids) > > + return -ENOMEM; > > + if (copy_from_user(ids, u64_to_user_ptr(args->objs), > > + array_size(count, sizeof(*ids)))) { > > + kfree(ids); > > + return -EFAULT; > > + } > > This looks like memdup_user() would be slightly simpler. That's useful, thanks.

1 0

Re: [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 06:32:13 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 09:43:09PM -0600, Elizabeth Figura wrote: > > > Why do you need a fixed minor number? Can't your userspace handle > > > dynamic numbers? What systems require a static value? > > > > I believe I added this because it's necessary for MODULE_ALIAS (and, more > > broadly, because I was following the example of vaguely comparable devices > > like /dev/loop-control). I suppose I could instead just remove MODULE_ALIAS > > (or even remove the ability to compile ntsync as a module entirely). > > Do you really need MODULE_ALIAS()? Having it for char devices to be > auto-loaded is not generally considered a good idea anymore as systems > should have the module loaded before userspace goes and asks for it. > > It also reduces suprises when any random userspace program can cause > kernel modules to be loaded for no real reason. I think there's no reason we can't make loading the system's problem. I'll remove it in v2.

1 0

Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:38:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > ntsync uses a misc device as the simplest and least intrusive uAPI interface. > > > > Each file description on the device represents an isolated NT instance, intended > > to correspond to a single NT virtual machine. > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > I'm looking at the ioctl interface to ensure it's well-formed. > > Your patches look ok from that perspective, but there are a > few minor things I would check for consistency here: > > > + > > +static const struct file_operations ntsync_fops = { > > + .owner = THIS_MODULE, > > + .open = ntsync_char_open, > > + .release = ntsync_char_release, > > + .unlocked_ioctl = ntsync_char_ioctl, > > + .compat_ioctl = ntsync_char_ioctl, > > + .llseek = no_llseek, > > +}; > > The .compat_ioctl pointer should point to compat_ptr_ioctl() > since the actual ioctl commands all take pointers instead > of interpreting the argument as a number. > > On x86 and arm64 this won't make a difference as compat_ptr() > is a nop. Thanks; will fix.

1 0

Re: [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 18:54:02 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:21PM -0600, Elizabeth Figura wrote: > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > --- > > Note, we can't take patches without any changelog text, and you don't > want us to :) > > > Documentation/admin-guide/devices.txt | 3 ++- > > Documentation/userspace-api/ioctl/ioctl-number.rst | 2 ++ > > drivers/misc/ntsync.c | 3 ++- > > include/linux/miscdevice.h | 1 + > > 4 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/admin-guide/devices.txt > > b/Documentation/admin-guide/devices.txt index 94c98be1329a..041404397ee5 > > 100644 > > --- a/Documentation/admin-guide/devices.txt > > +++ b/Documentation/admin-guide/devices.txt > > @@ -376,8 +376,9 @@ > > > > 240 = /dev/userio Serio driver testing device > > 241 = /dev/vhost-vsock Host kernel driver for virtio vsock > > 242 = /dev/rfkill Turning off radio transmissions (rfkill) > > > > + 243 = /dev/ntsync NT synchronization primitive device > > > > - 243-254 Reserved for local use > > + 244-254 Reserved for local use > > Why do you need a fixed minor number? Can't your userspace handle > dynamic numbers? What systems require a static value? I believe I added this because it's necessary for MODULE_ALIAS (and, more broadly, because I was following the example of vaguely comparable devices like /dev/loop-control). I suppose I could instead just remove MODULE_ALIAS (or even remove the ability to compile ntsync as a module entirely). It's a bit difficult to figure out what's the preferred way to organize things like this (there not being a lot of precedent for this kind of driver) so I'd appreciate any direction. --Zeb

1 0

Re: [RFC PATCH 3/9] ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 19:14:17 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:22PM -0600, Elizabeth Figura wrote: > > +static int ntsync_create_sem(struct ntsync_device *dev, void __user > > *argp) > > +{ > > + struct ntsync_sem_args __user *user_args = argp; > > + struct ntsync_sem_args args; > > + struct ntsync_obj *sem; > > + __u32 id; > > + int ret; > > + > > + if (copy_from_user(&args, argp, sizeof(args))) > > + return -EFAULT; > > + > > + if (args.count > args.max) > > + return -EINVAL; > > No bounds checking on count or max? > > What's the relationship between count and max? Indeed, no bounds checking. The counter is just the semaphore's internal value and has no meaning other than that. It's basically like an EFD_SEMAPHORE, except that the maximum is configurable rather than always being 2**64-2. > Some sort of real > documentation is needed here, the changelog needs to explain this. Or > somewhere, but as-is, this patch series is pretty unreviewable as I > can't figure out how to review it because I don't know what it wants to > do. There is some comprehensive documentation in the series, but for ease of review I will try to write a basic description of the API in each relevant patch in v2.

1 0

Re: [RFC PATCH 0/9] NT synchronization primitive driver
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 18:59:35 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:19PM -0600, Elizabeth Figura wrote: > > == Patches == > > > > This is the first part of a 32-patch series. The series comprises 17 patches > > which contain the actual implementation, 13 which provide self-tests, 1 to > > update the MAINTAINERS file, and 1 to add API documentation. > > 32 patches? I only see 9 here, why not submit them all? Because Documentation/process/submitting-patches.rst makes a point of asking people not to submit large patch series (and it matches the expectation of other projects I've worked with—that patches would be submitted and reviewed a few at a time). I suppose I've misunderstood that advice, though. I'll resend with the entire series. Sorry for the noise.

1 0

9.0 release notes, please review
by Alexandre Julliard 18 Jan '24

18 Jan '24

Folks, We've once again made very good progress on the regressions during this code freeze period, thanks to everybody for your help! It's now time for the final release. I've attached the tentative release notes, written with help from Jacek, Rémi and Zeb, and for the first time in Markdown format <g>. Please review these and let me know if anything is wrong, missing, or unclear. -- Alexandre Julliard julliard(a)winehq.org

8 17

Force feedback auto center implementation?
by Tyson Whitehead 13 Jan '24

13 Jan '24

Would like to get disabling force feedback auto-centering working so that trimming will work properly with force feedback devices in flight simulators. Currently the call to disable it is a stub static HRESULT dinput_device_set_property( IDirectInputDevice8W *iface, const GUID *guid, const DIPROPHEADER *header ) { ... case (DWORD_PTR)DIPROP_AUTOCENTER: { const DIPROPDWORD *value = (const DIPROPDWORD *)header; if (!(impl->caps.dwFlags & DIDC_FORCEFEEDBACK)) return DIERR_UNSUPPORTED; if ( header->dwHow != DIPH_DEVICE) return DIERR_INVALIDPARAM; impl->vtbl->set_property( iface, FIXME( "DIPROP_AUTOCENTER stub!\n" ); impl->autocenter = value->dwData; return DI_OK; } ... } After having looked through the wine, SDL, and kernel code and read up on the force feedback HID physical interface device (PID) usage table reports, I am guessing this was left as a stub because it doesn't fit in with the current design of dipnut communicating with the backend via HID reports. The issue being that auto centering, unlike everything else, isn't part of the PID specification, so there isn't a predefined report that can be used for this (see table 0x0f) https://www.usb.org/document-library/hid-usage-tables-14 Although I am no wine or Windows code expert, I am guess this leaves the following options - leave it disabled in the backend and emulate it via a frontend spring effect - abuse an existing HID report to communicate it - add a WINE specific HID report to communicate it - add a WINE specific IOCTL to communicate it For the first option, I mean have the winebus backends disable it via the kernel or an SDL call and then have the dinput layer enable simulate it by adding a default spring effect. This then lets the dinput frontend disable it again by removing or disabling its spring effect. For the second one I mean something like reserve an effect ID for specifying auto centering. Both of these are inspired by the fact that from the kernel code, it seems auto centering for HID devices is an undocumented use of the first effect ID for a spring effect https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… Would be interesting in knowing what sort of implementation people think would be best and acceptable for inclusion into wine? Thanks! Tyson

2 8

Wine staging 9.0-rc5 release
by Alistair Leslie-Hughes 13 Jan '24

13 Jan '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc5 (500 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

vkd3d request
by Alistair Leslie-Hughes 09 Jan '24

09 Jan '24

Hi All, Now that vkd3d 1.10 is out, I have a request for developers. Would it be possible to include a file of all games/applications that have fixes when they are committed. It's too hard to track unless you really doing serious work with it. The whole concept of including the latest vk3d3d in staging was to help with testing but if people don't know what to test, they wont. This would also, give a nice section in the ANNOUNCE as to what now works. :) Best Regards Alistair

3 4

[PATCH] po: Update Asturian translation
by Enol P. 08 Jan '24

08 Jan '24

2 2

Wine staging 9.0-rc4 release
by Alistair Leslie-Hughes 06 Jan '24

06 Jan '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc4 (500 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

Re: x86 SGDT emulation for Wine
by H. Peter Anvin 05 Jan '24

05 Jan '24

On January 4, 2024 6:47:04 PM PST, Andrew Cooper <andrew.cooper3(a)citrix.com> wrote: >On 05/01/2024 1:02 am, H. Peter Anvin wrote: >> Note that there is no fundamental reason you cannot run the Unix user space code inside the VM container, too; you only need to vmexit on an actual system call. > >I know this is going on a tangent, but getting a VMExit on the SYSCALL >instruction is surprisingly difficult. > >The "easy" way is to hide EFER.SCE behind the guests back, intercept #UD >and emulate both the SYSCALL and SYSRET instructions. It's slow, but it >works. > >However, FRED completely prohibits tricks like this, because what you >cannot reasonably do is clear CR4.FRED behind the back of a guest >kernel. You'd have to intercept and emulate all event sources in order >to catch SYSCALL. > >I raised this as a concern during early review, but Intel has no >official feature to take a VMExit on privilege change, and FRED >(rightly) wasn't an appropriate vehicle to add such a feature, so it was >deemed not an issue that the FRED design would break the unofficial ways >that people were using to intercept/monitor/etc system calls. > >~Andrew > >P.S. Yes, there are more adventurous tricks like injecting a thunk into >the guest kernel and editing MSR_LSTAR behind the guest's back. In >principle a similar trick works with FRED, but in order to do this to >Windows, you also need to hook checkpatch to blind it to the thunk, and >this is horribly invasive. *In this case* it shouldn't be a problem, since the "guest operating system" would be virtually nonexistent and entirely puppeted by Wine.

1 0

Re: x86 SGDT emulation for Wine
by H. Peter Anvin 05 Jan '24

05 Jan '24

On January 3, 2024 7:19:02 AM PST, Sean Christopherson <seanjc(a)google.com> wrote: >On Tue, Jan 02, 2024, Elizabeth Figura wrote: >> On Wednesday, December 27, 2023 5:58:19 PM CST H. Peter Anvin wrote: >> > On December 27, 2023 2:20:37 PM PST, Elizabeth Figura <zfigura(a)codeweavers.com> wrote: >> > >Hello all, >> > > >> > >There is a Windows 98 program, a game called Nuclear Strike, which wants to >> > >do some amount of direct VGA access. Part of this is port I/O, which >> > >naturally throws SIGILL that we can trivially catch and emulate in Wine. >> > >The other part is direct access to the video memory at 0xa0000, which in >> > >general isn't a problem to catch and virtualize as well. >> > > >> > >However, this program is a bit creative about how it accesses that memory; >> > >instead of just writing to 0xa0000 directly, it looks up a segment >> > >descriptor whose base is at 0xa0000 and then uses the %es override to >> > >write bytes. In pseudo-C, what it does is: > >... > >> > A prctl() to set the UMIP-emulated return values or disable it (giving >> > SIGILL) would be easy enough. >> > >> > For the non-UMIP case, and probably for a lot of other corner cases like >> > relying on certain magic selector values and what not, the best option >> > really would be to wrap the code in a lightweight KVM container. I do *not* >> > mean running the Qemu user space part of KVM; instead have Wine interface >> > with /dev/kvm directly. >> > >> > Non-KVM-capable hardware is basically historic at this point. >> >> Sorry for the late response—I've been trying to do research on what would be >> necessary to use KVM (plus I made the poor choice of sending this during the >> holiday season...) >> >> I'm concerned that KVM is going to be difficult or even intractable. Here are >> some of the problems that I (perhaps incorrectly) understand: >> >> * As I am led to understand, there can only be one hypervisor on the machine >> at a time, > >No. Only one instance of KVM-the-module is allowed, but there is no arbitrary >limit on the number of VMs that userspace can create. The only meaningful >limitation is memory, and while struct kvm isn't tiny, it's not _that_ big. > >> and KVM has a hard limit on the number of vCPUs. >> >> The obvious way to use KVM for Wine is to make each (guest) thread a vCPU. >> That will, at the very least, run into the thread limit. In order to avoid >> that we'd need to ship a whole scheduler, which is concerning. That's a huge >> component to ship and a huge burden to keep updated. It also means we need to >> hoist *all* of the ipc and sync code into the guest, which will take an >> enormous amount of work. >> >> Moreover, because there can only be one hypervisor, and Wine is a multi- >> process beast, that means that we suddenly need to throw every process into >> the same VM. > >As above, this is wildly inaccurate. The only KVM restriction with respect to >processes is that a VM is bound to the process (address space) that created the >VM. There are no restrictions on the number of VMs that can be created, e.g. a >single process can create multiple VMs. > >> That has unfortunate implications regarding isolation (it's been a dream for >> years that we'd be able to share a single wine "VM" between multiple users), >> it complicates memory management (though perhaps not terribly?). And it means >> you can only have one Wine VM at a time, and can't use Wine at the same time >> as a "real" VM, neither of which are restrictions that currently exist. >> >> And it's not even like we can refactor—we'd have to rewrite tons of code to >> work inside a VM, but also keep the old code around for the cases where we >> don't have a VM and want to delegate scheduling to the host OS. >> >> * Besides scheduling, we need to exit the VM every time we would normally call >> into Unix code, which in practice is every time that the application does an >> NT syscall, or uses a library which we delegate to the host (including e.g. >> GPU, multimedia, audio...) > >Maybe I misinterpreted Peter's suggestion, but at least in my mind I wasn't thinking >that the entire Wine process would run in a VM, but rather Wine would run just >the "problematic" code in a VM. > Yes, the idea would be that you would run the "problematic" code inside a VM *mapped 1:1 with the external address space*, i.e. use KVM simply as a special execution mode to give you more control of the fine grained machine state like the GDT. The code that you don't want executed in the VM context simply leave unmapped in the VM page tables and set up #PF to always exit the VM context.

2 2

x86 SGDT emulation for Wine
by Elizabeth Figura 03 Jan '24

03 Jan '24

Hello all, There is a Windows 98 program, a game called Nuclear Strike, which wants to do some amount of direct VGA access. Part of this is port I/O, which naturally throws SIGILL that we can trivially catch and emulate in Wine. The other part is direct access to the video memory at 0xa0000, which in general isn't a problem to catch and virtualize as well. However, this program is a bit creative about how it accesses that memory; instead of just writing to 0xa0000 directly, it looks up a segment descriptor whose base is at 0xa0000 and then uses the %es override to write bytes. In pseudo-C, what it does is: int get_vga_selector() { sgdt(&gdt_size, &gdt_ptr); sldt(&ldt_segment); ++gdt_size; descriptor = gdt_ptr; while (descriptor->base != 0xa0000) { ++descriptor; gdt_size -= sizeof(*descriptor); if (!gdt_size) break; } if (gdt_size) return (descriptor - gdt_ptr) << 3; descriptor = gdt_ptr[ldt_segment >> 3]->base; ldt_size = gdt_ptr[ldt_segment >> 3]->limit + 1; while (descriptor->base != 0xa0000) { ++descriptor; ldt_size -= sizeof(*descriptor); if (!ldt_size) break; } if (ldt_size) return (descriptor - ldt_ptr) << 3; return 0; } Currently we emulate IDT access. On a read fault, we execute sidt ourselves, check if the read address falls within the IDT, and return some dummy data from the exception handler if it does [1]. We can easily enough implement GDT access as well this way, and there is even an out-of-tree patch written some years ago that does this, and helps the game run. However, there are two problems that I have observed or anticipated: (1) On systems with UMIP, the kernel emulates sgdt instructions and returns a consistent address which we can guarantee is invalid. However, it also returns a size of zero. The program doesn't expect this (cf. the way the loop is written above) and I believe will effectively loop forever in that case, or until it finds the VGA selector or hits invalid memory. I see two obvious ways to fix this: either adjust the size of the fake kernel GDT, or provide a switch to stop emulating and let Wine handle it. The latter may very well a more sustainable option in the long term (although I'll admit I can't immediately come up with a reason why, other than "we might need to raise the size yet again".) Does anyone have opinions on this particular topic? I can look into writing a patch but I'm not sure what the best approach is. (2) On 64-bit systems without UMIP, sgdt returns a truncated address when in 32-bit mode. This truncated address in practice might point anywhere in the address space, including to valid memory. In order to fix this, we would need the kernel to guarantee that the GDT base points to an address whose bottom 32 bits we can guarantee are inaccessible. This is relatively easy to achieve ourselves by simply mapping those pages as noaccess, but it also means that those pages can't overlap something we need; we already go to pains to make sure that certain parts of the address space are free. Broadly anything above the 2G boundary *should* be okay though. Is this feasible? We could also just decide we don't care about systems without UMIP, but that seems a bit unfortunate; it's not that old of a feature. But I also have no idea how hard it would be to make this kind of a guarantee on the kernel side. This is also, theoretically, a problem for the IDT, except that on the machines I've tested, the IDT is always at 0xfffffe0000000000. That's not great either (it's certainly caused some weirdness and confusion when debugging, when we unexpectedly catch an unrelated null pointer access) but it seems to work in practice. --Zeb [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/ instr.c#l702

3 3

Handling stack overflow
by Dāvis Mosāns 01 Jan '24

01 Jan '24

Hi, I've been looking to get League of Legends work in Wine. The issue is that their Anti-Cheat hooks bunch of functions in ntdll.dll directly by prepending `jmp their_code` before the real function and it seems it messes something up. Anyway, topic of this email is about handling of stack overflow. When their exception handler gets messed up it is invoked recursively until stack overflow. And because it happened while it was in critical section it causes other threads to deadlock. My question is how such case should be handled? When thread is killed should lock be released so other threads can still proceed? Or maybe just whole process should be killed if any thread has stack overflow? To me it looks like in Windows when exception handler goes too deep then Just in Time debugger is invoked or if that's not enabled then process is killed with EXCEPTION_ACCESS_VIOLATION (maybe because it tried to access beyond end of stack?) Log looks like: [...] 0120:trace:seh:call_handler calling handler 00006FFFFFC97030 (rec=00007F3214C54360, frame=00007F3214D4E710 context=00007F3214C538D0, dispatch=00007F3214C537A0) 0120:trace:seh:call_handler handler at 00006FFFFFC97030 returned 2 0120:trace:seh:call_stack_handlers nested exception 0120:trace:seh:call_handler calling handler 00000001413B347C (rec=00007F3214C54360, frame=00007F3214D4F570 context=00007F3214C538D0, dispatch=00007F3214C537A0) 0120:err:virtual:virtual_setup_exception stack overflow 2576 bytes addr 0x6ffff9e66327 stack 0x7f3214c505f0 (0x7f3214c50000-0x7f3214c51000-0x7f3214d50000) 0124:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0124, blocked by 0120, retrying (60 sec) 011c:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 011c, blocked by 0120, retrying (60 sec) [...] // stuck like this And several threads stuck like this Thread 8 (Thread 472 "011c"): #0 0x00006fffffc966d4 in NtWaitForAlertByThreadId () from /opt/wine-lol-staging/lib/wine/x86_64-windows/ntdll.dll #1 0x00006fffffc9db68 in RtlWaitOnAddress (addr=addr@entry=0x6fffffcae4d8 <loader_section+24>, cmp=cmp@entry=0x6fffffcbda90 <zero>, size=size@entry=4, timeout=timeout@entry=0x7fc37b38f700) at ../wine/dlls/ntdll/sync.c:912 #2 0x00006fffffc9dd06 in wait_semaphore (timeout=<optimized out>, crit=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:196 #3 RtlpWaitForCriticalSection (crit=crit@entry=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:314 #4 0x00006fffffc9df71 in RtlEnterCriticalSection (crit=crit@entry=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:383 #5 0x00006fffffc7667b in loader_init (context=context@entry=0x7fc37b38fb00, entry=entry@entry=0x7fc37b38fb80) at ../wine/dlls/ntdll/loader.c:4405 #6 0x00006fffffc9a444 in LdrInitializeThunk (context=0x7fc37b38fb00, unk2=<optimized out>, unk3=<optimized out>, unk4=<optimized out>) at ../wine/dlls/ntdll/signal_x86_64.c:1716 #7 0x00006ffff88f7954 in ?? () from /mnt/Riot Games/League of Legends/wine/dosdevices/s:/Riot Games/League of Legends/Game/stub.dll Best regards, Dāvis

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2024