Received-SPF: pass (google.com: domain of linux-kernel+bounces-39116-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Elizabeth Figura <zfigura@codeweavers.com>
To: Andy Lutomirski <luto@kernel.org>, wine-devel@winehq.org,
 Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
 =?ISO-8859-1?Q?Andr=E9?= Almeida <andrealmeid@igalia.com>,
 Wolfram Sang <wsa@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
 Alexandre Julliard <julliard@winehq.org>
Subject:
 Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.
Date: Thu, 25 Jan 2024 12:21:59 -0600
Message-ID: <3785748.kQq0lBPeGt@terabithia>
In-Reply-To: <63b3828d-8482-4435-9c98-50578bbbbe07@app.fastmail.com>
References:
 <20240124004028.16826-1-zfigura@codeweavers.com>
 <10405963.nUPlyArG6x@terabithia>
 <63b3828d-8482-4435-9c98-50578bbbbe07@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

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=E2=80=AFPM Elizabeth Figura=20
<zfigura@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.]
> >=20
> > 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.
>=20
> I can think of a few other possible benefits of going with
> per-mutex file descriptors:
>=20
> - 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 wit=
h=20
the current design.

It also doesn't really mesh well with the NT design in the first place.=20
NTSYNC_IOC_WAIT_ANY differs from poll() in two major ways: it consumes stat=
e=20
of most object types, and (as coded here) it needs the owner thread ID to b=
e=20
specifically passed for mutexes.


Anyway, as Alexandre has informed me I clearly have misunderstood our=20
requirements, so I'm going to try to put together something using files=20
instead.