linux-kernel - Re: [PATCH 6/6] Makes procs file writable to move all threads by tgid at once

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 Aug 2009 17:01:42 -0700
From:	Benjamin Blum <bblum@...gle.com>
To:	Paul Menage <menage@...gle.com>, Benjamin Blum <bblum@...gle.com>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 6/6] Makes procs file writable to move all threads by tgid 
	at once

On Wed, Aug 5, 2009 at 9:42 AM, Louis Rilling<Louis.Rilling@...labs.com> wrote:
> On 05/08/09  9:11 -0700, Paul Menage wrote:
>> On Wed, Aug 5, 2009 at 3:20 AM, Louis Rilling<Louis.Rilling@...labs.com> 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-----
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/