On 2020-04-16 23:05:15 [-0400], Joel Fernandes wrote: > On Thu, Apr 16, 2020 at 11:34:44PM +0200, Sebastian Andrzej Siewior wrote: > > On 2020-04-16 14:00:57 [-0700], Paul E. McKenney wrote: > > > > > > We might need different calling-context restrictions for the two variants > > > of kfree_rcu(). And we might need to come up with some sort of lockdep > > > check for "safe to use normal spinlock in -rt". > > > > Oh. We do have this already, it is called CONFIG_PROVE_RAW_LOCK_NESTING. > > This one will scream if you do > > raw_spin_lock(); > > spin_lock(); > > > > Sadly, as of today, there is code triggering this which needs to be > > addressed first (but it is one list of things to do). > > > > Given the thread so far, is it okay if I repost the series with > > migrate_disable() instead of accepting a possible migration before > > grabbing the lock? I would prefer to avoid the extra RT case (avoiding > > memory allocations in a possible atomic context) until we get there. > > I prefer something like the following to make it possible to invoke > kfree_rcu() from atomic context considering call_rcu() is already callable > from such contexts. Thoughts? So it looks like it would work. However, could we please delay this until we have an actual case on RT? I just added WARN_ON(!preemptible()); to kfree_call_rcu() on v5.6.4-rt4 and nothing triggered. This is the list of users I had (just to figure out if this is used at all): - addrconf_ifdown - cgroup_free - cgroup_migrate_finish - css_task_iter_end - disk_expand_part_tbl - drop_sysctl_table - __hw_addr_flush - inetdev_event - ip6addrlbl_net_exit - ip6addrlbl_net_exit - ops_exit_list.isra.0 - rtnl_register_internal - simple_set_acl - swevent_hlist_put_cpu - timerfd_release - vfs_rename - __xfs_set_acl Sebastian
