Re: xfrm_state locking regression...
From: Timo Teräs <hidden>
Date: 2008-09-23 13:30:10
Herbert Xu wrote:
On Tue, Sep 23, 2008 at 04:01:29PM +0300, Timo Teräs wrote:quoted
So, what to do? 1. Go back to: list_del_rcu, xfrm_state_hold(all.next) on delete and xfrm_state_put(all.next) on destruct. 2. Add per-entry hlist of walkers currently referencing it. 3. Use the global walker list. 1 can keep memory allocated until userland wakes up. 2 & 3 can make the delete of that entry slow if there's many walkers suspended.I'd cross 3 off the list because 2 is just so much better :) I'd slightly lean towards 2 but now that you mention it yes even that is vulnerable to loads of dumpers sitting on the same entry. So SELINUX folks wouldn't like that :)
Umm... right. It's a tricky problem. Cannot think of perfect solution atm. But I guess 3 is in general case the best. But in worst case scenarios 1 performs better. I have no strong opinion either way. So what ever you want, I'm happy to provide a patch for.
quoted
Btw. the current stuff in net-next is broken. There's no locking for xfrm_state_walkers list handling.What about xfrm_cfg_mutex?
It's used only in xfrm_state_gc_task. xfrm_state_walk_{init,done}
touch xfrm_state_walks list without locking properly. At least in
the version I'm looking (= net-next-2.6 via git web interface).
- Timo