From owner-freebsd-hackers@freebsd.org Thu Apr 13 09:28:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B93ED3BAA3 for ; Thu, 13 Apr 2017 09:28:17 +0000 (UTC) (envelope-from ablacktshirt@gmail.com) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFB02C5F for ; Thu, 13 Apr 2017 09:28:16 +0000 (UTC) (envelope-from ablacktshirt@gmail.com) Received: by mail-pg0-x242.google.com with SMTP id g2so10283164pge.2 for ; Thu, 13 Apr 2017 02:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=a2j1IuhOD6HMFFaoSk4s7VuV09u2nX42VOKZHelFk04=; b=QOHWhM+dLG6bmRWRId5jeVy5IGIVufHvKfJf7+5e/zLci7cd7S0XL9mS2IcOLl8sms nzHrjXoyepdwZ5QL4k4q1ia9PDd7VOc/BmBUmIxDdhOVL32jWP+nM+I4ZQWWg430VojY TWg47ObeVpqpnIw4U/t9N654BRrOXSkCNmRDBBTbxLp6MaT5O5Kqbq/o8+8r2l0VUHQ5 mtt8uMXqW+SauLqro/ctLvlfnl2WKlLiTMqs8FcrSPcVjRAwI4g1bKSjBKzKeqU7Ulx8 ohN0TgKWsENRqN6O5LSrsyTfUQO22KfOzugPa8RD9tZsZp+rjKpozFMGs9ydNrUNF1xv 00LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=a2j1IuhOD6HMFFaoSk4s7VuV09u2nX42VOKZHelFk04=; b=fgogqMPPKh+I9oSeQ2CcH8QP1yoLZIXdczIYv4+0aUPLVjDY0HaUAYjktqItqCOQJJ MkD7USaYf7NW10wPsxbhKoCSBtBe9vsIEmFslP1QVyxU1yTZDmaTt9v8UKWwnxBKpjgy g1DOeD8JHCwHav7FP0LKVcqAOUvsIInzJPQ4of87p/upB0tPEoaxo/ZHJ+QZ43U9Qw6o DktxTvTgxOdobxga3t3eUTxabt/TAkL7hqq7m6lO5b+PfQLPKBz6P4NYKGjpPxP3wxxF 2FVKc/gApvjNQpxuyFz6iN0s1sbOWBt4HW86wlVYdIpGcq/k/DHWl12f9anM+qi3SGZL mSsw== X-Gm-Message-State: AN3rC/5WRQd6ot8lARfXkM2Ek1hW8IJLQm/YlrugUk8ynChTYzoEmVdl iQbq4eR1eMJuzSUjBpw= X-Received: by 10.98.14.28 with SMTP id w28mr2343869pfi.59.1492075696305; Thu, 13 Apr 2017 02:28:16 -0700 (PDT) Received: from [192.168.2.211] ([116.56.129.146]) by smtp.gmail.com with ESMTPSA id l127sm41436091pga.7.2017.04.13.02.28.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 02:28:15 -0700 (PDT) Subject: Re: Understanding the FreeBSD locking mechanism To: Chris Torek , imp@bsdimp.com References: <201704121853.v3CIrg5d055158@elf.torek.net> Cc: ed@nuxi.nl, freebsd-hackers@freebsd.org, rysto32@gmail.com, kostikbel@gmail.com From: Yubin Ruan Message-ID: <06a30d21-acff-efb2-ff58-9aa66793e929@gmail.com> Date: Thu, 13 Apr 2017 17:28:04 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201704121853.v3CIrg5d055158@elf.torek.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:28:17 -0000 On 2017年04月13日 02:53, Chris Torek wrote: >>> If you obtain the locks in the other order -- i.e., if you grab >>> the PROC_STATLOCK first, then try to lock PROC_LOCK -- you are >>> trying to take a spin-type mutex while holding a default mutex, > >> Is this a typo? I guess you mean something like "you are trying >> to take a blocking mutex while holding spin-type mutex". > > Yes, or rather brain-o (swapping words) -- these most often happen > if I am interrupted while composing a message :-) > >> I think I get your point: if you take a spin-type mutex, you >> already disable interrupt, which in effect means that no other >> code can preempt you. Under this circumstance, if you continue to >> take a blocking mutex, you may get blocked. Since you already >> disable interrupt and nobody can interrupt/preempt you, you are blocked >> on that CPU, not being able to do anything, which is pretty much a >> "deadlock" (actually this is not a deadlock, but, it is similar) > > Right. It *may* deadlock, and it is definitely not good -- and > the INVARIANTS kernel will check and panic. I discover that in the current implementation in FreeBSD, spinlock does not disable interrupt entirely: 607 for (;;) { 608 if (m->mtx_lock == MTX_UNOWNED && _mtx_obtain_lock(m, tid)) 609 break; 610 /* Give interrupts a chance while we spin. */ 611 spinlock_exit(); 612 while (m->mtx_lock != MTX_UNOWNED) { 613 if (i++ < 10000000) { 614 cpu_spinwait(); 615 continue; 616 } 617 if (i < 60000000 || kdb_active || panicstr != NULL) 618 DELAY(1); 619 else 620 _mtx_lock_spin_failed(m); 621 cpu_spinwait(); 622 } 623 spinlock_enter(); 624 } This is `_mtx_lock_spin_cookie(...)` in kern/kern_mutex.c, which implements the core logic of spinning. However, as you can see, while spinning, it would enable interrupt "occasionally" and disable it again... What is the rationale for that? Regards, Yubin Ruan