)]}'
{
  "commit": "e294a2074f0059de7c69b30fe3048fe61f971b83",
  "tree": "10dd8fbd6e6e34d8e2a1b67b57ac18ec20522a6b",
  "parents": [
    "82582b970d04ad4bcfaa9d3f9c3c256619fd889f"
  ],
  "author": {
    "name": "Roland Dreier",
    "email": "roland@purestorage.com",
    "time": "Mon Mar 28 14:13:35 2011 -0700"
  },
  "committer": {
    "name": "Willy Tarreau",
    "email": "w@1wt.eu",
    "time": "Sat Oct 06 00:35:00 2012 +0200"
  },
  "message": "Relax si_code check in rt_sigqueueinfo and rt_tgsigqueueinfo\n\ncommit 243b422af9ea9af4ead07a8ad54c90d4f9b6081a upstream\n\nCommit da48524eb206 (\"Prevent rt_sigqueueinfo and rt_tgsigqueueinfo\nfrom spoofing the signal code\") made the check on si_code too strict.\nThere are several legitimate places where glibc wants to queue a\nnegative si_code different from SI_QUEUE:\n\n - This was first noticed with glibc\u0027s aio implementation, which wants\n   to queue a signal with si_code SI_ASYNCIO; the current kernel\n   causes glibc\u0027s tst-aio4 test to fail because rt_sigqueueinfo()\n   fails with EPERM.\n\n - Further examination of the glibc source shows that getaddrinfo_a()\n   wants to use SI_ASYNCNL (which the kernel does not even define).\n   The timer_create() fallback code wants to queue signals with SI_TIMER.\n\nAs suggested by Oleg Nesterov \u003coleg@redhat.com\u003e, loosen the check to\nforbid only the problematic SI_TKILL case.\n\nReported-by: Klaus Dittrich \u003ckladit@arcor.de\u003e\nAcked-by: Julien Tinnes \u003cjln@google.com\u003e\nCc: \u003cstable@kernel.org\u003e\nSigned-off-by: Roland Dreier \u003croland@purestorage.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nTested-by: Krzysztof Mazur \u003ckrzysiek@podlesie.net\u003e\nSigned-off-by: Willy Tarreau \u003cw@1wt.eu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b368505a7b22fc09144721c10680b72c3e410cd4",
      "old_mode": 33188,
      "old_path": "kernel/signal.c",
      "new_id": "461885de3ff24d1548d6e254e0df7aa231d6864d",
      "new_mode": 33188,
      "new_path": "kernel/signal.c"
    }
  ]
}