Alan Cox wrote this message on Fri, Oct 02, 2015 at 18:50 -0500:
> On Oct 2, 2015, at 10:59 AM, John Baldwin <j...@freebsd.org> wrote:
>
> > I think it is not unreasonble to expect that fadvise() incurs system-wide
> > affects. A properly implemented WILLNEED that does read-ahead cannot work
> > without incurring system-wide effects. I had always assumed that fadvise()
> > 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).
>
>
> Can you elaborate on what you mean by ?I had always assumed that fadvise()
> operated on a file, ???
>
> Under the previous implementation, if you did an fadvise(DONTNEED) on a file,
> in order to cache the file?s pages, those pages first had to be unmapped from
> any address space. (You can find this unmapping performed by
> vm_page_try_to_cache().) In other words, there was never any code that said,
> ?Is this a mapped page, and if it is, don?t cache it because we?re actually
> performing an fadvise().? So, to pick an extreme example, if you did an
> fadvise(?libc.so?, DONTNEED), unless some process had libc.so wired, then
> every 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 the 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 mattered in cases where th
e 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
from disk, over and over and over again...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
