From owner-svn-src-head@FreeBSD.ORG Tue Aug 20 22:27:07 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 0CCB07C0; Tue, 20 Aug 2013 22:27:07 +0000 (UTC) (envelope-from gibbs@FreeBSD.org) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C91042159; Tue, 20 Aug 2013 22:27:06 +0000 (UTC) Received: from [192.168.6.147] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.5) with ESMTP id r7KMR4jh007017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Aug 2013 22:27:05 GMT (envelope-from gibbs@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: svn commit: r254138 - in head: share/man/man9 sys/amd64/amd64 sys/arm/arm sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/dev/agp sys/dev/drm2/i915 sys/dev/drm2/ttm sys/dev/md sys/fs/fuse sys/fs... From: "Justin T. Gibbs" In-Reply-To: Date: Tue, 20 Aug 2013 16:26:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201308091111.r79BBCbY095386@svn.freebsd.org> <20130813142230.GE54133@acme.spoerlein.net> To: attilio@FreeBSD.org X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (aslan.scsiguy.com [70.89.174.89]); Tue, 20 Aug 2013 22:27:05 +0000 (UTC) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= 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: Tue, 20 Aug 2013 22:27:07 -0000 On Aug 13, 2013, at 8:59 AM, Attilio Rao wrote: > On Tue, Aug 13, 2013 at 4:22 PM, Ulrich Sp=F6rlein = wrote: >> On Fri, 2013-08-09 at 11:11:12 +0000, Attilio Rao wrote: >>> Author: attilio >>> Date: Fri Aug 9 11:11:11 2013 >>> New Revision: 254138 >>> URL: http://svnweb.freebsd.org/changeset/base/254138 >>>=20 >>> Log: >>> The soft and hard busy mechanism rely on the vm object lock to = work. >>> Unify the 2 concept into a real, minimal, sxlock where the shared >>> acquisition represent the soft busy and the exclusive acquisition >>> represent the hard busy. >>> The old VPO_WANTED mechanism becames the hard-path for this new = lock >>> and it becomes per-page rather than per-object. >>> The vm_object lock becames an interlock for this functionality: >>> it can be held in both read or write mode. >>> However, if the vm_object lock is held in read mode while acquiring >>> or releasing the busy state, the thread owner cannot make any >>> assumption on the busy state unless it is also busying it. >>>=20 >>> Also: >>> - Add a new flag to directly shared busy pages while vm_page_alloc >>> and vm_page_grab are being executed. This will be very helpful >>> once these functions happen under a read object lock. >>> - Move the swapping sleep into its own per-object flag >>>=20 >>> The KPI is heavilly changed this is why the version is bumped. >>> It is very likely that some VM ports users will need to change >>> their own code. >>>=20 >>> Sponsored by: EMC / Isilon storage division >>> Discussed with: alc >>> Reviewed by: jeff, kib >>> Tested by: gavin, bapt (older version) >>> Tested by: pho, scottl >>=20 >> The changes to sys/vm/vm_fault.c introduce a call to >> vm_page_sleep_if_busy() where the return code is not checked. The = other >> 5 places in the tree check the return code, please fix this here too. >> It's CID 1062398, and I would encourage folks to get an account with >> scan.coverity.com and have an eye on newly found defects. >=20 > Not true. > The same call existed also before with exactly the same semantic. > The trick there is that it is not important to check for the return > value because we are going to retry the operation anyway. > The code looks ok to me. >=20 > Attilio If this is the case, perhaps the call should be prefixed with "(void)". That would at least tell the next person reading the code that this is intentional. -- Justin=