Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757742Ab1F2Ueq (ORCPT ); Wed, 29 Jun 2011 16:34:46 -0400 Received: from smtp-out.google.com ([74.125.121.67]:4490 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754860Ab1F2Uem (ORCPT ); Wed, 29 Jun 2011 16:34:42 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:sender:in-reply-to:references:date: x-google-sender-auth:message-id:subject:from:to:cc:content-type:x-system-of-record; b=evkGY7XgvESYdQm81UiVUGGu6KmctMbueqgr0BfwqQZcMsuFqgp9KEC9MNLrgF+5h RyVGKZeSNK6ydDEfAgtzA== MIME-Version: 1.0 In-Reply-To: References: <1309376033-32005-1-git-send-email-dima@android.com> Date: Wed, 29 Jun 2011 13:34:38 -0700 X-Google-Sender-Auth: pm3ijgj9CUfEZ9iwuRmew9mo21E Message-ID: Subject: Re: [PATCH] plist: add mutex to the blessed lock type for plists From: Dima Zavin To: Andi Kleen Cc: linux-kernel@vger.kernel.org, Steven Rostedt , Lai Jiangshan , Thomas Gleixner Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1636 Lines: 45 On Wed, Jun 29, 2011 at 1:13 PM, Andi Kleen wrote: > Dima Zavin 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@linux.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/