July 2026 - Wine-Devel - list.winehq.org

[PATCH v2 2/5] selftests: ntsync: add wait argument validation tests

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Add coverage for documented EINVAL cases: zero owner on wait any/all, non-zero pad, and objects from a different /dev/ntsync instance. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- .../testing/selftests/drivers/ntsync/ntsync.c | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c index 12b4b81edf7f..c9fe4d5987ec 100644 --- a/tools/testing/selftests/drivers/ntsync/ntsync.c +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c @@ -1340,4 +1340,48 @@ TEST(stress_wait) close(stress_device); } +TEST(wait_args_validation) +{ + struct ntsync_sem_args sem_args = { .count = 1, .max = 1 }; + struct ntsync_wait_args wait_args = {0}; + struct timespec timeout; + int fd, fd2, sem, ret; + __u32 index; + + fd = open("/dev/ntsync", O_CLOEXEC | O_RDONLY); + ASSERT_GE(fd, 0); + + fd2 = open("/dev/ntsync", O_CLOEXEC | O_RDONLY); + ASSERT_GE(fd2, 0); + + sem = ioctl(fd, NTSYNC_IOC_CREATE_SEM, &sem_args); + EXPECT_GE(sem, 0); + + ret = wait_any(fd, 1, &sem, 0, &index); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + ret = wait_all(fd, 1, &sem, 0, &index); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + clock_gettime(CLOCK_MONOTONIC, &timeout); + wait_args.timeout = timeout.tv_sec * 1000000000ULL + timeout.tv_nsec; + wait_args.count = 0; + wait_args.objs = 0; + wait_args.owner = 123; + wait_args.pad = 1; + ret = ioctl(fd, NTSYNC_IOC_WAIT_ANY, &wait_args); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + ret = wait_any(fd2, 1, &sem, 123, &index); + EXPECT_EQ(-1, ret); + EXPECT_EQ(EINVAL, errno); + + close(sem); + close(fd2); + close(fd); +} + TEST_HARNESS_MAIN -- 2.53.0

July 23, 2026

[PATCH v2 1/5] selftests: ntsync: fix wake_all CREATE_EVENT fd expectation

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> wake_all used EXPECT_EQ(0, objs[3]) after NTSYNC_IOC_CREATE_EVENT. The ioctl returns a non-negative file descriptor on success; check EXPECT_LE(0, objs[3]) like the other CREATE_* paths. The incorrect expectation was noted on list (Mar 2025) but is still present in mainline. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c index e6a37214aa46..12b4b81edf7f 100644 --- a/tools/testing/selftests/drivers/ntsync/ntsync.c +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c @@ -968,7 +968,7 @@ TEST(wake_all) auto_event_args.manual = false; auto_event_args.signaled = true; objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); - EXPECT_EQ(0, objs[3]); + EXPECT_LE(0, objs[3]); wait_args.timeout = get_abs_timeout(1000); wait_args.objs = (uintptr_t)objs; -- 2.53.0

July 23, 2026

[PATCH v2 0/5] ntsync miscellaneous patches

by Elizabeth Figura

This is a resend of a series originally submitted as [1], combined with two patches originally sent as [2]. This supersedes a previous set of patches sent as [3]. The following is the original cover letter sent with the series at [1]. [1] https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/ [2] https://lore.kernel.org/all/20260720175402.44338-1-ivanrwcm25@gmail.com/ [3] https://lore.kernel.org/all/20260720171740.447035-1-zfigura@codeweavers.com/ === This series improves ntsync without changing wait/wake semantics: 1/4 — Align Documentation/userspace-api/ntsync.rst with include/uapi/linux/ntsync.h (ioctl macro names and struct layout). 2/4 — Fix wake_all selftest: CREATE_EVENT returns an fd, not zero. 3/4 — Add selftests for documented EINVAL cases (zero owner, non-zero pad, cross-instance object use). 4/4 — Reject wait ioctls when owner is zero, matching the documented uAPI (3/4 depends on 4/4 for the owner tests). Patch 4/4 closes a spec gap: Documentation/userspace-api/ntsync.rst requires EINVAL when wait owner is zero, but setup_wait() only validated pad and flags. Unlock/kill mutex ioctls already reject owner == 0. Testing: - scripts/checkpatch.pl --strict --no-tree: clean (4/4 patches) - make headers && make -C tools/testing/selftests TARGETS=drivers/ntsync - Kernel 7.1.0-ntsync-test+ (CONFIG_NTSYNC=y), QEMU x86_64 initramfs: tools/testing/selftests/drivers/ntsync/ntsync — 12/12 PASS, including wake_all and wait_args_validation - On 6.17.0-35-generic with the distro ntsync.ko (without patch 4/4): wait_args_validation fails on owner==0 (wait proceeds instead of EINVAL), confirming the gap this series fixes Iván Ezequiel Rodriguez (5): selftests: ntsync: fix wake_all CREATE_EVENT fd expectation selftests: ntsync: add wait argument validation tests ntsync: reject wait ioctls with zero owner docs: ntsync: align ioctl names and struct layouts with uapi selftests: ntsync: test absolute MONOTONIC waits under time namespaces Documentation/userspace-api/ntsync.rst | 33 ++--- drivers/misc/ntsync.c | 3 + .../testing/selftests/drivers/ntsync/ntsync.c | 133 +++++++++++++++++- 3 files changed, 152 insertions(+), 17 deletions(-) base-commit: 2cedf2272f1bb42471e646868ac572cc5752bd91 -- 2.53.0

July 23, 2026

Re: [PATCH 0/4] ntsync miscellaneous patches

by Elizabeth Figura

On Monday, 20 July 2026 12:17:36 CDT Elizabeth Figura via Wine-Devel wrote: > This is a resend of a series originally submitted as [1], now sent to char-misc. > The following is the original cover letter sent with that series. > > [1] https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/ I've received new patches including an update of one of these; I will resend with those patches included. Sorry for the noise.

July 23, 2026

Re: On implementing the 'beep' escape code in conhost

by Elizabeth Figura

On Thursday, 23 July 2026 12:49:32 CDT Barath Rk via Wine-Devel wrote: > > but I don't have strong objection for playing a predefined sound instead > directly from conhost > > If that is the case, would it be better to first create a proper > implementation of Beep(that doesn't rely on forwarding to conhost. I > suppose this should be possible with whatever winmm provides right now) and > then use that here? The trouble with that is layering; it's surely wrong to call winmm or anything audio from kernelbase. It may be that it calls out to a service.

July 23, 2026

Re: On implementing the 'beep' escape code in conhost

by Jacek Caban

On 7/23/26 19:14, Elizabeth Figura via Wine-Devel wrote: > On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote: >>> then the latter shouldn't call MessageBeep(). >> yeah, Beep doesn't call MessageBeep. the beep I am attempting to >> implement will be done by a change in conhost where if '\a'(int 7) is >> encountered we call MessageBeep(MB_OK), that's about it > Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep(). FWIW, I think that calling IOCTL_CONDRV_BEEP from Beep is not exactly right. As the FIXME in Beep says, it should work when no console is attached, which means that it should not depend on conhost. If we'd get that right, we could use Beep from conhost. Jacek

July 23, 2026

Re: On implementing the 'beep' escape code in conhost

by Barath Rk

> but I don't have strong objection for playing a predefined sound instead directly from conhost If that is the case, would it be better to first create a proper implementation of Beep(that doesn't rely on forwarding to conhost. I suppose this should be possible with whatever winmm provides right now) and then use that here? This would also avoid having to implement a beep for the wayland driver. I guess that it wasn't done at the start because it isn't as straightforward to implement as it is in X11(where you just call XBell) and while looking into it, I figured that the simplest way to implement the wayland driver would be with a previous sound, so we might as well just do that in conhost. On Thu, 23 Jul, 2026, 11:08 pm Eric Pouech, <eric.pouech(a)orange.fr> wrote: > Le 23/07/2026 à 19:14, Elizabeth Figura a écrit : > > On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote: > > then the latter shouldn't call MessageBeep(). > > yeah, Beep doesn't call MessageBeep. the beep I am attempting to > implement will be done by a change in conhost where if '\a'(int 7) is > encountered we call MessageBeep(MB_OK), that's about it > > > Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep(). > > > > in fact, I did propose MessageBeep to avoid calling Beep from conhost (as > our current MessageBeep implementation doesn't fallbck to Beep) and to make > the patch simpler > > but I don't have strong objection for playing a predefined sound instead > directly from conhost > > -Eric > > >

July 23, 2026

Re: On implementing the 'beep' escape code in conhost

by Eric Pouech

Le 23/07/2026 à 19:14, Elizabeth Figura a écrit : > On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote: >>> then the latter shouldn't call MessageBeep(). >> yeah, Beep doesn't call MessageBeep. the beep I am attempting to >> implement will be done by a change in conhost where if '\a'(int 7) is >> encountered we call MessageBeep(MB_OK), that's about it > Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep(). > > in fact, I did propose MessageBeep to avoid calling Beep from conhost (as our current MessageBeep implementation doesn't fallbck to Beep) and to make the patch simpler but I don't have strong objection for playing a predefined sound instead directly from conhost -Eric

July 23, 2026

Re: On implementing the 'beep' escape code in conhost

by Barath Rk

Well, I was under the impression that Eric was referring to the part in write_console that deals with the '\a' case, which was the subject matter of the bug that I linked at the start as well. > deals with write_console that deals with the '\a' case, in this case, I don't think Beep will be called, and the IOCTRL_CONDRV_BEEP handling needn't be touched. only a call to MessageBeep needs to be made. The implementation of Beep and consequently the handling of IOCTRL_CONDRV_BEEP should be taken up as a separate issue I think. On Thu, Jul 23, 2026 at 10:44 PM Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > > On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote: > > > then the latter shouldn't call MessageBeep(). > > yeah, Beep doesn't call MessageBeep. the beep I am attempting to > > implement will be done by a change in conhost where if '\a'(int 7) is > > encountered we call MessageBeep(MB_OK), that's about it > > Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep(). > >

July 23, 2026

Re: On implementing the 'beep' escape code in conhost

by Elizabeth Figura

On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote: > > then the latter shouldn't call MessageBeep(). > yeah, Beep doesn't call MessageBeep. the beep I am attempting to > implement will be done by a change in conhost where if '\a'(int 7) is > encountered we call MessageBeep(MB_OK), that's about it Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep().

July 23, 2026