On Wed, Aug 5, 2009 at 9:42 AM, Louis Rilling<Louis.Rilling@xxxxxxxxxxx> wrote: > On 05/08/09 9:11 -0700, Paul Menage wrote: >> On Wed, Aug 5, 2009 at 3:20 AM, Louis Rilling<Louis.Rilling@xxxxxxxxxxx> wrote: >> > >> > The downside of this is teaching lockdep about this recursive locking. Not that >> > simple actually... >> >> Don't we just give each thread's lock its own lock class? That's what >> we did for the cgroup hierarchy_mutex. > > Given that lock classes must be static and that lockdep only supports a limited > lock depth, this is an issue for processes having many threads. > >> >> > so that such cases are currently handled using a higher-level >> > lock that prevents races in locking the whole chain (there was one such example >> > for locking all vmas with KVM). IIUC, the intent here is to avoid such >> > higher-level lock. >> >> cgroup_mutex already fulfills the role of the higher-level lock. > > If so (that is, here cgroup_mutex is taken before write-locking all threads' > rw_sem), then enhancing rwsem's interface in a similar way to the > spin_lock_nest_lock() interface could do it. There will still be an issue with > many threads and lockdep limited lock depth though. If we make the locks per-thread, then we can use plain mutexes instead of rwsems since the only reader will ever be the owning thread itself, and we can use mutex_lock_nested. > > Added Peter in CC. > > Louis > > -- > Dr Louis Rilling Kerlabs > Skype: louis.rilling Batiment Germanium > Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes > http://www.kerlabs.com/ 35700 Rennes > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkp5tmoACgkQVKcRuvQ9Q1TwdACeMwdKtGc3rU3PGXPgYvdj9Vxe > xYIAmQFMW6Ri9JGuc7+A0WmGzXkzQ81A > =Wj3u > -----END PGP SIGNATURE----- > > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
