On Wed, Aug 19, 2020 at 05:05:28PM +0200, peter enderborg wrote: > 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. > > 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. That sounds to me like a good argument for synchronize_rcu(), but I at the end of the day, I must defer to you guys given your knowledge of this code. Thanx, Paul
