From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752896AbcFQOZI (ORCPT ); Fri, 17 Jun 2016 10:25:08 -0400 Received: from linuxhacker.ru ([217.76.32.60]:44212 "EHLO fiona.linuxhacker.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751095AbcFQOZH convert rfc822-to-8bit (ORCPT ); Fri, 17 Jun 2016 10:25:07 -0400 Subject: Re: initialize a mutex into locked state? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Oleg Drokin In-Reply-To: <20160617141912.GS30154@twins.programming.kicks-ass.net> Date: Fri, 17 Jun 2016 10:24:32 -0400 Cc: Mailing List , mingo@redhat.com, arjan@linux.intel.com, "J . Bruce Fields" , Jeff Layton Content-Transfer-Encoding: 8BIT Message-Id: References: <55315ADD-4AE1-4EA4-8291-1B07F659BD99@linuxhacker.ru> <20160617082559.GD30935@twins.programming.kicks-ass.net> <38111D58-C42F-4ED3-BC31-04884795BE38@linuxhacker.ru> <20160617141912.GS30154@twins.programming.kicks-ass.net> To: Peter Zijlstra X-Mailer: Apple Mail (2.1283) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Jun 17, 2016, at 10:19 AM, Peter Zijlstra wrote: > On Fri, Jun 17, 2016 at 10:14:10AM -0400, Oleg Drokin wrote: >> >> On Jun 17, 2016, at 4:25 AM, Peter Zijlstra wrote: >> >>> On Wed, Jun 15, 2016 at 02:23:35PM -0400, Oleg Drokin wrote: >>>> Hello! >>>> >>>> To my surprise I found out that it's not possible to initialise a mutex into >>>> a locked state. >>>> I discussed it with Arjan and apparently there's no fundamental reason >>>> not to allow this. >>> >>> There is. A mutex _must_ have an owner. If you can initialize it in >>> locked state, you could do so statically, ie. outside of the context of >>> a task. >> >> What's wrong with disallowing only static initializers, but allowing dynamic ones? >> Then there is a clear owner. > > At which point, what wrong with the simple: > > mutex_init(&m); > mutex_lock(&m); > > Sequence? Its obvious, has clear semantics and doesn't extend the API. The problem is: spin_lock(somelock); structure = some_internal_list_lookup(list); if (structure) goto out; init_new_structure(new_structure); mutex_init(&new_structure->s_mutex); mutex_lock(&new_structure->s_mutex); // XXX CANNOT DO THIS UNDER SPINLOCK! list_add(list, new_structure->s_list); structure = new_structure; out: spin_unlock(somelock); return structure;