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:   Thu, 8 Nov 2018 19:16:30 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc:     tglx@...utronix.de, linux-rt-users@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: srcu: use cpu_online() instead custom check

On 2018-11-08 10:05:17 [-0800], Paul E. McKenney wrote:
> Just to make sure I understand, this is the call to queue_delayed_work_on()
> from srcu_queue_delayed_work_on(), right?

correct.

> And if I am guessing correctly, you would like to get rid of the
> constraint requiring CPUHP_RCUTREE_PREP to precede CPUHP_TIMERS_PREPARE?

no, my problem is the preempt_disable() around queue_delayed_work_on().
If the CPUs goes offline _after_ queue_delayed_work_on() then the timer
gets migrated and work item should show up on another CPU. 
If the CPU is offline at queue_delayed_work_on() time then the timer
gets enqueued and won't fire until the CPU is back online and I *think*
that is the reason behind this "is CPU online" check.

> If so, the swait_event_idle_timeout_exclusive() in rcu_gp_fqs_loop()
> in kernel/rcu/tree.c also requires this ordering.  There are probably
> other pieces of code needing this.
> 
> Plus the reason for running this on a specific CPU is that the workqueue
> item is processing that CPU's per-CPU variables, including invoking that
> CPU's callbacks.  The item is srcu_invoke_callbacks().

The SRCU callback is invoking per-CPU variables? Like this_cpu_ptr()?
But if the CPU is offline then you fallback to queue_delayed_work()?

> 							Thanx, Paul

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ