From owner-svn-src-head@FreeBSD.ORG Thu Sep 12 15:59:59 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A3074AD; Thu, 12 Sep 2013 15:59:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF3FC2CAA; Thu, 12 Sep 2013 15:59:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 08708B958; Thu, 12 Sep 2013 11:59:58 -0400 (EDT) From: John Baldwin To: Davide Italiano Subject: Re: svn commit: r254703 - in head: share/man/man9 sys/sys Date: Thu, 12 Sep 2013 10:08:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201308231412.r7NECdG7081565@svn.freebsd.org> <201308261502.13277.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201309121008.01115.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Sep 2013 11:59:58 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:59:59 -0000 On Wednesday, September 11, 2013 2:10:11 pm Davide Italiano wrote: > [snip] > > > Well, I've thought about changing lc_lock/unlock to return a uintptr_t or > > void * instead of an int and then I could make rm_sleep work fine. However, > > that still doesn't solve the callout case. The callout case can't be fixed > > easily without explicitly allocating storage in the softclock thread itself. > > > > Also, I don't think you want a pointer in a lock_object. Imagine if two > > threads both locked and then slept on the same rm lock in succession while > > waiting for a wakeup. You would have two trackers to keep track of, but only > > one pointer in the lock_object. > > > > I'm not sure you need to revert your commit. It should pretty much panic > > instantly if someone tries to use it with a read lock instead of a write > > lock, even without INVARIANTS. > > > > -- > > John Baldwin > > Hi John, > I've finally gotten around to dedicate some time to this. > The following patch : > http://people.freebsd.org/~davide/review/callout_sharedrm.diff is a > proposed fix the problem for the callout_rm shared case, based on your > suggestions. > I've overloaded the lc_lock/lc_unlock functions so that they take an > additional void *arg argument which in the callout rm shared case is a > pointer to priotracker structure (I used a void * so that it could be > used for some other purposes in the future, if any). > I've also added a MPASS in the lc_lock()/lc_unlock() functions for all > the primitives but rmlock so that is ensured that arg passed is NULL. > I'm not completely sure this is required but I put that there as > safety belt. > The KPI is highly disturbed by this change, but unfortunately I wasn't > able to find out a way to workaround the problem without this > breakage. While we're breaking things, I guess we can fix the > rm_sleep() case as well instead of causing a double breakage. > My only doubt is what exactly we should return from lc_unlock/lc_lock, > as long as in the, e.g. rwlock case we need to return a boolean that > contains lock state (shared/exclusive) whilst in the rmlock case we > need to return both the lock state and a pointer to struct > rm_priotracker. My best guess is that of introducing a 'struct > lockstate' (sorry for the poor name choice, just to give you the idea) > which contains these two informations, but probably we can > alternatively use a single pointer and store the information about > lock state in the low order bits. > What's your opinion about? Hmm, I think I had envisioned something a bit simpler. Namely, I would change lc_lock/lc_unlock to return a uintptr_t instead of an int, and I would then change lc_unlock for an rm lock to return a pointer to the current thread's tracker as the 'how' and 0 for a write lock. Note that you have to use the existing tracker to make this work correctly for the sleep case where you unlock/lock. For the callout case I figured you would just hack it explicitly like this: if (flags & CALLOUT_SHAREDRM) rm_rlock(...) else lock->lc_lock(); However, if you make my suggested change to make the 'how' a uintptr_t that passes the tracker you can actually do this in the callout case: struct rm_priotracker tracker; uintptr_t how; how = 0; if (flags & CALLOUT_SHAREDLOCK) how = 1; else if (flags & CALLOUT_SHAREDRM) how = (uintptr_t)&tracker; ... class->lc_lock(lock, how); Now, it would be even nicer to make prevent footshooting perhaps by checking the lock class directly: how = 0; if (flags & CALLOUT_SHAREDLOCK) { if (class == &lock_class_rm || class == &lock_class_rm_sleepable) how = (uintptr_t)&tracker; else how = 1; } -- John Baldwin