On Thu, 2021-08-19 at 09:47 -0400, Mimi Zohar wrote: > On Thu, 2021-08-19 at 12:58 +0000, THOBY Simon wrote: > > Hi Liqiong, > > > > On 8/19/21 12:15 PM, liqiong wrote: > > > When "ima_match_policy" is looping while "ima_update_policy" changs > > > the variable "ima_rules", then "ima_match_policy" may can't exit loop, > > > and kernel keeps printf "rcu_sched detected stall on CPU ...". > > > > > > It occurs at boot phase, systemd-services are being checked within > > > "ima_match_policy,at the same time, the variable "ima_rules" > > > is changed by a service. > > > > First off, thanks for finding and identifying this nasty bug. > > Once the initial builtin policy rules have been replaced by a custom > policy, rules may only be appended by splicing the new rules with the > existing rules. There should never be a problem reading the rules at > that point. Does this problem occur before the builtin policy rules > have been replaced with a custom policy? Yes, the problem is limited to transitioning from the builtin policy to the custom policy. Adding a new lock around rcu code seems counter productive, especially since switching the policy rules happens once, normally during early boot before access to real root. Please consider Simon's suggestion or finding some other solution. thanks, Mimi
