linux-kernel - Re: NMI reentrant RCU list for -rt kernels

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:	Sat, 22 Jul 2006 19:14:22 +0100 (BST)
From:	Esben Nielsen <nielsen.esben@...glemail.com>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
cc:	"Paul E. McKenney" <pmckenne@...ibm.com>,
	Bill Huey <bhuey@...w.com>, linux-kernel@...r.kernel.org
Subject: Re: NMI reentrant RCU list for -rt kernels

On Sat, 22 Jul 2006, Mathieu Desnoyers wrote:

> Hi Paul,
>
> Following your presentation on RCU lists for -rt kernel, discussing with Bill
> Huey led me to the following idea that could solve the problem of NMI reentrancy
> of RCU read side in the -rt kernels.
>
> If we consider that the RCU list modification that makes the read side
> lock preemptible is only needed for very long code paths, we could leave the
> original RCU implementation along with the preemptible one, so that very short
> and frequent code paths could benefit of using the very cheap preempt count
> protection without having a too big impact on the scheduler latency.
>
> For instance, my LTTng tracer disables the preemption for about 95 ns, which I
> doubt would be a problem for real-time behavior. I could easily fix maximum
> a maximum list size so it can be run in a constant time.
>
> So, basically, the idea is to have two RCU API that could take names like :
> atomic_rcu_* and rcu_*
>
> Does this idea make sense ?

No,

1) Can you readily identify the very short code pathes? What about future 
code added to the kernel?
2) Having two parellel systems is a bad idea.
3) I believe RCU can be made much cheaper than the 
current implementation which look horrible.

I remember once discussing RCU on the list. I came up with the idea 
rcu_read_lock()/unlock() to be implemented as a per-task counter just as
preempt_disable()/disable(). The run-queue then has a sum of all the 
counters of tasks on that cpu (minus the counter for the current task).
I even made some sample code...
The only reason this wasn't considered working was the migration from CPU 
to CPU. I frankly can't see why this couldn't be fixed.

So the answer to you is: No. Fix the preemptible RCU instead. You have an 
idea above.

Esben


>
> Mathieu
>
>
> OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
> Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> -
> 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/
>
-
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/