From owner-svn-src-head@FreeBSD.ORG Mon Aug 26 18:33:43 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 4889D452; Mon, 26 Aug 2013 18:33:43 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C493F26C8; Mon, 26 Aug 2013 18:33:42 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id m17so2371957vca.3 for ; Mon, 26 Aug 2013 11:33:41 -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=6BXVFn4OGbI8y27zWyMpCrkGHnLFaHpm/0OvOt0QC/I=; b=wRzlJJ/0S5ZOCoxeKr5fkHA5OfhqmxEjvAGa0foz+oxyDb/87tmikU7lDV80z/VCz8 m6piUc85YXcTlU6szR5iZGhZVcn6er0UlgHpm1ohCRu1LsN5MAM+ykC//6uLHrMDV8zs 1juLofHGlBEUvAJVYZ+d5b+06qRzoMDQfJOVP5qSD+QuhdBcoghNa5KtkfvVmH1wXHig ebpfl6BQ1UWoxNOoOUuuutivI5LQdV32x0SGEgFSu9D/hUeU4ANPUemLiO1XlkdCAlpA hE/nAaK3vTln5ascfA7+2BmTyTnSKUsGPOcS6+81x5Et7y2k+0j2CfQ+kyW/+vgye2Pf D85Q== MIME-Version: 1.0 X-Received: by 10.58.100.234 with SMTP id fb10mr16253383veb.5.1377542021845; Mon, 26 Aug 2013 11:33:41 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.65.132 with HTTP; Mon, 26 Aug 2013 11:33:41 -0700 (PDT) In-Reply-To: <201308231258.50969.jhb@freebsd.org> References: <201308231412.r7NECdG7081565@svn.freebsd.org> <201308231051.08997.jhb@freebsd.org> <201308231258.50969.jhb@freebsd.org> Date: Mon, 26 Aug 2013 11:33:41 -0700 X-Google-Sender-Auth: fSnKzIN-BnmgEu7VLvSQ2fxf4jM 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: Mon, 26 Aug 2013 18:33:43 -0000 On Fri, Aug 23, 2013 at 9:58 AM, John Baldwin wrote: > On Friday, August 23, 2013 11:29:45 am Davide Italiano wrote: >> On Fri, Aug 23, 2013 at 4:51 PM, John Baldwin wrote: >> > On Friday, August 23, 2013 10:12:39 am Davide Italiano wrote: >> >> Author: davide >> >> Date: Fri Aug 23 14:12:39 2013 >> >> New Revision: 254703 >> >> URL: http://svnweb.freebsd.org/changeset/base/254703 >> >> >> >> Log: >> >> Introduce callout_init_rm() so that callouts can be used in conjunction >> >> with rmlocks. This works only with non-sleepable rm because handlers run >> >> in SWI context. While here, document the new KPI in the timeout(9) >> >> manpage. >> > >> > It also only works with exclusive locks. (lc_unlock/lc_lock only handle >> > write locks for rmlocks). >> > >> > -- >> > John Baldwin >> >> Thanks for pointing out this. >> I think it would be nice to have lc_lock/lc_unlock working both for >> shared and exclusive locks but I'm not 100% sure about all the >> implications/complications. From what I see for rwlocks asserting if a >> lock is held in read-mode is really cheap (check against a flag) while >> for rmlocks the assertion relies on traversing the tracker list for >> the rmlock so I'm worried this operation could be expensive. What's >> your opinion about? > > The much bigger problem is you need an rmtracker object to pass to the > lock/unlock routines. > > You could make this work hackishly in the callout case by special casing > rm locks that use read locking and using a tracker on softclock's stack, > but it is much harder to fix this for the rm_sleep() case where the > sequence is lc_unlock/lc_lock. > > -- > John Baldwin I see. I would really like to go for a clean solution if possible, and if the timeframe for 10 doesn't allow this just revert the commit until a better solution would be available. FWIW, I pondered a bit about this and the only way I was able to think is that of augmenting 'struct lock_object' with a 'void *arg' field that in this case could be used to store a pointer to something, which in this case is a pointer to a rmtracker object, and this could allow easily to retrieve the needed information (as far as I see something similar is done to store WITNESS information). This, OTOH, could be overkill just to fix this case though. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare