)]}'
{
  "commit": "97b9410643475d6557d2517c2aff9fd2221141a9",
  "tree": "47b22d65e97075fa1d17852ee0c62485df23e7ed",
  "parents": [
    "320437af954cbe66478f1f5e8b34cb5a8d072191"
  ],
  "author": {
    "name": "Thomas Gleixner",
    "email": "tglx@linutronix.de",
    "time": "Tue Sep 24 21:50:23 2013 +0200"
  },
  "committer": {
    "name": "Thomas Gleixner",
    "email": "tglx@linutronix.de",
    "time": "Wed Oct 23 12:51:21 2013 +0200"
  },
  "message": "clockevents: Sanitize ticks to nsec conversion\n\nMarc Kleine-Budde pointed out, that commit 77cc982 \"clocksource: use\nclockevents_config_and_register() where possible\" caused a regression\nfor some of the converted subarchs.\n\nThe reason is, that the clockevents core code converts the minimal\nhardware tick delta to a nanosecond value for core internal\nusage. This conversion is affected by integer math rounding loss, so\nthe backwards conversion to hardware ticks will likely result in a\nvalue which is less than the configured hardware limitation. The\naffected subarchs used their own workaround (SIGH!) which got lost in\nthe conversion.\n\nThe solution for the issue at hand is simple: adding evt-\u003emult - 1 to\nthe shifted value before the integer divison in the core conversion\nfunction takes care of it. But this only works for the case where for\nthe scaled math mult/shift pair \"mult \u003c\u003d 1 \u003c\u003c shift\" is true. For the\ncase where \"mult \u003e 1 \u003c\u003c shift\" we can apply the rounding add only for\nthe minimum delta value to make sure that the backward conversion is\nnot less than the given hardware limit. For the upper bound we need to\nomit the rounding add, because the backwards conversion is always\nlarger than the original latch value. That would violate the upper\nbound of the hardware device.\n\nThough looking closer at the details of that function reveals another\nbogosity: The upper bounds check is broken as well. Checking for a\nresulting \"clc\" value greater than KTIME_MAX after the conversion is\npointless. The conversion does:\n\n      u64 clc \u003d (latch \u003c\u003c evt-\u003eshift) / evt-\u003emult;\n\nSo there is no sanity check for (latch \u003c\u003c evt-\u003eshift) exceeding the\n64bit boundary. The latch argument is \"unsigned long\", so on a 64bit\narch the handed in argument could easily lead to an unnoticed shift\noverflow. With the above rounding fix applied the calculation before\nthe divison is:\n\n       u64 clc \u003d (latch \u003c\u003c evt-\u003eshift) + evt-\u003emult - 1;\n\nSo we need to make sure, that neither the shift nor the rounding add\nis overflowing the u64 boundary.\n\n[ukl: move assignment to rnd after eventually changing mult, fix build\n issue and correct comment with the right math]\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Russell King - ARM Linux \u003clinux@arm.linux.org.uk\u003e\nCc: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nCc: nicolas.ferre@atmel.com\nCc: Marc Pignat \u003cmarc.pignat@hevs.ch\u003e\nCc: john.stultz@linaro.org\nCc: kernel@pengutronix.de\nCc: Ronald Wahl \u003cronald.wahl@raritan.com\u003e\nCc: LAK \u003clinux-arm-kernel@lists.infradead.org\u003e\nCc: Ludovic Desroches \u003cludovic.desroches@atmel.com\u003e\nCc: stable@vger.kernel.org\nLink: http://lkml.kernel.org/r/1380052223-24139-1-git-send-email-u.kleine-koenig@pengutronix.de\nSigned-off-by: Uwe Kleine-König \u003cu.kleine-koenig@pengutronix.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "38959c86678987d0306548b73c03b9413c68b321",
      "old_mode": 33188,
      "old_path": "kernel/time/clockevents.c",
      "new_id": "662c5798a685d77904fcc1080596e4e4bd5d34b3",
      "new_mode": 33188,
      "new_path": "kernel/time/clockevents.c"
    }
  ]
}