)]}'
{
  "commit": "30bac164aca750892b93eef350439a0562a68647",
  "tree": "044818c698f84733295380e5a39493c51d1ed9c8",
  "parents": [
    "db781446312314fb11a860ece9a757db2c2d69f1"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Jan 24 09:04:37 2019 +1300"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Jan 24 09:04:37 2019 +1300"
  },
  "message": "Revert \"Change mincore() to count \"mapped\" pages rather than \"cached\" pages\"\n\nThis reverts commit 574823bfab82d9d8fa47f422778043fbb4b4f50e.\n\nIt turns out that my hope that we could just remove the code that\nexposes the cache residency status from mincore() was too optimistic.\n\nThere are various random users that want it, and one example would be\nthe Netflix database cluster maintenance. To quote Josh Snyder:\n\n \"For Netflix, losing accurate information from the mincore syscall\n  would lengthen database cluster maintenance operations from days to\n  months. We rely on cross-process mincore to migrate the contents of a\n  page cache from machine to machine, and across reboots.\n\n  To do this, I wrote and maintain happycache [1], a page cache\n  dumper/loader tool. It is quite similar in architecture to pgfincore,\n  except that it is agnostic to workload. The gist of happycache\u0027s\n  operation is \"produce a dump of residence status for each page, do\n  some operation, then reload exactly the same pages which were present\n  before.\" happycache is entirely dependent on accurate reporting of the\n  in-core status of file-backed pages, as accessed by another process.\n\n  We primarily use happycache with Cassandra, which (like Postgres +\n  pgfincore) relies heavily on OS page cache to reduce disk accesses.\n  Because our workloads never experience a cold page cache, we are able\n  to provision hardware for a peak utilization level that is far lower\n  than the hypothetical \"every query is a cache miss\" peak.\n\n  A database warmed by happycache can be ready for service in seconds\n  (bounded only by the performance of the drives and the I/O subsystem),\n  with no period of in-service degradation. By contrast, putting a\n  database in service without a page cache entails a potentially\n  unbounded period of degradation (at Netflix, the time to populate a\n  single node\u0027s cache via natural cache misses varies by workload from\n  hours to weeks). If a single node upgrade were to take weeks, then\n  upgrading an entire cluster would take months. Since we want to apply\n  security upgrades (and other things) on a somewhat tighter schedule,\n  we would have to develop more complex solutions to provide the same\n  functionality already provided by mincore.\n\n  At the bottom line, happycache is designed to benignly exploit the\n  same information leak documented in the paper [2]. I think it makes\n  perfect sense to remove cross-process mincore functionality from\n  unprivileged users, but not to remove it entirely\"\n\nWe do have an alternate approach that limits the cache residency\nreporting only to processes that have write permissions to the file, so\nwe can fix the original information leak issue that way.  It involves\n_adding_ code rather than removing it, which is sad, but hey, at least\nwe haven\u0027t found any users that would find the restrictions\nunacceptable.\n\nSo revert the optimistic first approach to make room for that alternate\nfix instead.\n\nReported-by: Josh Snyder \u003cjoshs@netflix.com\u003e\nCc: Jiri Kosina \u003cjikos@kernel.org\u003e\nCc: Dominique Martinet \u003casmadeus@codewreck.org\u003e\nCc: Andy Lutomirski \u003cluto@amacapital.net\u003e\nCc: Dave Chinner \u003cdavid@fromorbit.com\u003e\nCc: Kevin Easton \u003ckevin@guarana.org\u003e\nCc: Matthew Wilcox \u003cwilly@infradead.org\u003e\nCc: Cyril Hrubis \u003cchrubis@suse.cz\u003e\nCc: Vlastimil Babka \u003cvbabka@suse.cz\u003e\nCc: Tejun Heo \u003ctj@kernel.org\u003e\nCc: Kirill A. Shutemov \u003ckirill@shutemov.name\u003e\nCc: Daniel Gruss \u003cdaniel@gruss.cc\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f0f91461a9f45c350fd8fccc0ccaf6c9578e4b3a",
      "old_mode": 33188,
      "old_path": "mm/mincore.c",
      "new_id": "218099b5ed31d1e971d8d64b0951a31b8e310c01",
      "new_mode": 33188,
      "new_path": "mm/mincore.c"
    }
  ]
}