Date: Thu, 8 Oct 2015 21:30:59 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Alan Cox <alc@rice.edu> Cc: John Baldwin <jhb@freebsd.org>, Mark Johnston <markj@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288431 - in head/sys: kern sys vm Message-ID: <20151009043059.GK67524@funkthat.com> In-Reply-To: <F3EF914A-8296-4833-BCF8-B9D878CAB80C@rice.edu> References: <201509302306.t8UN6UwX043736@repo.freebsd.org> <1837187.vUDrWYExQX@ralph.baldwin.cx> <20151002045842.GA18421@raichu> <4276391.z2UvhhORjP@ralph.baldwin.cx> <F3EF914A-8296-4833-BCF8-B9D878CAB80C@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Cox wrote this message on Fri, Oct 02, 2015 at 18:50 -0500:
> On Oct 2, 2015, at 10:59 AM, John Baldwin <jhb@freebsd.org> wrote:
>=20
> > I think it is not unreasonble to expect that fadvise() incurs system-wi=
de
> > affects. A properly implemented WILLNEED that does read-ahead cannot w=
ork
> > without incurring system-wide effects. I had always assumed that fadvi=
se()
> > operated on a file, not a given process' view of a file (unlike, say,
> > madvise which only operates on mappings and only indirectly affects
> > file-backed data).
>=20
>=20
> Can you elaborate on what you mean by ?I had always assumed that fadvise(=
) operated on a file, ???
>=20
> Under the previous implementation, if you did an fadvise(DONTNEED) on a f=
ile, in order to cache the file?s pages, those pages first had to be unmapp=
ed from any address space. (You can find this unmapping performed by vm_pa=
ge_try_to_cache().) In other words, there was never any code that said, ?I=
s this a mapped page, and if it is, don?t cache it because we?re actually p=
erforming an fadvise().? So, to pick an extreme example, if you did an fad=
vise(?libc.so?, DONTNEED), unless some process had libc.so wired, then ever=
y single mapping to every single page of libc.so was going to be destroyed =
and the pages moved to the cache. However, because we moved the pages to t=
he cache (rather than freeing them), and libc.so is frequently accessed, a =
subsequent instruction fetch would have faulted and been able to reactivate=
the cached page, avoiding an I/O operation. In other words, that we were =
caching the pages targeted by fadvise() rather than simply freeing them mat=
tered in cases where the pages were in use/accessed by multiple processes.
This would be a very nasty DoS if someone just ran fadvise('libc.so',
DONTNEED) in loop, and forced any future accesses of libc.so to pull
=66rom disk, over and over and over again...
--=20
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151009043059.GK67524>