linux-kernel - Re: [PATCH v5 5/7] revocable: Add fops replacement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251023155746.GL262900@nvidia.com>
Date: Thu, 23 Oct 2025 12:57:46 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Tzung-Bi Shih <tzungbi@...nel.org>, Benson Leung <bleung@...omium.org>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>,
	Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	chrome-platform@...ts.linux.dev, linux-kselftest@...r.kernel.org,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH v5 5/7] revocable: Add fops replacement

On Thu, Oct 23, 2025 at 05:04:57PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Oct 23, 2025 at 11:51:31AM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 23, 2025 at 10:22:01PM +0800, Tzung-Bi Shih wrote:
> > 
> > > I was misunderstanding about the "sync" we were discussing for
> > > misc_deregister_sync().  The "sync", is analogous to synchronize_srcu()
> > > of revocable_provider_revoke() in the revocable version [1], doesn't wait
> > > for closing all opened files.
> > 
> > Yes, and my remark is we don't need to obfuscate simple locks in core
> > kernel code.
> 
> {sigh}
> 
> Yes, that's not the goal here at all.

It is what is being proposed by this series.

> I've refrained from jumping in as I think we are thinking of different
> stuff here, probably talking past each other in places.
> 
> The original goal of having "revocable" is still needed, despite you
> feeling that cdev can live without it (I strongly disagree with that,
> and the v4l, gpio, i2c, and other subsystem developers have feelings
> along those lines as backed up by the many talks over the years about
> this.)

Yes, I undertand that, but this example is just not a good
justification or vehicle for it.

cdev wants a sync unregister, this is a common pattern open coded in
many subsystems. It solves problems for alot of places, including the
bug identified in this series.

Dan and Laurent have brought this up in the past, it is something that
can be fixed and Tzung-Bi's fops shimming approach is a good idea.

Of course it is not *every* problem and there may still be a role for
revokable.

This series is fixing a simple driver bug that is due to not having a
misc_unregister_sync(). So let's fix that in the natural way and find
some other, hopefully better, reason to introduce revocable.

> The use of it in the Rust code already is kind of proof of this, it
> enables driver authors to not have to worry about a ton of real-world
> issues they would have to otherwise.  Which is why I suggested copying
> that pattern into C to help us out here.

IMHO the rust code does it principally because the sync unregister
life cycle model does not fit naturally into rust.

Jason