From owner-freebsd-hackers@freebsd.org  Wed Jun 14 16:16:53 2017
Return-Path: <owner-freebsd-hackers@freebsd.org>
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 A852CBEE16F
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Wed, 14 Jun 2017 16:16:53 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 3D4DF6EE2B;
 Wed, 14 Jun 2017 16:16:53 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
 by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5EGGm0a000583
 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 14 Jun 2017 19:16:48 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5EGGm0a000583
Received: (from kostik@localhost)
 by tom.home (8.15.2/8.15.2/Submit) id v5EGGmgX000582;
 Wed, 14 Jun 2017 19:16:48 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
 using -f
Date: Wed, 14 Jun 2017 19:16:48 +0300
From: Konstantin Belousov <kostikbel@gmail.com>
To: Conrad Meyer <cem@freebsd.org>
Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject: Re: Re: A question about in lock usage in FreeBSD
Message-ID: <20170614161648.GQ2088@kib.kiev.ua>
References: <5940EA87.4030002@163.com>
 <CAG6CVpVd-5_7cf5O=egC7cLisag9GCc_MN==EvS8M0i-Q8cS2Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAG6CVpVd-5_7cf5O=egC7cLisag9GCc_MN==EvS8M0i-Q8cS2Q@mail.gmail.com>
User-Agent: Mutt/1.8.2 (2017-04-18)
X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no
 autolearn_force=no version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jun 2017 16:16:53 -0000

On Wed, Jun 14, 2017 at 08:45:21AM -0700, Conrad Meyer wrote:
> On Wed, Jun 14, 2017 at 12:49 AM, Jia-Ju Bai <baijiaju1990@163.com> wrote:
> > Namely, it is unsafe that the thread calls the function which may sleep when
> > the thread holds mutexes, reader/writer locks or read-mostly locks.
> > Is it right?
> 
> Correct.  sxlocks ("shared-exclusive," although I tend to think of the
> "s" as standing for "sleepable") can be held calling functions which
> may sleep.

Note that 'can' there refers only to the ability to make calls into the
locking subsystem without making it panic or triggering witness warnings.
The concrete sleepable locks itself might be unsuitable to held during
specific sleep, or cause some side effects if owned while sleeping that 
make the system unusable.

For instance, we used to own vnode and buffer locks while filesystems
copied data in/out in the VOP_READ and VOP_WRITE. It was tolerated by
locking subsystem but was the source of large series of hard to tackle
deadlocks.

In other words, the permit to own the sleepable locks while sleeping is
only about an absence of the tiranic overseer who disallows that, and
not a guarantee that the permit is handy to use.