Messages in this thread | | | Date | Fri, 7 Dec 2012 09:57:24 -0800 | From | Tejun Heo <> | Subject | Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context |
| |
On Fri, Dec 07, 2012 at 11:08:13PM +0530, Srivatsa S. Bhat wrote: > 4. No deadlock possibilities > > Per-cpu locking is not the way to go if we want to have relaxed rules > for lock-ordering. Because, we can end up in circular-locking dependencies > as explained in https://lkml.org/lkml/2012/12/6/290 > > So, avoid per-cpu locking schemes (per-cpu locks/per-cpu atomic counters > with spin-on-contention etc) as much as possible.
I really can't say I like this approach. percpu locking is very tricky to get right and difficult to get right and we should try our best to avoid implementing subsystem specific ones as much as possible. Also, I think the right approach would be auditing each get_online_cpus_atomic() callsites and figure out proper locking order rather than implementing a construct this unusual especially as hunting down the incorrect cases shouldn't be difficult given proper lockdep annotation.
lg_lock doesn't do local nesting and I'm not sure how big a deal that is as I don't know how many should be converted. But if nesting is an absolute necessity, it would be much better to implement generic rwlock variant (say, lg_rwlock) rather than implementing unusual cpuhotplug-specific percpu synchronization construct.
Thanks.
-- tejun
| |