From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751710AbbCNXJG (ORCPT ); Sat, 14 Mar 2015 19:09:06 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:37765 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750887AbbCNXJD (ORCPT ); Sat, 14 Mar 2015 19:09:03 -0400 Message-ID: <5504BF8B.1090207@gmail.com> Date: Sun, 15 Mar 2015 01:08:59 +0200 From: Matthias Bonne User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130306 Thunderbird/17.0.3 MIME-Version: 1.0 To: Valdis.Kletnieks@vt.edu CC: Yann Droneaud , kernelnewbies@kernelnewbies.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar Subject: Re: Question on mutex code References: <54F64E10.7050801@gmail.com> <1425992639.3991.11.camel@opteya.com> <65060.1425999557@turing-police.cc.vt.edu> In-Reply-To: <65060.1425999557@turing-police.cc.vt.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/10/15 16:59, Valdis.Kletnieks@vt.edu wrote: > On Tue, 10 Mar 2015 14:03:59 +0100, Yann Droneaud said: > >>> Consider the following sequence of events: >>> >>> 0. Suppose a mutex is locked by task A and has no waiters. >>> >>> 1. Task B calls mutex_trylock(). >>> >>> 2. mutex_trylock() calls the architecture-specific >>> __mutex_fastpath_trylock(), with __mutex_trylock_slowpath() as >>> fail_fn. >>> >>> 3. According to the description of __mutex_fastpath_trylock() (for >>> example in include/asm-generic/mutex-dec.h), "if the architecture >>> has no effective trylock variant, it should call the fail_fn >>> spinlock-based trylock variant unconditionally". So >>> __mutex_fastpath_trylock() may now call __mutex_trylock_slowpath(). >>> >>> 4. Task A releases the mutex. >>> >>> 5. Task B, in __mutex_trylock_slowpath, executes: >>> >>> /* No need to trylock if the mutex is locked. */ >>> if (mutex_is_locked(lock)) >>> return 0; >>> >>> Since the mutex is no longer locked, the function continues. >>> >>> 6. Task C, which runs on a different cpu than task B, locks the mutex >>> again. >>> >>> 7. Task B, in __mutex_trylock_slowpath(), continues: >>> >>> spin_lock_mutex(&lock->wait_lock, flags); > > B will spin here until C releases the lock. > > When that spin exits, C no longer holds the lock. Re-do the analysis > from this point. > Thank you for the review. I don't think B waits for C here - C holds the mutex (lock), not the internal spinlock (lock->wait_lock). I might be wrong though.