)]}'
{
  "commit": "ee568b25ee9e160b32d1aef73d8b2ee9c05d34db",
  "tree": "a29f070d82e6f787570213161c4c46c16ca6ef8a",
  "parents": [
    "30390880debce4a68fd23e87a787f27609e4bf4a"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Tue Mar 17 10:02:35 2009 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Tue Mar 17 10:02:35 2009 -0700"
  },
  "message": "Avoid 64-bit \"switch()\" statements on 32-bit architectures\n\nCommit ee6f779b9e0851e2f7da292a9f58e0095edf615a (\"filp-\u003ef_pos not\ncorrectly updated in proc_task_readdir\") changed the proc code to use\nfilp-\u003ef_pos directly, rather than through a temporary variable.  In the\nprocess, that caused the operations to be done on the full 64 bits, even\nthough the offset is never that big.\n\nThat\u0027s all fine and dandy per se, but for some unfathomable reason gcc\ngenerates absolutely horrid code when using 64-bit values in switch()\nstatements.  To the point of actually calling out to gcc helper\nfunctions like __cmpdi2 rather than just doing the trivial comparisons\ndirectly the way gcc does for normal compares.  At which point we get\nlink failures, because we really don\u0027t want to support that kind of\ncrazy code.\n\nFix this by just casting the f_pos value to \"unsigned long\", which\nis plenty big enough for /proc, and avoids the gcc code generation issue.\n\nReported-by: Alexey Dobriyan \u003cadobriyan@gmail.com\u003e\nCc: Zhang Le \u003cr0bertz@gentoo.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "cc6ea2329e71f4f086e4949a6fb46a94a5e3de56",
      "old_mode": 33188,
      "old_path": "fs/proc/base.c",
      "new_id": "beaa0ce3b82e1de8fec8941584a03f3dc32a700b",
      "new_mode": 33188,
      "new_path": "fs/proc/base.c"
    }
  ]
}