)]}'
{
  "commit": "60fd760fb9ff7034360bab7137c917c0330628c2",
  "tree": "2498b0456b49dc0f4e7db34a9c1d3858e2b5eaf9",
  "parents": [
    "a68e61e8ff2d46327a37b69056998b47745db6fa"
  ],
  "author": {
    "name": "Andrew Morton",
    "email": "akpm@linux-foundation.org",
    "time": "Wed Feb 04 15:12:06 2009 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Feb 05 12:56:47 2009 -0800"
  },
  "message": "revert \"rlimit: permit setting RLIMIT_NOFILE to RLIM_INFINITY\"\n\nRevert commit 0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f because it causes\n(arguably poorly designed) existing userspace to spend interminable\nperiods closing billions of not-open file descriptors.\n\nWe could bring this back, with some sort of opt-in tunable in /proc, which\ndefaults to \"off\".\n\nPeter\u0027s alanysis follows:\n\n: I spent several hours trying to get to the bottom of a serious\n: performance issue that appeared on one of our servers after upgrading to\n: 2.6.28.  In the end it\u0027s what could be considered a userspace bug that\n: was triggered by a change in 2.6.28.  Since this might also affect other\n: people I figured I\u0027d at least document what I found here, and maybe we\n: can even do something about it:\n:\n:\n: So, I upgraded some of debian.org\u0027s machines to 2.6.28.1 and immediately\n: the team maintaining our ftp archive complained that one of their\n: scripts that previously ran in a few minutes still hadn\u0027t even come\n: close to being done after an hour or so.  Downgrading to 2.6.27 fixed\n: that.\n:\n: Turns out that script is forking a lot and something in it or python or\n: whereever closes all the file descriptors it doesn\u0027t want to pass on.\n: That is, it starts at zero and goes up to ulimit -n/RLIMIT_NOFILE and\n: closes them all with a few exceptions.\n:\n: Turns out that takes a long time when your limit -n is now 2^20 (1048576).\n:\n: With 2.6.27.* the ulimit -n was the standard 1024, but with 2.6.28 it is\n: now a thousand times that.\n:\n: 2.6.28 included a patch titled \"rlimit: permit setting RLIMIT_NOFILE to\n: RLIM_INFINITY\" (0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f)[1] that\n: allows, as the title implies, to set the limit for number of files to\n: infinity.\n:\n: Closer investigation showed that the broken default ulimit did not apply\n: to \"system\" processes (like stuff started from init).  In the end I\n: could establish that all processes that passed through pam_limit at one\n: point had the bad resource limit.\n:\n: Apparently the pam library in Debian etch (4.0) initializes the limits\n: to some default values when it doesn\u0027t have any settings in limit.conf\n: to override them.  Turns out that for nofiles this is RLIM_INFINITY.\n: Commenting out \"case RLIMIT_NOFILE\" in pam_limit.c:267 of our pam\n: package version 0.79-5 fixes that - tho I\u0027m not sure what side effects\n: that has.\n:\n: Debian lenny (the upcoming 5.0 version) doesn\u0027t have this issue as it\n: uses a different pam (version).\n\nReported-by: Peter Palfrader \u003cweasel@debian.org\u003e\nCc: Adam Tkac \u003cvonsch@gmail.com\u003e\nCc: Michael Kerrisk \u003cmtk.manpages@googlemail.com\u003e\nCc: \u003cstable@kernel.org\u003e\t\t[2.6.28.x]\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": "e7dc0e10a485878a08a8c80b52e6919ca6da3c13",
      "old_mode": 33188,
      "old_path": "kernel/sys.c",
      "new_id": "f145c415bc160e62b6d888cf6fa9d3198c00b4a7",
      "new_mode": 33188,
      "new_path": "kernel/sys.c"
    }
  ]
}