From owner-svn-src-all@FreeBSD.ORG Wed Nov 13 07:28:30 2013 Return-Path: Delivered-To: svn-src-all@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 ESMTPS id 9C0BE5B1; Wed, 13 Nov 2013 07:28:30 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F9DF2A02; Wed, 13 Nov 2013 07:28:29 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAD7SOEb020407; Wed, 13 Nov 2013 09:28:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAD7SOEb020407 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAD7SNC3020406; Wed, 13 Nov 2013 09:28:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Nov 2013 09:28:23 +0200 From: Konstantin Belousov To: John-Mark Gurney Subject: Re: svn commit: r258039 - in head/sys: kern vm Message-ID: <20131113072823.GB59496@kib.kiev.ua> References: <201311120847.rAC8lwi8053235@svn.freebsd.org> <20131112215200.Y1480@besplex.bde.org> <20131113002906.GZ2279@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dbNh/oC2ly3B0NQi" Content-Disposition: inline In-Reply-To: <20131113002906.GZ2279@funkthat.com> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 07:28:30 -0000 --dbNh/oC2ly3B0NQi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 12, 2013 at 04:29:06PM -0800, John-Mark Gurney wrote: > Bruce Evans wrote this message on Tue, Nov 12, 2013 at 22:13 +1100: > > On Tue, 12 Nov 2013, Konstantin Belousov wrote: > >=20 > > >Log: > > > Avoid overflow for the page counts. > > > > > > Reported and tested by: pho > > > Sponsored by: The FreeBSD Foundation > > > MFC after: 1 week > >=20 > > >Modified: head/sys/kern/vfs_vnops.c > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > >--- head/sys/kern/vfs_vnops.c Tue Nov 12 08:32:10 2013 (r258038) > > >+++ head/sys/kern/vfs_vnops.c Tue Nov 12 08:47:58 2013 (r258039) > > >@@ -933,8 +933,9 @@ vn_io_fault(struct file *fp, struct uio > > > void *rl_cookie; > > > struct mount *mp; > > > vm_page_t *prev_td_ma; > > >- int cnt, error, save, saveheld, prev_td_ma_cnt; > > >+ int error, save, saveheld, prev_td_ma_cnt; > > > vm_offset_t addr, end; > > >+ vm_size_t cnt; > >=20 > > int was correct for a count. You can't possibly have the 8TB > > of physical memory needed to overflow a 32-bit int page count. > ^ today > > It is reasonably to assume 32-bit ints. >=20 > Except that the modern AMD64 arch now allows 52 bits of address for > phyiscal memory, which does mean in a few years, we will be eclipsing > 8TB in a single machine... >=20 > Isn't someone running FreeBSD on a 1TB machine? I'm pretty possitive > I remeber someone running 512GB, so only 3/4 doublings away from hitting > the limit... The variable in question has no relation to the physical memory size. I already noted to Bruce, in the private reply, that the variable must hold the count of the page frames covering the i/o request. As such, it must be sized to be able to hold the page count for the whole address space. The variable is clamped later, but this is an implementation detail. --dbNh/oC2ly3B0NQi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSgyoWAAoJEJDCuSvBvK1BuQEP/RL5CcbyhL0gTSqBM/aHH+CH WnqKPogIHAGum//8kbqvF5zdFUaSCnjKqCoGoIN/15jV0Y3XhbTc+06tlQJg4i83 H9srd+wO+isSxA3682oiebSkkzEYoW1tM0037QyQ/+8MKdGUR8u0K3aUcO30Ih1M qdJXoTmmLm2IJCReSHYp311Yv9LXmkr3xCScOYisbnR3aL/dI+zvQAH5efvmNIks yWTLkCpf/KxF6gpv/becBE3xVgh+K22yMl5e7rI/52tdFylOjeumcVhSL61zLDNW nDSGslIJP39r3zeyRW0V3kpNa8ejOM4poyNeoPPpA6VD3ZQ9nrN7N+QZ3SYmfuJv AR7IX2QXoJ9Tn/K4FYQa+j1OQf2tGkTkc1z0qqvx41gEiTZWNVn2C2Nv2GyAb0f+ hKJG92+M1n/bhZr/W5hJQF1h5LpSxzyPMLGr0qfcls48FcacC0Ymz653FIxbSk55 f5qiCQAmSiMzOtVyhj/n1msEDaF/ZCei3n2eSHLp6rgG93optL+OLdPkGrKcev0k yCw0tPPDbNHJOeFGORCc6XeSiL+gCx6S/rNZk+1eSeNkt2zCFhpIqkuZUpOxyDsG ozMDWx21EyUkzFwIhuNiXLRHAj6O/nG6uJpawJyHeuxUzrUchX4/Dxo4qgGfC1Hv DoKdiT5qV/Bn1c5RSPFR =TS3x -----END PGP SIGNATURE----- --dbNh/oC2ly3B0NQi--