Date: Wed, 13 Nov 2013 09:28:23 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r258039 - in head/sys: kern vm Message-ID: <20131113072823.GB59496@kib.kiev.ua> In-Reply-To: <20131113002906.GZ2279@funkthat.com> References: <201311120847.rAC8lwi8053235@svn.freebsd.org> <20131112215200.Y1480@besplex.bde.org> <20131113002906.GZ2279@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131113072823.GB59496>