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]
Date:	Wed, 7 Mar 2012 10:10:27 +0200
From:	Gilad Ben-Yossef <gilad@...yossef.com>
To:	Lai Jiangshan <eag0628@...il.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...ymtl.ca,
	josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
	rostedt@...dmis.org, Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, darren@...art.com, fweisbec@...il.com,
	patches@...aro.org
Subject: Re: [RFC PATCH 5/6] implement per-cpu&per-domain state machine call_srcu()

On Tue, Mar 6, 2012 at 4:44 PM, Lai Jiangshan <eag0628@...il.com> wrote:
> On Tue, Mar 6, 2012 at 7:52 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Tue, 2012-03-06 at 17:57 +0800, Lai Jiangshan wrote:
>>> +void srcu_barrier(struct srcu_struct *sp)
>>> +{
>>> +       struct srcu_sync sync;
>>> +       struct srcu_head *head = &sync.head;
>>> +       unsigned long chck_seq; /* snap */
>>> +
>>> +       int idle_loop = 0;
>>> +       int cpu;
>>> +       struct srcu_cpu_struct *scp;
>>> +
>>> +       spin_lock_irq(&sp->gp_lock);
>>> +       chck_seq = sp->chck_seq;
>>> +       for_each_possible_cpu(cpu) {
>>
>> ARGH!! this is really not ok.. so we spend all this time killing
>> srcu_sync_expidited and co because they prod at all cpus for no good
>> reason, and what do you do?
>
> it is srcu_barrier(), it have to wait all callbacks complete for all
> cpus since it is per-cpu
> implementation.

I would say it only needs to wait for callbacks to complete for all
CPUs that has a callback pending.

Unless I misunderstood something, that is what your code does already
- it does not wait for completion,
or schedules a work on a CPU that does not has a callback pending, right?

>
>>
>> Also, what happens if your cpu isn't actually online?
>
> The workqueue handles it, not here, if a cpu state machine has callbacks, the
> state machine is started, if it has no callback,  srcu_barrier() does
> nothing for
> this cpu

I understand the point is that offline cpus wont have callbacks, so
nothing would be
done for them, but still, is that a reason to even check? why not use
for_each_online_cpu

I think that if a cpu that was offline went online after your check
and managed to get an
SRCU callback pending it is by definition not a callback srcu_barrier
needs to wait for
since it went pending at a later time then srcu_barrier was called. Or
have I missed something?

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@...yossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ