On 8/19/20 3:15 PM, Paul E. McKenney wrote: > On Wed, Aug 19, 2020 at 08:06:25AM -0400, Stephen Smalley wrote: >> On 8/19/20 4:32 AM, peter enderborg wrote: >> >>> From 8184ea3648b18718fdb460a30dfc7f848b7bc6a2 Mon Sep 17 00:00:00 2001 >>> From: Peter Enderborg <peter.enderborg@xxxxxxxx> >>> Date: Wed, 19 Aug 2020 10:20:28 +0200 >>> Subject: [RFC PATCH] selinux: Use call_rcu for policydb and booleans >>> >>> This patch adds call_rcu that moves sycronize out >>> out call path. In the callback we can no call >>> cond_resched so they have to be remvoed. >> If you look at the first version of my patch, I used call_rcu() but in a >> manner that avoided the need to remove cond_resched() or kvfree() calls from >> the freeing code by having the rcu callback just schedule_work() to free it >> later. That follows the pattern used for freeing user namespaces, for >> example. However, in re-reading the RCU documentation, my understanding is >> that one should use synchronize_rcu() followed by direct freeing whenever >> possible and this is possible from both the policy load and setting >> booleans. Neither of them are very frequent operations nor so >> performance-critical that the cost of synchronize_rcu() would be considered >> unacceptable IMHO. Thus, I don't believe we need to do this. > Indeed, synchronize_rcu() avoids things like callback flooding. > There are nevertheless cases where synchronize_rcu() can be a problem, > for example due to its relatively long latency (milliseconds at best). > But if this is an infrequent operation, that should not be an issue. > > If there nevertheless is a reason to avoid synchronize_rcu(), then > queue_rcu_work() gets you directly to a sleepable workqueue context > where cond_resched() can be used. > > Thnax, Paul >From what I have seen in usage of booleans the usage is switch-state, do-something, switch-back. So if there is anything security related you want switch time to be fast. But when I measured it was faster with synchronize_rcu than call_rcu. booleans work are smaller than a total policy load.
