)]}'
{
  "commit": "4e6fd33b75602ced4c5d43e99a10a1d13f33d4f4",
  "tree": "f22573e7d57532c4393ae26bea08866decad2813",
  "parents": [
    "8c6ba51bdad0de0dc2a2e2415d4dac2d0db6c1a1"
  ],
  "author": {
    "name": "Chris Snook",
    "email": "csnook@redhat.com",
    "time": "Fri Sep 29 02:01:33 2006 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@g5.osdl.org",
    "time": "Fri Sep 29 09:18:23 2006 -0700"
  },
  "message": "[PATCH] enforce RLIMIT_NOFILE in poll()\n\nPOSIX states that poll() shall fail with EINVAL if nfds \u003e OPEN_MAX.  In\nthis context, POSIX is referring to sysconf(OPEN_MAX), which is the value\nof current-\u003esignal-\u003erlim[RLIMIT_NOFILE].rlim_cur in the linux kernel, not\nthe compile-time constant which happens to also be named OPEN_MAX.  In the\ncurrent code, an application may poll up to max_fdset file descriptors,\neven if this exceeds RLIMIT_NOFILE.  The current code also breaks\napplications which poll more than max_fdset descriptors, which worked circa\n2.4.18 when the check was against NR_OPEN, which is 1024*1024.  This patch\nenforces the limit precisely as POSIX defines, even if RLIMIT_NOFILE has\nbeen changed at run time with ulimit -n.\n\nTo elaborate on the rationale for this, there are three cases:\n\n1) RLIMIT_NOFILE is at the default value of 1024\n\nIn this (default) case, the patch changes nothing.  Calls with nfds \u003e 1024\nfail with EINVAL both before and after the patch, and calls with nfds \u003c\u003d\n1024 pass the check both before and after the patch, since 1024 is the\ninitial value of max_fdset.\n\n2) RLIMIT_NOFILE has been raised above the default\n\nIn this case, poll() becomes more permissive, allowing polling up to\nRLIMIT_NOFILE file descriptors even if less than 1024 have been opened.\nThe patch won\u0027t introduce new errors here.  If an application somehow\ndepends on poll() failing when it polls with duplicate or invalid file\ndescriptors, it\u0027s already broken, since this is already allowed below 1024,\nand will also work above 1024 if enough file descriptors have been open at\nsome point to cause max_fdset to have been increased above nfds.\n\n3) RLIMIT_NOFILE has been lowered below the default\n\nIn this case, the system administrator or the user has gone out of their\nway to protect the system from inefficient (or malicious) applications\nwasting kernel memory.  The current code allows polling up to 1024 file\ndescriptors even if RLIMIT_NOFILE is much lower, which is not what the user\nor administrator intended.  Well-written applications which only poll\nvalid, unique file descriptors will never notice the difference, because\nthey\u0027ll hit the limit on open() first.  If an application gets broken\nbecause of the patch in this case, then it was already poorly/maliciously\ndesigned, and allowing it to work in the past was a violation of POSIX and\na DoS risk on low-resource systems.\n\nWith this patch, poll() will permit exactly what POSIX suggests, no more,\nno less, and for any run-time value set with ulimit -n, not just 256 or\n1024.  There are existing apps which which poll a large number of file\ndescriptors, some of which may be invalid, and if those numbers stradle\n1024, they currently fail with or without the patch in -mm, though they\nworked fine under 2.4.18.\n\nSigned-off-by: Chris Snook \u003ccsnook@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "33b72ba0f86f45790bd7661053266cd8336c9757",
      "old_mode": 33188,
      "old_path": "fs/select.c",
      "new_id": "dcbc1112b7ec214c063eaf5786bb17d5f208e6b0",
      "new_mode": 33188,
      "new_path": "fs/select.c"
    }
  ]
}