Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.

From: "Arnd Bergmann" <arnd@arndb.de>
To: "Elizabeth Figura" <zfigura@codeweavers.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	wine-devel@winehq.org
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	"André 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 17:47:49 +0100	[thread overview]
Message-ID: <63b3828d-8482-4435-9c98-50578bbbbe07@app.fastmail.com> (raw)
In-Reply-To: <10405963.nUPlyArG6x@terabithia>

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@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, ...)

- replacing your logic around xarray with something a bit
  simpler. As far as I can tell, your code is all correct here,
  but it would be easier to understand if it looked more like
  other code I'm familiar with.

> The main question is, is NOFILE a realistic concern, and what other problems 
> might there be, in terms of making these heavier objects? Besides memory usage 
> I can't think of any, but of course I don't have much knowledge of this area.

I would think that RLIMIT_NOFILE is a sensible way of
managing this, at least this way it's possible to prevent
exhausting memory with too many mutexes, but still raising
the limit if you need more than whatever default one might
come up with.

     Arnd