On 18.03.2020 07:26, Jürgen Groß wrote:
On 17.03.20 15:36, Jan Beulich wrote:
On 13.03.2020 14:06, Juergen Gross wrote:
Xen's RCU implementation relies on no softirq handling taking place
while being in a RCU critical section. Add ASSERT()s in debug builds
in order to catch any violations.
For that purpose modify rcu_read_[un]lock() to use a dedicated percpu
counter additional to preempt_[en|dis]able() as this enables to test
that condition in __do_softirq() (ASSERT_NOT_IN_ATOMIC() is not
usable there due to __cpu_up() calling process_pending_softirqs()
while holding the cpu hotplug lock).
While at it switch the rcu_read_[un]lock() implementation to static
inline functions instead of macros.
Signed-off-by: Juergen Gross <jgr...@suse.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
with one remark:
@@ -91,16 +114,23 @@ typedef struct _rcu_read_lock rcu_read_lock_t;
* will be deferred until the outermost RCU read-side critical section
* completes.
*
- * It is illegal to block while in an RCU read-side critical section.
+ * It is illegal to process softirqs while in an RCU read-side critical
section.
The latest with the re-added preempt_disable(), wouldn't this better
say "... to process softirqs or block ..."?
I can add this, but OTOH blocking without processing softirqs is not
possible, as there is no other (legal) way to enter the scheduler.
Sure, but that's still implicit, but could do with saying explicitly.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
