linux-kernel - Re: [PATCH] plist: add mutex to the blessed lock type for plists

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPz4a6CbzEm3QJZ-5wsaiSH1H9g7tgo7E7-HyRB8Fv5=NfGDRQ@mail.gmail.com>
Date:	Wed, 29 Jun 2011 13:34:38 -0700
From:	Dima Zavin <dima@...roid.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] plist: add mutex to the blessed lock type for plists

On Wed, Jun 29, 2011 at 1:13 PM, Andi Kleen <andi@...stfloor.org> wrote:
> Dima Zavin <dima@...roid.com> writes:
>
>> Currently, plist debugging "enforces" that the plist is locked
>> with either a raw_spinlock or a spinlock. The plist data structure
>> is useful in other places, where spinlocks are unnecessary.
>>
>> Extend the plist initializers and debug checks to allow the plist
>> to be protected by a mutex
>
> Seems really ugly and clearly not a godo path.
>
> It's a bit like adding a 11th argument to a function which already has
> 10.
>
> Perhaps better move out the locking completely to wrappers and remove
> the knowledge from the core plist code.

Yeah, it is pretty ugly. Are you proposing adding new plist types like
plist_mutex and plist_spinlock and have the initializers create the
wrapper plist types? And then you would have X types, and X different
functions for add and del? Unless I'm misunderstanding where you
propose putting the wrappers. And then we'll have to audit all the
users to know which flavors are currently being used where (raw vs
spin).

The whole enforcement of locking inside this code is awkward anyway.
We don't enforce locking on rb_trees, or on list_head, etc. Why
plists? The funny part is that the test code in plist.c itself has a
hack to skip the lock check.

--Dima

>
> -Andi
>
>
> --
> ak@...ux.intel.com -- Speaking for myself only
>
--
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/