linux-kernel - RE: [PATCH next 4/5] locking/osq_lock: Optimise per-cpu data accesses.

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: <f11f674ae0ab4ef0a2ae76235c6352d2@AcuMS.aculab.com>
Date: Sat, 30 Dec 2023 22:47:19 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Ingo Molnar' <mingo@...nel.org>
CC: "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	"'peterz@...radead.org'" <peterz@...radead.org>, "'longman@...hat.com'"
	<longman@...hat.com>, "'mingo@...hat.com'" <mingo@...hat.com>,
	"'will@...nel.org'" <will@...nel.org>, "'boqun.feng@...il.com'"
	<boqun.feng@...il.com>, 'Linus Torvalds' <torvalds@...ux-foundation.org>,
	"'xinhui.pan@...ux.vnet.ibm.com'" <xinhui.pan@...ux.vnet.ibm.com>,
	"'virtualization@...ts.linux-foundation.org'"
	<virtualization@...ts.linux-foundation.org>, 'Zeng Heng'
	<zengheng4@...wei.com>
Subject: RE: [PATCH next 4/5] locking/osq_lock: Optimise per-cpu data
 accesses.

From: Ingo Molnar
> Sent: 30 December 2023 20:38
> 
> * David Laight <David.Laight@...LAB.COM> wrote:
> 
> >  bool osq_lock(struct optimistic_spin_queue *lock)
> >  {
> > -	struct optimistic_spin_node *node = this_cpu_ptr(&osq_node);
> > +	struct optimistic_spin_node *node = raw_cpu_read(osq_node.self);
> >  	struct optimistic_spin_node *prev, *next;
> >  	int old;
> >
> > -	if (unlikely(node->cpu == OSQ_UNLOCKED_VAL))
> > -		node->cpu = encode_cpu(smp_processor_id());
> > +	if (unlikely(!node)) {
> > +		int cpu = encode_cpu(smp_processor_id());
> > +		node = decode_cpu(cpu);
> > +		node->self = node;
> > +		node->cpu = cpu;
> 
> This whole initialization sequence is suboptimal and needs to be
> cleaned up first: the node->cpu field is constant once initialized, so
> it should be initialized from appropriate init methods, not runtime in
> osq_lock(), right?

I thought that as well, but there would need to be a list of 'init'
functions for the per-cpu data. I didn't spot one.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)