linux-kernel - Re: Using markers w/ preemptible RCU in early code

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>] [day] [month] [year] [list]

Message-ID: <20080511035644.3613a9a2@linux360.ro>
Date:	Sun, 11 May 2008 03:56:44 +0300
From:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Paul McKenney <Paul.McKenney@...ibm.com>
Cc:	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: Using markers w/ preemptible RCU in early code

On Sat, 10 May 2008 17:30:23 -0700
Paul McKenney <Paul.McKenney@...ibm.com> wrote:

> There might be an easy and harmless fix for early-boot use of 
> synchronize_sched() -- I will look into this.
> 
> As noted above, call_rcu() is not a problem.
> 
> The rcu_barrier*() primitives must never be invoked at early boot
> time. These primitives absolutely must block until all of the
> corresponding flavor of callback has been invoked (and completed),
> but it is not possible to block during early boot.  Perhaps they
> should do a WARN_ON() or BUG_ON() in this case?
> 
> But why are you calling rcu_barrier() during early boot in the first 
> place?

Hi,

Mathieu's code does not call rcu_barrier() explicitely during early
boot. It just happens that I need to use his code (i.e. markers) at that
moment.

My understanding is that we could skip any synchronization primitives
during early code, since there is no SMP and no preemption (and no IRQs
popping around, maybe?). RCU stuff still needs to get registered for
later on, though.

I guess we should write a marker_probe_register() variant for early
code, with no rcu_barrier() and no synchronize_sched() around.

Mathieu, does this sound okay?

(Paul, I removed your alias from the Cc list, so you don't get duplicates.)


Thanks for your input,
		Eduard
--
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/