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
