diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2019-04-14 15:09:40 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2019-04-14 15:09:40 -0700 |
commit | 6b3a707736301c2128ca85ce85fb13f60b5e350a (patch) | |
tree | 2bf1892cf29121150adece8d1221ecd513a4e792 /.mailmap | |
parent | 4443f8e6ac7755cd775c70d08be8042dc2f936cb (diff) | |
parent | 15fab63e1e57be9fdb5eec1bbc5916e9825e9acb (diff) |
Merge branch 'page-refs' (page ref overflow)
Merge page ref overflow branch.
Jann Horn reported that he can overflow the page ref count with
sufficient memory (and a filesystem that is intentionally extremely
slow).
Admittedly it's not exactly easy. To have more than four billion
references to a page requires a minimum of 32GB of kernel memory just
for the pointers to the pages, much less any metadata to keep track of
those pointers. Jann needed a total of 140GB of memory and a specially
crafted filesystem that leaves all reads pending (in order to not ever
free the page references and just keep adding more).
Still, we have a fairly straightforward way to limit the two obvious
user-controllable sources of page references: direct-IO like page
references gotten through get_user_pages(), and the splice pipe page
duplication. So let's just do that.
* branch page-refs:
fs: prevent page refcount overflow in pipe_buf_get
mm: prevent get_user_pages() from overflowing page refcount
mm: add 'try_get_page()' helper function
mm: make page ref count overflow check tighter and more explicit
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions