From owner-svn-src-head@FreeBSD.ORG Wed Sep 11 18:10:12 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4B7EA4B; Wed, 11 Sep 2013 18:10:12 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DAAF2D3B; Wed, 11 Sep 2013 18:10:12 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id db12so5950900veb.8 for ; Wed, 11 Sep 2013 11:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FQrjyRPXcRdLPSHpNPUqVlnIPgsIUGLn9VW08ZGYy1Q=; b=owDvInnaqSqyp1aYjV+n6HkcI54f1yEiqo0lOEWjvnu/d6EX7qlPexn1JA26wr3wPH L0/vTlP5tOCBqaclZU2f84rROiBTKYUudGnVIFdONQznNlQ+W7NEgQ3fQm4rceVkjvUF lydpQnM8AsLa1Vok1SpHiLF0k46U7EqvhRo2NSCbYHeQVCwk6DncDz2B2WS/AfOxHZwM grc1bWYnDr5nrUlF138oNLy5nuw6xnQy4Mlk3EfSCYrH4VJ1Eu9piAOVIctX5fZiw7rf /rrtrwgnXkfSAnpOsynkZ2LUpSmxHG6WSVfwOC7K1hiBLfe0m0wP2yhngTHW5ulrXkud 8Bgg== MIME-Version: 1.0 X-Received: by 10.58.67.9 with SMTP id j9mr2475618vet.22.1378923011342; Wed, 11 Sep 2013 11:10:11 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.65.132 with HTTP; Wed, 11 Sep 2013 11:10:11 -0700 (PDT) In-Reply-To: <201308261502.13277.jhb@freebsd.org> References: <201308231412.r7NECdG7081565@svn.freebsd.org> <201308231258.50969.jhb@freebsd.org> <201308261502.13277.jhb@freebsd.org> Date: Wed, 11 Sep 2013 20:10:11 +0200 X-Google-Sender-Auth: JNiOBf3A-GQOaxfc__wK4L9G0s8 Message-ID: Subject: Re: svn commit: r254703 - in head: share/man/man9 sys/sys From: Davide Italiano To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 11 Sep 2013 18:10:12 -0000 [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? Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare