)]}'
{
  "commit": "b8c8a338f75e052d9fa2fed851259320af412e3f",
  "tree": "01e07f1041a243d1bbac18cbfb14ced0d1734436",
  "parents": [
    "ef4650144e76ae361fe4b8c9a0afcd53074cd520"
  ],
  "author": {
    "name": "Johannes Weiner",
    "email": "hannes@cmpxchg.org",
    "time": "Fri Oct 13 15:58:05 2017 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Fri Oct 13 16:18:32 2017 -0700"
  },
  "message": "Revert \"vmalloc: back off when the current task is killed\"\n\nThis reverts commits 5d17a73a2ebe (\"vmalloc: back off when the current\ntask is killed\") and 171012f56127 (\"mm: don\u0027t warn when vmalloc() fails\ndue to a fatal signal\").\n\nCommit 5d17a73a2ebe (\"vmalloc: back off when the current task is\nkilled\") made all vmalloc allocations from a signal-killed task fail.\nWe have seen crashes in the tty driver from this, where a killed task\nexiting tries to switch back to N_TTY, fails n_tty_open because of the\nvmalloc failing, and later crashes when dereferencing tty-\u003edisc_data.\n\nArguably, relying on a vmalloc() call to succeed in order to properly\nexit a task is not the most robust way of doing things.  There will be a\nfollow-up patch to the tty code to fall back to the N_NULL ldisc.\n\nBut the justification to make that vmalloc() call fail like this isn\u0027t\nconvincing, either.  The patch mentions an OOM victim exhausting the\nmemory reserves and thus deadlocking the machine.  But the OOM killer is\nonly one, improbable source of fatal signals.  It doesn\u0027t make sense to\nfail allocations preemptively with plenty of memory in most cases.\n\nThe patch doesn\u0027t mention real-life instances where vmalloc sites would\nexhaust memory, which makes it sound more like a theoretical issue to\nbegin with.  But just in case, the OOM access to memory reserves has\nbeen restricted on the allocator side in cd04ae1e2dc8 (\"mm, oom: do not\nrely on TIF_MEMDIE for memory reserves access\"), which should take care\nof any theoretical concerns on that front.\n\nRevert this patch, and the follow-up that suppresses the allocation\nwarnings when we fail the allocations due to a signal.\n\nLink: http://lkml.kernel.org/r/20171004185906.GB2136@cmpxchg.org\nFixes:  171012f56127 (\"mm: don\u0027t warn when vmalloc() fails due to a fatal signal\")\nSigned-off-by: Johannes Weiner \u003channes@cmpxchg.org\u003e\nAcked-by: Vlastimil Babka \u003cvbabka@suse.cz\u003e\nAcked-by: Michal Hocko \u003cmhocko@suse.com\u003e\nCc: Alan Cox \u003calan@llwyncelyn.cymru\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\nCc: Dmitry Vyukov \u003cdvyukov@google.com\u003e\nCc: \u003cstable@vger.kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "8a43db6284ebcb9c40dfc3532d454c783ea61412",
      "old_mode": 33188,
      "old_path": "mm/vmalloc.c",
      "new_id": "673942094328a710b059b2b50e149ce7eb3d5f11",
      "new_mode": 33188,
      "new_path": "mm/vmalloc.c"
    }
  ]
}