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

[Dima Zavin]

On Wed, Jun 29, 2011 at 1:13 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> Dima Zavin <dima@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx -- Speaking for myself only
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/