linux-kernel - Re: [PATCH 1/2] list: introduce a new cutting helper

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZmsS9DZWl8TccvKz@kbusch-mbp.dhcp.thefacebook.com>
Date: Thu, 13 Jun 2024 09:40:36 -0600
From: Keith Busch <kbusch@...nel.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Nilay Shroff <nilay@...ux.ibm.com>, l@...sch-mbp.dhcp.thefacebook.com,
	Keith Busch <kbusch@...a.com>, linux-nvme@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	hch@....de, sagi@...mberg.me, davidgow@...gle.com,
	akpm@...ux-foundation.org, venkat88@...ux.vnet.ibm.com
Subject: Re: [PATCH 1/2] list: introduce a new cutting helper

On Thu, Jun 13, 2024 at 08:15:06AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 13, 2024 at 08:47:26AM -0600, Keith Busch wrote:
> > > 
> > > Just make a helper function like this:
> > > 
> > > 	static void my_synchronize_srcu(void)
> > > 	{
> > > 		synchronize_srcu(&my_srcu_struct);
> > > 	}
> > > 
> > > Or am I missing something subtle here?
> > 
> > That would work if we had a global srcu, but the intended usage
> > dynamically allocates one per device the driver is attached to, so a
> > void callback doesn't know which one to sync.
> 
> Ah, good point!  I suppose that a further suggestion to just JIT the
> needed function would not be well-received?  ;-)
> 
> I cannot resist suggesting placing a pointer to the srcu_struct in
> the task structure.  /me runs...
> 
> Perhaps somewhat more constructively, my usual question:  Is it really
> necessary to have per-driver SRCU here?  What would break if there was
> a global srcu_struct that applied to all drivers?

There's not a strict need for srcu_struct to be per device that I know
of. It was just done this way to keep usage localized to the parts that
need to be protected. The fear being that one device's long running
reader could prevent another device from quickly tearing down.