)]}'
{
  "log": [
    {
      "commit": "232beb6ef710cf53def84d01276f59766b62756e",
      "tree": "25de72e5898ba09f9a0ad97743e1aa47f8f3df18",
      "parents": [
        "ea38cd4170bdf0aa767d04df8363d08d5cc45dd2"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "peterz@infradead.org",
        "time": "Thu Oct 02 16:17:02 2014 -0700"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:40 2014 +0800"
      },
      "message": "perf: fix perf bug in fork()\n\ncommit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream.\n\nOleg noticed that a cleanup by Sylvain actually uncovered a bug; by\ncalling perf_event_free_task() when failing sched_fork() we will not yet\nhave done the memset() on -\u003eperf_event_ctxp[] and will therefore try and\n\u0027free\u0027 the inherited contexts, which are still in use by the parent\nprocess.  This is bad..\n\nSuggested-by: Oleg Nesterov \u003coleg@redhat.com\u003e\nReported-by: Oleg Nesterov \u003coleg@redhat.com\u003e\nReported-by: Sylvain \u0027ythier\u0027 Hitier \u003csylvain.hitier@gmail.com\u003e\nSigned-off-by: Peter Zijlstra (Intel) \u003cpeterz@infradead.org\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "4fae6ccac642aa30d189dea30ef14306aad4d2d2",
      "tree": "f4277880c2438c5ef039b4a88d818555150799f9",
      "parents": [
        "699c06b386d592bede77d5a28ed1637c80ab99c0"
      ],
      "author": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Thu Sep 25 09:41:02 2014 +0800"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:38 2014 +0800"
      },
      "message": "cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags\n\ncommit 2ad654bc5e2b211e92f66da1d819e47d79a866f0 upstream.\n\nWhen we change cpuset.memory_spread_{page,slab}, cpuset will flip\nPF_SPREAD_{PAGE,SLAB} bit of tsk-\u003eflags for each task in that cpuset.\nThis should be done using atomic bitops, but currently we don\u0027t,\nwhich is broken.\n\nTetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happened\nwhen one thread tried to clear PF_USED_MATH while at the same time another\nthread tried to flip PF_SPREAD_PAGE/PF_SPREAD_SLAB. They both operate on\nthe same task.\n\nHere\u0027s the full report:\nhttps://lkml.org/lkml/2014/9/19/230\n\nTo fix this, we make PF_SPREAD_PAGE and PF_SPREAD_SLAB atomic flags.\n\nv4:\n- updated mm/slab.c. (Fengguang Wu)\n- updated Documentation.\n\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Miao Xie \u003cmiaox@cn.fujitsu.com\u003e\nCc: Kees Cook \u003ckeescook@chromium.org\u003e\nFixes: 950592f7b991 (\"cpusets: update tasks\u0027 page/slab spread flags in time\")\nReported-by: Tetsuo Handa \u003cpenguin-kernel@I-love.SAKURA.ne.jp\u003e\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\n[lizf: Backported to 3.4:\n - adjust context\n - check current-\u003eflags \u0026 PF_MEMPOLICY rather than current-\u003emempolicy]\n"
    },
    {
      "commit": "1f8f277312d81d9412ec94bec8ab1ba0dce0bf05",
      "tree": "8e03c5bb56e719859f858c5c00387e20491daf97",
      "parents": [
        "cf33e82d6b78b8ada9ee06809440a62adcb16021"
      ],
      "author": {
        "name": "Cong Wang",
        "email": "cwang@twopensource.com",
        "time": "Tue Sep 02 15:27:20 2014 -0700"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:32 2014 +0800"
      },
      "message": "perf: Fix a race condition in perf_remove_from_context()\n\ncommit 3577af70a2ce4853d58e57d832e687d739281479 upstream.\n\nWe saw a kernel soft lockup in perf_remove_from_context(),\nit looks like the `perf` process, when exiting, could not go\nout of the retry loop. Meanwhile, the target process was forking\na child. So either the target process should execute the smp\nfunction call to deactive the event (if it was running) or it should\ndo a context switch which deactives the event.\n\nIt seems we optimize out a context switch in perf_event_context_sched_out(),\nand what\u0027s more important, we still test an obsolete task pointer when\nretrying, so no one actually would deactive that event in this situation.\nFix it directly by reloading the task pointer in perf_remove_from_context().\n\nThis should cure the above soft lockup.\n\nSigned-off-by: Cong Wang \u003ccwang@twopensource.com\u003e\nSigned-off-by: Cong Wang \u003cxiyou.wangcong@gmail.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Paul Mackerras \u003cpaulus@samba.org\u003e\nCc: Arnaldo Carvalho de Melo \u003cacme@kernel.org\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nLink: http://lkml.kernel.org/r/1409696840-843-1-git-send-email-xiyou.wangcong@gmail.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "49d4f0197912461fb2939ca51521b47655b04b11",
      "tree": "c9fbeb1f40c7e05498e157a4d6a2846d68750306",
      "parents": [
        "a90ec2a8bbd22a90dfdb5ca1b294c900226b7ff8"
      ],
      "author": {
        "name": "Andrew Hunter",
        "email": "ahh@google.com",
        "time": "Thu Sep 04 14:17:16 2014 -0700"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:32 2014 +0800"
      },
      "message": "jiffies: Fix timeval conversion to jiffies\n\ncommit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream.\n\ntimeval_to_jiffies tried to round a timeval up to an integral number\nof jiffies, but the logic for doing so was incorrect: intervals\ncorresponding to exactly N jiffies would become N+1. This manifested\nitself particularly repeatedly stopping/starting an itimer:\n\nsetitimer(ITIMER_PROF, \u0026val, NULL);\nsetitimer(ITIMER_PROF, NULL, \u0026val);\n\nwould add a full tick to val, _even if it was exactly representable in\nterms of jiffies_ (say, the result of a previous rounding.)  Doing\nthis repeatedly would cause unbounded growth in val.  So fix the math.\n\nHere\u0027s what was wrong with the conversion: we essentially computed\n(eliding seconds)\n\njiffies \u003d usec  * (NSEC_PER_USEC/TICK_NSEC)\n\nby using scaling arithmetic, which took the best approximation of\nNSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC \u003d\nx/(2^USEC_JIFFIE_SC), and computed:\n\njiffies \u003d (usec * x) \u003e\u003e USEC_JIFFIE_SC\n\nand rounded this calculation up in the intermediate form (since we\ncan\u0027t necessarily exactly represent TICK_NSEC in usec.) But the\nscaling arithmetic is a (very slight) *over*approximation of the true\nvalue; that is, instead of dividing by (1 usec/ 1 jiffie), we\neffectively divided by (1 usec/1 jiffie)-epsilon (rounding\ndown). This would normally be fine, but we want to round timeouts up,\nand we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this\nwould be fine if our division was exact, but dividing this by the\nslightly smaller factor was equivalent to adding just _over_ 1 to the\nfinal result (instead of just _under_ 1, as desired.)\n\nIn particular, with HZ\u003d1000, we consistently computed that 10000 usec\nwas 11 jiffies; the same was true for any exact multiple of\nTICK_NSEC.\n\nWe could possibly still round in the intermediate form, adding\nsomething less than 2^USEC_JIFFIE_SC - 1, but easier still is to\nconvert usec-\u003ensec, round in nanoseconds, and then convert using\ntime*spec*_to_jiffies.  This adds one constant multiplication, and is\nnot observably slower in microbenchmarks on recent x86 hardware.\n\nTested: the following program:\n\nint main() {\n  struct itimerval zero \u003d {{0, 0}, {0, 0}};\n  /* Initially set to 10 ms. */\n  struct itimerval initial \u003d zero;\n  initial.it_interval.tv_usec \u003d 10000;\n  setitimer(ITIMER_PROF, \u0026initial, NULL);\n  /* Save and restore several times. */\n  for (size_t i \u003d 0; i \u003c 10; ++i) {\n    struct itimerval prev;\n    setitimer(ITIMER_PROF, \u0026zero, \u0026prev);\n    /* on old kernels, this goes up by TICK_USEC every iteration */\n    printf(\"previous value: %ld %ld %ld %ld\\n\",\n           prev.it_interval.tv_sec, prev.it_interval.tv_usec,\n           prev.it_value.tv_sec, prev.it_value.tv_usec);\n    setitimer(ITIMER_PROF, \u0026prev, NULL);\n  }\n    return 0;\n}\n\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Ingo Molnar \u003cmingo@redhat.com\u003e\nCc: Paul Turner \u003cpjt@google.com\u003e\nCc: Richard Cochran \u003crichardcochran@gmail.com\u003e\nCc: Prarit Bhargava \u003cprarit@redhat.com\u003e\nReviewed-by: Paul Turner \u003cpjt@google.com\u003e\nReported-by: Aaron Jacobs \u003cjacobsa@google.com\u003e\nSigned-off-by: Andrew Hunter \u003cahh@google.com\u003e\n[jstultz: Tweaked to apply to 3.17-rc]\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\n[lizf: Backported to 3.4: adjust filename]\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "e06503426ebc296f1ae67bfd4733afadb69076cb",
      "tree": "f2830b94df6dca8837d91a538787dc6120d07c51",
      "parents": [
        "b114657d1e55a0484bcfdb3f3b946f96bb2f80e7"
      ],
      "author": {
        "name": "Richard Larocque",
        "email": "rlarocque@google.com",
        "time": "Tue Sep 09 18:31:05 2014 -0700"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:31 2014 +0800"
      },
      "message": "alarmtimer: Lock k_itimer during timer callback\n\ncommit 474e941bed9262f5fa2394f9a4a67e24499e5926 upstream.\n\nLocks the k_itimer\u0027s it_lock member when handling the alarm timer\u0027s\nexpiry callback.\n\nThe regular posix timers defined in posix-timers.c have this lock held\nduring timout processing because their callbacks are routed through\nposix_timer_fn().  The alarm timers follow a different path, so they\nought to grab the lock somewhere else.\n\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Richard Cochran \u003crichardcochran@gmail.com\u003e\nCc: Prarit Bhargava \u003cprarit@redhat.com\u003e\nCc: Sharvil Nanavati \u003csharvil@google.com\u003e\nSigned-off-by: Richard Larocque \u003crlarocque@google.com\u003e\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "b114657d1e55a0484bcfdb3f3b946f96bb2f80e7",
      "tree": "b2e1e5035bb4dd5ecf74f3513241c2478a36df87",
      "parents": [
        "7ccf24be49f1020e408ee27a3714d41590009422"
      ],
      "author": {
        "name": "Richard Larocque",
        "email": "rlarocque@google.com",
        "time": "Tue Sep 09 18:31:04 2014 -0700"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:31 2014 +0800"
      },
      "message": "alarmtimer: Do not signal SIGEV_NONE timers\n\ncommit 265b81d23a46c39df0a735a3af4238954b41a4c2 upstream.\n\nAvoids sending a signal to alarm timers created with sigev_notify set to\nSIGEV_NONE by checking for that special case in the timeout callback.\n\nThe regular posix timers avoid sending signals to SIGEV_NONE timers by\nnot scheduling any callbacks for them in the first place.  Although it\nwould be possible to do something similar for alarm timers, it\u0027s simpler\nto handle this as a special case in the timeout.\n\nPrior to this patch, the alarm timer would ignore the sigev_notify value\nand try to deliver signals to the process anyway.  Even worse, the\nsanity check for the value of sigev_signo is skipped when SIGEV_NONE was\nspecified, so the signal number could be bogus.  If sigev_signo was an\nunitialized value (as it often would be if SIGEV_NONE is used), then\nit\u0027s hard to predict which signal will be sent.\n\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Richard Cochran \u003crichardcochran@gmail.com\u003e\nCc: Prarit Bhargava \u003cprarit@redhat.com\u003e\nCc: Sharvil Nanavati \u003csharvil@google.com\u003e\nSigned-off-by: Richard Larocque \u003crlarocque@google.com\u003e\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "7ccf24be49f1020e408ee27a3714d41590009422",
      "tree": "c16f56adfb93c06a50e0b45a3bc77b60d9473d20",
      "parents": [
        "40ee8d0faf83eb55d4829796a28dacf48519caec"
      ],
      "author": {
        "name": "Richard Larocque",
        "email": "rlarocque@google.com",
        "time": "Tue Sep 09 18:31:03 2014 -0700"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:31 2014 +0800"
      },
      "message": "alarmtimer: Return relative times in timer_gettime\n\ncommit e86fea764991e00a03ff1e56409ec9cacdbda4c9 upstream.\n\nReturns the time remaining for an alarm timer, rather than the time at\nwhich it is scheduled to expire.  If the timer has already expired or it\nis not currently scheduled, the it_value\u0027s members are set to zero.\n\nThis new behavior matches that of the other posix-timers and the POSIX\nspecifications.\n\nThis is a change in user-visible behavior, and may break existing\napplications.  Hopefully, few users rely on the old incorrect behavior.\n\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Richard Cochran \u003crichardcochran@gmail.com\u003e\nCc: Prarit Bhargava \u003cprarit@redhat.com\u003e\nCc: Sharvil Nanavati \u003csharvil@google.com\u003e\nSigned-off-by: Richard Larocque \u003crlarocque@google.com\u003e\n[jstultz: minor style tweak]\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\n[lizf: Backported to 3.4:\n - add alarm_expires_remaining() introduced by commit 6cffe00f7d4e]\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "40ee8d0faf83eb55d4829796a28dacf48519caec",
      "tree": "0395a72bf583d469f1a2552716faf0dc7841b0dc",
      "parents": [
        "e393942b1628770467481935738fd214566fe7bb"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Thu Sep 11 23:44:35 2014 +0200"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:30 2014 +0800"
      },
      "message": "futex: Unlock hb-\u003elock in futex_wait_requeue_pi() error path\n\ncommit 13c42c2f43b19aab3195f2d357db00d1e885eaa8 upstream.\n\nfutex_wait_requeue_pi() calls futex_wait_setup(). If\nfutex_wait_setup() succeeds it returns with hb-\u003elock held and\npreemption disabled. Now the sanity check after this does:\n\n        if (match_futex(\u0026q.key, \u0026key2)) {\n\t   \tret \u003d -EINVAL;\n\t\tgoto out_put_keys;\n\t}\n\nwhich releases the keys but does not release hb-\u003elock.\n\nSo we happily return to user space with hb-\u003elock held and therefor\npreemption disabled.\n\nUnlock hb-\u003elock before taking the exit route.\n\nReported-by: Dave \"Trinity\" Jones \u003cdavej@redhat.com\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nReviewed-by: Darren Hart \u003cdvhart@linux.intel.com\u003e\nReviewed-by: Davidlohr Bueso \u003cdave@stgolabs.net\u003e\nCc: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLink: http://lkml.kernel.org/r/alpine.DEB.2.10.1409112318500.4178@nanos\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\n[lizf: Backported to 3.4: queue_unlock() takes two parameters]\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "a48fec2f276f8003fb8098df892ea3acb5d7149a",
      "tree": "f9215afbe8d73833a7c5eaba2f6dc54ed4b8f96c",
      "parents": [
        "c16060dfda1c8418a9e638b79f5d2101b482e89f"
      ],
      "author": {
        "name": "Alban Crequy",
        "email": "alban.crequy@collabora.co.uk",
        "time": "Mon Aug 18 12:20:20 2014 +0100"
      },
      "committer": {
        "name": "Zefan Li",
        "email": "lizefan@huawei.com",
        "time": "Mon Dec 01 18:02:23 2014 +0800"
      },
      "message": "cgroup: reject cgroup names with \u0027 \u0027\n\ncommit 71b1fb5c4473a5b1e601d41b109bdfe001ec82e0 upstream.\n\n/proc/\u003cpid\u003e/cgroup contains one cgroup path on each line. If cgroup names are\nallowed to contain \"\\n\", applications cannot parse /proc/\u003cpid\u003e/cgroup safely.\n\nSigned-off-by: Alban Crequy \u003calban.crequy@collabora.co.uk\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\n[lizf: Backported to 3.4:\n - adjust context\n - s/name/dentry-\u003ed_name.name/]\nSigned-off-by: Zefan Li \u003clizefan@huawei.com\u003e\n"
    },
    {
      "commit": "fbbb7208969e8bfbd07782bbec069878a29d3267",
      "tree": "b0b5110b20ae77407f43801d002e26dd12764c09",
      "parents": [
        "f73ff697833654ee578b606ea746d15dc1220aab"
      ],
      "author": {
        "name": "Jan Kara",
        "email": "jack@suse.cz",
        "time": "Fri Aug 01 12:20:02 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Aug 07 12:00:10 2014 -0700"
      },
      "message": "timer: Fix lock inversion between hrtimer_bases.lock and scheduler locks\n\ncommit 504d58745c9ca28d33572e2d8a9990b43e06075d upstream.\n\nclockevents_increase_min_delta() calls printk() from under\nhrtimer_bases.lock. That causes lock inversion on scheduler locks because\nprintk() can call into the scheduler. Lockdep puts it as:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n[ INFO: possible circular locking dependency detected ]\n3.15.0-rc8-06195-g939f04b #2 Not tainted\n-------------------------------------------------------\ntrinity-main/74 is trying to acquire lock:\n (\u0026port_lock_key){-.....}, at: [\u003c811c60be\u003e] serial8250_console_write+0x8c/0x10c\n\nbut task is already holding lock:\n (hrtimer_bases.lock){-.-...}, at: [\u003c8103caeb\u003e] hrtimer_try_to_cancel+0x13/0x66\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #5 (hrtimer_bases.lock){-.-...}:\n       [\u003c8104a942\u003e] lock_acquire+0x92/0x101\n       [\u003c8142f11d\u003e] _raw_spin_lock_irqsave+0x2e/0x3e\n       [\u003c8103c918\u003e] __hrtimer_start_range_ns+0x1c/0x197\n       [\u003c8107ec20\u003e] perf_swevent_start_hrtimer.part.41+0x7a/0x85\n       [\u003c81080792\u003e] task_clock_event_start+0x3a/0x3f\n       [\u003c810807a4\u003e] task_clock_event_add+0xd/0x14\n       [\u003c8108259a\u003e] event_sched_in+0xb6/0x17a\n       [\u003c810826a2\u003e] group_sched_in+0x44/0x122\n       [\u003c81082885\u003e] ctx_sched_in.isra.67+0x105/0x11f\n       [\u003c810828e6\u003e] perf_event_sched_in.isra.70+0x47/0x4b\n       [\u003c81082bf6\u003e] __perf_install_in_context+0x8b/0xa3\n       [\u003c8107eb8e\u003e] remote_function+0x12/0x2a\n       [\u003c8105f5af\u003e] smp_call_function_single+0x2d/0x53\n       [\u003c8107e17d\u003e] task_function_call+0x30/0x36\n       [\u003c8107fb82\u003e] perf_install_in_context+0x87/0xbb\n       [\u003c810852c9\u003e] SYSC_perf_event_open+0x5c6/0x701\n       [\u003c810856f9\u003e] SyS_perf_event_open+0x17/0x19\n       [\u003c8142f8ee\u003e] syscall_call+0x7/0xb\n\n-\u003e #4 (\u0026ctx-\u003elock){......}:\n       [\u003c8104a942\u003e] lock_acquire+0x92/0x101\n       [\u003c8142f04c\u003e] _raw_spin_lock+0x21/0x30\n       [\u003c81081df3\u003e] __perf_event_task_sched_out+0x1dc/0x34f\n       [\u003c8142cacc\u003e] __schedule+0x4c6/0x4cb\n       [\u003c8142cae0\u003e] schedule+0xf/0x11\n       [\u003c8142f9a6\u003e] work_resched+0x5/0x30\n\n-\u003e #3 (\u0026rq-\u003elock){-.-.-.}:\n       [\u003c8104a942\u003e] lock_acquire+0x92/0x101\n       [\u003c8142f04c\u003e] _raw_spin_lock+0x21/0x30\n       [\u003c81040873\u003e] __task_rq_lock+0x33/0x3a\n       [\u003c8104184c\u003e] wake_up_new_task+0x25/0xc2\n       [\u003c8102474b\u003e] do_fork+0x15c/0x2a0\n       [\u003c810248a9\u003e] kernel_thread+0x1a/0x1f\n       [\u003c814232a2\u003e] rest_init+0x1a/0x10e\n       [\u003c817af949\u003e] start_kernel+0x303/0x308\n       [\u003c817af2ab\u003e] i386_start_kernel+0x79/0x7d\n\n-\u003e #2 (\u0026p-\u003epi_lock){-.-...}:\n       [\u003c8104a942\u003e] lock_acquire+0x92/0x101\n       [\u003c8142f11d\u003e] _raw_spin_lock_irqsave+0x2e/0x3e\n       [\u003c810413dd\u003e] try_to_wake_up+0x1d/0xd6\n       [\u003c810414cd\u003e] default_wake_function+0xb/0xd\n       [\u003c810461f3\u003e] __wake_up_common+0x39/0x59\n       [\u003c81046346\u003e] __wake_up+0x29/0x3b\n       [\u003c811b8733\u003e] tty_wakeup+0x49/0x51\n       [\u003c811c3568\u003e] uart_write_wakeup+0x17/0x19\n       [\u003c811c5dc1\u003e] serial8250_tx_chars+0xbc/0xfb\n       [\u003c811c5f28\u003e] serial8250_handle_irq+0x54/0x6a\n       [\u003c811c5f57\u003e] serial8250_default_handle_irq+0x19/0x1c\n       [\u003c811c56d8\u003e] serial8250_interrupt+0x38/0x9e\n       [\u003c810510e7\u003e] handle_irq_event_percpu+0x5f/0x1e2\n       [\u003c81051296\u003e] handle_irq_event+0x2c/0x43\n       [\u003c81052cee\u003e] handle_level_irq+0x57/0x80\n       [\u003c81002a72\u003e] handle_irq+0x46/0x5c\n       [\u003c810027df\u003e] do_IRQ+0x32/0x89\n       [\u003c8143036e\u003e] common_interrupt+0x2e/0x33\n       [\u003c8142f23c\u003e] _raw_spin_unlock_irqrestore+0x3f/0x49\n       [\u003c811c25a4\u003e] uart_start+0x2d/0x32\n       [\u003c811c2c04\u003e] uart_write+0xc7/0xd6\n       [\u003c811bc6f6\u003e] n_tty_write+0xb8/0x35e\n       [\u003c811b9beb\u003e] tty_write+0x163/0x1e4\n       [\u003c811b9cd9\u003e] redirected_tty_write+0x6d/0x75\n       [\u003c810b6ed6\u003e] vfs_write+0x75/0xb0\n       [\u003c810b7265\u003e] SyS_write+0x44/0x77\n       [\u003c8142f8ee\u003e] syscall_call+0x7/0xb\n\n-\u003e #1 (\u0026tty-\u003ewrite_wait){-.....}:\n       [\u003c8104a942\u003e] lock_acquire+0x92/0x101\n       [\u003c8142f11d\u003e] _raw_spin_lock_irqsave+0x2e/0x3e\n       [\u003c81046332\u003e] __wake_up+0x15/0x3b\n       [\u003c811b8733\u003e] tty_wakeup+0x49/0x51\n       [\u003c811c3568\u003e] uart_write_wakeup+0x17/0x19\n       [\u003c811c5dc1\u003e] serial8250_tx_chars+0xbc/0xfb\n       [\u003c811c5f28\u003e] serial8250_handle_irq+0x54/0x6a\n       [\u003c811c5f57\u003e] serial8250_default_handle_irq+0x19/0x1c\n       [\u003c811c56d8\u003e] serial8250_interrupt+0x38/0x9e\n       [\u003c810510e7\u003e] handle_irq_event_percpu+0x5f/0x1e2\n       [\u003c81051296\u003e] handle_irq_event+0x2c/0x43\n       [\u003c81052cee\u003e] handle_level_irq+0x57/0x80\n       [\u003c81002a72\u003e] handle_irq+0x46/0x5c\n       [\u003c810027df\u003e] do_IRQ+0x32/0x89\n       [\u003c8143036e\u003e] common_interrupt+0x2e/0x33\n       [\u003c8142f23c\u003e] _raw_spin_unlock_irqrestore+0x3f/0x49\n       [\u003c811c25a4\u003e] uart_start+0x2d/0x32\n       [\u003c811c2c04\u003e] uart_write+0xc7/0xd6\n       [\u003c811bc6f6\u003e] n_tty_write+0xb8/0x35e\n       [\u003c811b9beb\u003e] tty_write+0x163/0x1e4\n       [\u003c811b9cd9\u003e] redirected_tty_write+0x6d/0x75\n       [\u003c810b6ed6\u003e] vfs_write+0x75/0xb0\n       [\u003c810b7265\u003e] SyS_write+0x44/0x77\n       [\u003c8142f8ee\u003e] syscall_call+0x7/0xb\n\n-\u003e #0 (\u0026port_lock_key){-.....}:\n       [\u003c8104a62d\u003e] __lock_acquire+0x9ea/0xc6d\n       [\u003c8104a942\u003e] lock_acquire+0x92/0x101\n       [\u003c8142f11d\u003e] _raw_spin_lock_irqsave+0x2e/0x3e\n       [\u003c811c60be\u003e] serial8250_console_write+0x8c/0x10c\n       [\u003c8104e402\u003e] call_console_drivers.constprop.31+0x87/0x118\n       [\u003c8104f5d5\u003e] console_unlock+0x1d7/0x398\n       [\u003c8104fb70\u003e] vprintk_emit+0x3da/0x3e4\n       [\u003c81425f76\u003e] printk+0x17/0x19\n       [\u003c8105bfa0\u003e] clockevents_program_min_delta+0x104/0x116\n       [\u003c8105c548\u003e] clockevents_program_event+0xe7/0xf3\n       [\u003c8105cc1c\u003e] tick_program_event+0x1e/0x23\n       [\u003c8103c43c\u003e] hrtimer_force_reprogram+0x88/0x8f\n       [\u003c8103c49e\u003e] __remove_hrtimer+0x5b/0x79\n       [\u003c8103cb21\u003e] hrtimer_try_to_cancel+0x49/0x66\n       [\u003c8103cb4b\u003e] hrtimer_cancel+0xd/0x18\n       [\u003c8107f102\u003e] perf_swevent_cancel_hrtimer.part.60+0x2b/0x30\n       [\u003c81080705\u003e] task_clock_event_stop+0x20/0x64\n       [\u003c81080756\u003e] task_clock_event_del+0xd/0xf\n       [\u003c81081350\u003e] event_sched_out+0xab/0x11e\n       [\u003c810813e0\u003e] group_sched_out+0x1d/0x66\n       [\u003c81081682\u003e] ctx_sched_out+0xaf/0xbf\n       [\u003c81081e04\u003e] __perf_event_task_sched_out+0x1ed/0x34f\n       [\u003c8142cacc\u003e] __schedule+0x4c6/0x4cb\n       [\u003c8142cae0\u003e] schedule+0xf/0x11\n       [\u003c8142f9a6\u003e] work_resched+0x5/0x30\n\nother info that might help us debug this:\n\nChain exists of:\n  \u0026port_lock_key --\u003e \u0026ctx-\u003elock --\u003e hrtimer_bases.lock\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock(hrtimer_bases.lock);\n                               lock(\u0026ctx-\u003elock);\n                               lock(hrtimer_bases.lock);\n  lock(\u0026port_lock_key);\n\n *** DEADLOCK ***\n\n4 locks held by trinity-main/74:\n #0:  (\u0026rq-\u003elock){-.-.-.}, at: [\u003c8142c6f3\u003e] __schedule+0xed/0x4cb\n #1:  (\u0026ctx-\u003elock){......}, at: [\u003c81081df3\u003e] __perf_event_task_sched_out+0x1dc/0x34f\n #2:  (hrtimer_bases.lock){-.-...}, at: [\u003c8103caeb\u003e] hrtimer_try_to_cancel+0x13/0x66\n #3:  (console_lock){+.+...}, at: [\u003c8104fb5d\u003e] vprintk_emit+0x3c7/0x3e4\n\nstack backtrace:\nCPU: 0 PID: 74 Comm: trinity-main Not tainted 3.15.0-rc8-06195-g939f04b #2\n 00000000 81c3a310 8b995c14 81426f69 8b995c44 81425a99 8161f671 8161f570\n 8161f538 8161f559 8161f538 8b995c78 8b142bb0 00000004 8b142fdc 8b142bb0\n 8b995ca8 8104a62d 8b142fac 000016f2 81c3a310 00000001 00000001 00000003\nCall Trace:\n [\u003c81426f69\u003e] dump_stack+0x16/0x18\n [\u003c81425a99\u003e] print_circular_bug+0x18f/0x19c\n [\u003c8104a62d\u003e] __lock_acquire+0x9ea/0xc6d\n [\u003c8104a942\u003e] lock_acquire+0x92/0x101\n [\u003c811c60be\u003e] ? serial8250_console_write+0x8c/0x10c\n [\u003c811c6032\u003e] ? wait_for_xmitr+0x76/0x76\n [\u003c8142f11d\u003e] _raw_spin_lock_irqsave+0x2e/0x3e\n [\u003c811c60be\u003e] ? serial8250_console_write+0x8c/0x10c\n [\u003c811c60be\u003e] serial8250_console_write+0x8c/0x10c\n [\u003c8104af87\u003e] ? lock_release+0x191/0x223\n [\u003c811c6032\u003e] ? wait_for_xmitr+0x76/0x76\n [\u003c8104e402\u003e] call_console_drivers.constprop.31+0x87/0x118\n [\u003c8104f5d5\u003e] console_unlock+0x1d7/0x398\n [\u003c8104fb70\u003e] vprintk_emit+0x3da/0x3e4\n [\u003c81425f76\u003e] printk+0x17/0x19\n [\u003c8105bfa0\u003e] clockevents_program_min_delta+0x104/0x116\n [\u003c8105cc1c\u003e] tick_program_event+0x1e/0x23\n [\u003c8103c43c\u003e] hrtimer_force_reprogram+0x88/0x8f\n [\u003c8103c49e\u003e] __remove_hrtimer+0x5b/0x79\n [\u003c8103cb21\u003e] hrtimer_try_to_cancel+0x49/0x66\n [\u003c8103cb4b\u003e] hrtimer_cancel+0xd/0x18\n [\u003c8107f102\u003e] perf_swevent_cancel_hrtimer.part.60+0x2b/0x30\n [\u003c81080705\u003e] task_clock_event_stop+0x20/0x64\n [\u003c81080756\u003e] task_clock_event_del+0xd/0xf\n [\u003c81081350\u003e] event_sched_out+0xab/0x11e\n [\u003c810813e0\u003e] group_sched_out+0x1d/0x66\n [\u003c81081682\u003e] ctx_sched_out+0xaf/0xbf\n [\u003c81081e04\u003e] __perf_event_task_sched_out+0x1ed/0x34f\n [\u003c8104416d\u003e] ? __dequeue_entity+0x23/0x27\n [\u003c81044505\u003e] ? pick_next_task_fair+0xb1/0x120\n [\u003c8142cacc\u003e] __schedule+0x4c6/0x4cb\n [\u003c81047574\u003e] ? trace_hardirqs_off_caller+0xd7/0x108\n [\u003c810475b0\u003e] ? trace_hardirqs_off+0xb/0xd\n [\u003c81056346\u003e] ? rcu_irq_exit+0x64/0x77\n\nFix the problem by using printk_deferred() which does not call into the\nscheduler.\n\nReported-by: Fengguang Wu \u003cfengguang.wu@intel.com\u003e\nSigned-off-by: Jan Kara \u003cjack@suse.cz\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "f73ff697833654ee578b606ea746d15dc1220aab",
      "tree": "5fba9efb577e61579fc9dba897f500b200fd6985",
      "parents": [
        "7f6c1deb02e6ac110645c87fd2446594803a8a72"
      ],
      "author": {
        "name": "John Stultz",
        "email": "john.stultz@linaro.org",
        "time": "Wed Jun 04 16:11:40 2014 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Aug 07 12:00:10 2014 -0700"
      },
      "message": "printk: rename printk_sched to printk_deferred\n\ncommit aac74dc495456412c4130a1167ce4beb6c1f0b38 upstream.\n\nAfter learning we\u0027ll need some sort of deferred printk functionality in\nthe timekeeping core, Peter suggested we rename the printk_sched function\nso it can be reused by needed subsystems.\n\nThis only changes the function name. No logic changes.\n\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\nReviewed-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Jan Kara \u003cjack@suse.cz\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Jiri Bohac \u003cjbohac@suse.cz\u003e\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Ingo Molnar \u003cmingo@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "5dc1c8851364ffb79cb9403f72c712ee83cce755",
      "tree": "b327092a6e3ddd4f5b89de8809c80f691c74c018",
      "parents": [
        "299e667e26e9e3382fa471370121b117fa8ae987"
      ],
      "author": {
        "name": "Takashi Iwai",
        "email": "tiwai@suse.de",
        "time": "Tue Jul 15 08:51:27 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Jul 28 07:06:46 2014 -0700"
      },
      "message": "PM / sleep: Fix request_firmware() error at resume\n\ncommit 4320f6b1d9db4ca912c5eb6ecb328b2e090e1586 upstream.\n\nThe commit [247bc037: PM / Sleep: Mitigate race between the freezer\nand request_firmware()] introduced the finer state control, but it\nalso leads to a new bug; for example, a bug report regarding the\nfirmware loading of intel BT device at suspend/resume:\n  https://bugzilla.novell.com/show_bug.cgi?id\u003d873790\n\nThe root cause seems to be a small window between the process resume\nand the clear of usermodehelper lock.  The request_firmware() function\nchecks the UMH lock and gives up when it\u0027s in UMH_DISABLE state.  This\nis for avoiding the invalid  f/w loading during suspend/resume phase.\nThe problem is, however, that usermodehelper_enable() is called at the\nend of thaw_processes().  Thus, a thawed process in between can kick\noff the f/w loader code path (in this case, via btusb_setup_intel())\neven before the call of usermodehelper_enable().  Then\nusermodehelper_read_trylock() returns an error and request_firmware()\nspews WARN_ON() in the end.\n\nThis oneliner patch fixes the issue just by setting to UMH_FREEZING\nstate again before restarting tasks, so that the call of\nrequest_firmware() will be blocked until the end of this function\ninstead of returning an error.\n\nFixes: 247bc0374254 (PM / Sleep: Mitigate race between the freezer and request_firmware())\nLink: https://bugzilla.novell.com/show_bug.cgi?id\u003d873790\nSigned-off-by: Takashi Iwai \u003ctiwai@suse.de\u003e\nSigned-off-by: Rafael J. Wysocki \u003crafael.j.wysocki@intel.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "299e667e26e9e3382fa471370121b117fa8ae987",
      "tree": "cb7dc72c583b7c561369c7ed28f6cfa3ad8874e8",
      "parents": [
        "b63dd4c81b9eccf95c1d08775bb7f2d05d70c8f1"
      ],
      "author": {
        "name": "John Stultz",
        "email": "john.stultz@linaro.org",
        "time": "Mon Jul 07 14:06:11 2014 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Jul 28 07:06:46 2014 -0700"
      },
      "message": "alarmtimer: Fix bug where relative alarm timers were treated as absolute\n\ncommit 16927776ae757d0d132bdbfabbfe2c498342bd59 upstream.\n\nSharvil noticed with the posix timer_settime interface, using the\nCLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users\ntried to specify a relative time timer, it would incorrectly be\ntreated as absolute regardless of the state of the flags argument.\n\nThis patch corrects this, properly checking the absolute/relative flag,\nas well as adds further error checking that no invalid flag bits are set.\n\nReported-by: Sharvil Nanavati \u003csharvil@google.com\u003e\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Prarit Bhargava \u003cprarit@redhat.com\u003e\nCc: Sharvil Nanavati \u003csharvil@google.com\u003e\nLink: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.org\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "2a77794da631ec2b2d2243b83fa6793676cdf411",
      "tree": "00290e2eca39d1b204d7a518b749b1ae68b18c0f",
      "parents": [
        "ea018da95368adfb700689bd9842714f7c3db665"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Wed Jun 11 18:44:04 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jul 17 15:39:50 2014 -0700"
      },
      "message": "rtmutex: Plug slow unlock race\n\ncommit 27e35715df54cbc4f2d044f681802ae30479e7fb upstream.\n\nWhen the rtmutex fast path is enabled the slow unlock function can\ncreate the following situation:\n\nspin_lock(foo-\u003em-\u003ewait_lock);\nfoo-\u003em-\u003eowner \u003d NULL;\n\t    \t\t\trt_mutex_lock(foo-\u003em); \u003c-- fast path\n\t\t\t\tfree \u003d atomic_dec_and_test(foo-\u003erefcnt);\n\t\t\t\trt_mutex_unlock(foo-\u003em); \u003c-- fast path\n\t\t\t\tif (free)\n\t\t\t\t   kfree(foo);\n\nspin_unlock(foo-\u003em-\u003ewait_lock); \u003c--- Use after free.\n\nPlug the race by changing the slow unlock to the following scheme:\n\n     while (!rt_mutex_has_waiters(m)) {\n     \t    /* Clear the waiters bit in m-\u003eowner */\n\t    clear_rt_mutex_waiters(m);\n      \t    owner \u003d rt_mutex_owner(m);\n      \t    spin_unlock(m-\u003ewait_lock);\n      \t    if (cmpxchg(m-\u003eowner, owner, 0) \u003d\u003d owner)\n      \t       return;\n      \t    spin_lock(m-\u003ewait_lock);\n     }\n\nSo in case of a new waiter incoming while the owner tries the slow\npath unlock we have two situations:\n\n unlock(wait_lock);\n\t\t\t\t\tlock(wait_lock);\n cmpxchg(p, owner, 0) \u003d\u003d owner\n \t    \t   \t\t\tmark_rt_mutex_waiters(lock);\n\t \t\t\t\tacquire(lock);\n\nOr:\n\n unlock(wait_lock);\n\t\t\t\t\tlock(wait_lock);\n\t \t\t\t\tmark_rt_mutex_waiters(lock);\n cmpxchg(p, owner, 0) !\u003d owner\n\t\t\t\t\tenqueue_waiter();\n\t\t\t\t\tunlock(wait_lock);\n lock(wait_lock);\n wakeup_next waiter();\n unlock(wait_lock);\n\t\t\t\t\tlock(wait_lock);\n\t\t\t\t\tacquire(lock);\n\nIf the fast path is disabled, then the simple\n\n   m-\u003eowner \u003d NULL;\n   unlock(m-\u003ewait_lock);\n\nis sufficient as all access to m-\u003eowner is serialized via\nm-\u003ewait_lock;\n\nAlso document and clarify the wakeup_next_waiter function as suggested\nby Oleg Nesterov.\n\nReported-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nReviewed-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/20140611183852.937945560@linutronix.de\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Mike Galbraith \u003cumgwanakikbuti@gmail.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "ea018da95368adfb700689bd9842714f7c3db665",
      "tree": "1292bd16701c41189f489d5950b074772b5cb2fc",
      "parents": [
        "307e2e09be9993d7fe403a7310b28ab2d8e2f6ce"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Thu Jun 05 12:34:23 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jul 17 15:39:50 2014 -0700"
      },
      "message": "rtmutex: Handle deadlock detection smarter\n\ncommit 3d5c9340d1949733eb37616abd15db36aef9a57c upstream.\n\nEven in the case when deadlock detection is not requested by the\ncaller, we can detect deadlocks. Right now the code stops the lock\nchain walk and keeps the waiter enqueued, even on itself. Silly not to\nyell when such a scenario is detected and to keep the waiter enqueued.\n\nReturn -EDEADLK unconditionally and handle it at the call sites.\n\nThe futex calls return -EDEADLK. The non futex ones dequeue the\nwaiter, throw a warning and put the task into a schedule loop.\n\nTagged for stable as it makes the code more robust.\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Brad Mouring \u003cbmouring@ni.com\u003e\nLink: http://lkml.kernel.org/r/20140605152801.836501969@linutronix.de\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Mike Galbraith \u003cumgwanakikbuti@gmail.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "307e2e09be9993d7fe403a7310b28ab2d8e2f6ce",
      "tree": "63c91c95088bebcce1bf4df486b17aa5312c95d0",
      "parents": [
        "90b421b52720b30644e104da002505f08a77c07a"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Thu Jun 05 11:16:12 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jul 17 15:39:50 2014 -0700"
      },
      "message": "rtmutex: Detect changes in the pi lock chain\n\ncommit 82084984383babe728e6e3c9a8e5c46278091315 upstream.\n\nWhen we walk the lock chain, we drop all locks after each step. So the\nlock chain can change under us before we reacquire the locks. That\u0027s\nharmless in principle as we just follow the wrong lock path. But it\ncan lead to a false positive in the dead lock detection logic:\n\nT0 holds L0\nT0 blocks on L1 held by T1\nT1 blocks on L2 held by T2\nT2 blocks on L3 held by T3\nT4 blocks on L4 held by T4\n\nNow we walk the chain\n\nlock T1 -\u003e lock L2 -\u003e adjust L2 -\u003e unlock T1 -\u003e\n     lock T2 -\u003e  adjust T2 -\u003e  drop locks\n\nT2 times out and blocks on L0\n\nNow we continue:\n\nlock T2 -\u003e lock L0 -\u003e deadlock detected, but it\u0027s not a deadlock at all.\n\nBrad tried to work around that in the deadlock detection logic itself,\nbut the more I looked at it the less I liked it, because it\u0027s crystal\nball magic after the fact.\n\nWe actually can detect a chain change very simple:\n\nlock T1 -\u003e lock L2 -\u003e adjust L2 -\u003e unlock T1 -\u003e lock T2 -\u003e adjust T2 -\u003e\n\n     next_lock \u003d T2-\u003epi_blocked_on-\u003elock;\n\ndrop locks\n\nT2 times out and blocks on L0\n\nNow we continue:\n\nlock T2 -\u003e\n\n     if (next_lock !\u003d T2-\u003epi_blocked_on-\u003elock)\n     \t   return;\n\nSo if we detect that T2 is now blocked on a different lock we stop the\nchain walk. That\u0027s also correct in the following scenario:\n\nlock T1 -\u003e lock L2 -\u003e adjust L2 -\u003e unlock T1 -\u003e lock T2 -\u003e adjust T2 -\u003e\n\n     next_lock \u003d T2-\u003epi_blocked_on-\u003elock;\n\ndrop locks\n\nT3 times out and drops L3\nT2 acquires L3 and blocks on L4 now\n\nNow we continue:\n\nlock T2 -\u003e\n\n     if (next_lock !\u003d T2-\u003epi_blocked_on-\u003elock)\n     \t   return;\n\nWe don\u0027t have to follow up the chain at that point, because T2\npropagated our priority up to T4 already.\n\n[ Folded a cleanup patch from peterz ]\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nReported-by: Brad Mouring \u003cbmouring@ni.com\u003e\nCc: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/20140605152801.930031935@linutronix.de\nSigned-off-by: Mike Galbraith \u003cumgwanakikbuti@gmail.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "90b421b52720b30644e104da002505f08a77c07a",
      "tree": "6e267789da89c5601db4ad1f376b549215f7afdc",
      "parents": [
        "bf09db97205d46b3e083582eb2799aedddd9953b"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Thu May 22 03:25:39 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jul 17 15:39:50 2014 -0700"
      },
      "message": "rtmutex: Fix deadlock detector for real\n\ncommit 397335f004f41e5fcf7a795e94eb3ab83411a17c upstream.\n\nThe current deadlock detection logic does not work reliably due to the\nfollowing early exit path:\n\n\t/*\n\t * Drop out, when the task has no waiters. Note,\n\t * top_waiter can be NULL, when we are in the deboosting\n\t * mode!\n\t */\n\tif (top_waiter \u0026\u0026 (!task_has_pi_waiters(task) ||\n\t\t\t   top_waiter !\u003d task_top_pi_waiter(task)))\n\t\tgoto out_unlock_pi;\n\nSo this not only exits when the task has no waiters, it also exits\nunconditionally when the current waiter is not the top priority waiter\nof the task.\n\nSo in a nested locking scenario, it might abort the lock chain walk\nand therefor miss a potential deadlock.\n\nSimple fix: Continue the chain walk, when deadlock detection is\nenabled.\n\nWe also avoid the whole enqueue, if we detect the deadlock right away\n(A-A). It\u0027s an optimization, but also prevents that another waiter who\ncomes in after the detection and before the task has undone the damage\nobserves the situation and detects the deadlock and returns\n-EDEADLOCK, which is wrong as the other task is not in a deadlock\nsituation.\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nReviewed-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nLink: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.de\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Mike Galbraith \u003cumgwanakikbuti@gmail.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "bf09db97205d46b3e083582eb2799aedddd9953b",
      "tree": "a56ddb942afc72096dc4b53c725f603d841d2ccb",
      "parents": [
        "fa1bd9b16b3432bce7937a5a4b5d75ab2f5b634c"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Tue Jun 24 23:50:09 2014 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jul 17 15:39:50 2014 -0700"
      },
      "message": "tracing: Remove ftrace_stop/start() from reading the trace file\n\ncommit 099ed151675cd1d2dbeae1dac697975f6a68716d upstream.\n\nDisabling reading and writing to the trace file should not be able to\ndisable all function tracing callbacks. There\u0027s other users today\n(like kprobes and perf). Reading a trace file should not stop those\nfrom happening.\n\nReviewed-by: Masami Hiramatsu \u003cmasami.hiramatsu.pt@hitachi.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "f54e04114e99817aae34261901fa5b54e6e2c336",
      "tree": "50371f4b87102e0b22d4c5e0b40428348941b2d0",
      "parents": [
        "d06191b3d67e11142db2d601a8393535e58de5e3"
      ],
      "author": {
        "name": "Gu Zheng",
        "email": "guz.fnst@cn.fujitsu.com",
        "time": "Wed Jun 25 09:57:18 2014 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jul 17 15:39:49 2014 -0700"
      },
      "message": "cpuset,mempolicy: fix sleeping function called from invalid context\n\ncommit 391acf970d21219a2a5446282d3b20eace0c0d7a upstream.\n\nWhen runing with the kernel(3.15-rc7+), the follow bug occurs:\n[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586\n[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python\n[ 9969.441175] INFO: lockdep is turned off.\n[ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G       A      3.15.0-rc7+ #85\n[ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012\n[ 9969.706052]  ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18\n[ 9969.795323]  ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c\n[ 9969.884710]  ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000\n[ 9969.974071] Call Trace:\n[ 9970.003403]  [\u003cffffffff8162f523\u003e] dump_stack+0x4d/0x66\n[ 9970.065074]  [\u003cffffffff8109995a\u003e] __might_sleep+0xfa/0x130\n[ 9970.130743]  [\u003cffffffff81633e6c\u003e] mutex_lock_nested+0x3c/0x4f0\n[ 9970.200638]  [\u003cffffffff811ba5dc\u003e] ? kmem_cache_alloc+0x1bc/0x210\n[ 9970.272610]  [\u003cffffffff81105807\u003e] cpuset_mems_allowed+0x27/0x140\n[ 9970.344584]  [\u003cffffffff811b1303\u003e] ? __mpol_dup+0x63/0x150\n[ 9970.409282]  [\u003cffffffff811b1385\u003e] __mpol_dup+0xe5/0x150\n[ 9970.471897]  [\u003cffffffff811b1303\u003e] ? __mpol_dup+0x63/0x150\n[ 9970.536585]  [\u003cffffffff81068c86\u003e] ? copy_process.part.23+0x606/0x1d40\n[ 9970.613763]  [\u003cffffffff810bf28d\u003e] ? trace_hardirqs_on+0xd/0x10\n[ 9970.683660]  [\u003cffffffff810ddddf\u003e] ? monotonic_to_bootbased+0x2f/0x50\n[ 9970.759795]  [\u003cffffffff81068cf0\u003e] copy_process.part.23+0x670/0x1d40\n[ 9970.834885]  [\u003cffffffff8106a598\u003e] do_fork+0xd8/0x380\n[ 9970.894375]  [\u003cffffffff81110e4c\u003e] ? __audit_syscall_entry+0x9c/0xf0\n[ 9970.969470]  [\u003cffffffff8106a8c6\u003e] SyS_clone+0x16/0x20\n[ 9971.030011]  [\u003cffffffff81642009\u003e] stub_clone+0x69/0x90\n[ 9971.091573]  [\u003cffffffff81641c29\u003e] ? system_call_fastpath+0x16/0x1b\n\nThe cause is that cpuset_mems_allowed() try to take\nmutex_lock(\u0026callback_mutex) under the rcu_read_lock(which was hold in\n__mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is\nunder rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock\nprotection region to protect the access to cpuset only in\ncurrent_cpuset_is_being_rebound(). So that we can avoid this bug.\n\nThis patch is a temporary solution that just addresses the bug\nmentioned above, can not fix the long-standing issue about cpuset.mems\nrebinding on fork():\n\n\"When the forker\u0027s task_struct is duplicated (which includes\n -\u003emems_allowed) and it races with an update to cpuset_being_rebound\n in update_tasks_nodemask() then the task\u0027s mems_allowed doesn\u0027t get\n updated. And the child task\u0027s mems_allowed can be wrong if the\n cpuset\u0027s nodemask changes before the child has been added to the\n cgroup\u0027s tasklist.\"\n\nSigned-off-by: Gu Zheng \u003cguz.fnst@cn.fujitsu.com\u003e\nAcked-by: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "0c3351a0a4815ea566d3febf82033b6c55ed4a2d",
      "tree": "6aaeb576ba3bda684481e2ca0d4b185b7b0ff6a6",
      "parents": [
        "e3293b8639a90b7227be9c273af0a45015c499bb"
      ],
      "author": {
        "name": "Oleg Nesterov",
        "email": "oleg@redhat.com",
        "time": "Sun Apr 13 20:58:54 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sun Jul 06 18:49:20 2014 -0700"
      },
      "message": "tracing: Fix syscall_*regfunc() vs copy_process() race\n\ncommit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.\n\nsyscall_regfunc() and syscall_unregfunc() should set/clear\nTIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race\nwith copy_process() and miss the new child which was not added to\nthe process/thread lists yet.\n\nChange copy_process() to update the child\u0027s TIF_SYSCALL_TRACEPOINT\nunder tasklist.\n\nLink: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com\n\nFixes: a871bd33a6c0 \"tracing: Add syscall tracepoints\"\nAcked-by: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nAcked-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Oleg Nesterov \u003coleg@redhat.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "a97df3f22b83742deb9191d53928641ec3befb6e",
      "tree": "c34f984ed3c4f844aeb3b2076148d2f334e5b134",
      "parents": [
        "1d48df4863c4a4d40809575efa1f101b1e8090b5"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Thu Mar 07 14:53:45 2013 +0100"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Jun 30 20:01:33 2014 -0700"
      },
      "message": "genirq: Sanitize spurious interrupt detection of threaded irqs\n\ncommit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream.\n\nTill reported that the spurious interrupt detection of threaded\ninterrupts is broken in two ways:\n\n- note_interrupt() is called for each action thread of a shared\n  interrupt line. That\u0027s wrong as we are only interested whether none\n  of the device drivers felt responsible for the interrupt, but by\n  calling multiple times for a single interrupt line we account\n  IRQ_NONE even if one of the drivers felt responsible.\n\n- note_interrupt() when called from the thread handler is not\n  serialized. That leaves the members of irq_desc which are used for\n  the spurious detection unprotected.\n\nTo solve this we need to defer the spurious detection of a threaded\ninterrupt to the next hardware interrupt context where we have\nimplicit serialization.\n\nIf note_interrupt is called with action_ret \u003d\u003d IRQ_WAKE_THREAD, we\ncheck whether the previous interrupt requested a deferred check. If\nnot, we request a deferred check for the next hardware interrupt and\nreturn.\n\nIf set, we check whether one of the interrupt threads signaled\nsuccess. Depending on this information we feed the result into the\nspurious detector.\n\nIf one primary handler of a shared interrupt returns IRQ_HANDLED we\ndisable the deferred check of irq threads on the same line, as we have\nfound at least one device driver who cared.\n\nReported-by: Till Straumann \u003cstrauman@slac.stanford.edu\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nTested-by: Austin Schuh \u003caustin@peloton-tech.com\u003e\nCc: Oliver Hartkopp \u003csocketcan@hartkopp.net\u003e\nCc: Wolfgang Grandegger \u003cwg@grandegger.com\u003e\nCc: Pavel Pisa \u003cpisa@cmp.felk.cvut.cz\u003e\nCc: Marc Kleine-Budde \u003cmkl@pengutronix.de\u003e\nCc: linux-can@vger.kernel.org\nLink: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "3f8f4ae48f4023e1c53722b1dc1a7ab897cbca14",
      "tree": "2677e4c998e385b214a5a04f09343133b2ebc8be",
      "parents": [
        "7be9d6cd4b57ebd5b344e4a006c0aa6e7a08aba3"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Fri Nov 29 12:18:13 2013 +0100"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Jun 26 15:10:29 2014 -0400"
      },
      "message": "nohz: Fix another inconsistency between CONFIG_NO_HZ\u003dn and nohz\u003doff\n\ncommit 0e576acbc1d9600cf2d9b4a141a2554639959d50 upstream.\n\nIf CONFIG_NO_HZ\u003dn tick_nohz_get_sleep_length() returns NSEC_PER_SEC/HZ.\n\nIf CONFIG_NO_HZ\u003dy and the nohz functionality is disabled via the\ncommand line option \"nohz\u003doff\" or not enabled due to missing hardware\nsupport, then tick_nohz_get_sleep_length() returns 0. That happens\nbecause ts-\u003esleep_length is never set in that case.\n\nSet it to NSEC_PER_SEC/HZ when the NOHZ mode is inactive.\n\nReported-by: Michal Hocko \u003cmhocko@suse.cz\u003e\nReported-by: Borislav Petkov \u003cbp@alien8.de\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Rui Xiang \u003crui.xiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "39da9a416814e556060bab8569293b8f3d889765",
      "tree": "47e6e9dc9b64c873e31bd67dfe4d9ecdfb81ea98",
      "parents": [
        "35a2bae84d5bc0a6609134b51053f78d235940c2"
      ],
      "author": {
        "name": "Andy Lutomirski",
        "email": "luto@amacapital.net",
        "time": "Wed May 28 23:09:58 2014 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Jun 16 13:45:46 2014 -0700"
      },
      "message": "auditsc: audit_krule mask accesses need bounds checking\n\ncommit a3c54931199565930d6d84f4c3456f6440aefd41 upstream.\n\nFixes an easy DoS and possible information disclosure.\n\nThis does nothing about the broken state of x32 auditing.\n\neparis: If the admin has enabled auditd and has specifically loaded\naudit rules.  This bug has been around since before git.  Wow...\n\nSigned-off-by: Andy Lutomirski \u003cluto@amacapital.net\u003e\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "d6e81d4f7b4e8cea2817c7568e3756798cd29aae",
      "tree": "0f9ff9d27bcba2a3278122bb4834a33a4da02266",
      "parents": [
        "ee40d72c3e6fc7e6cd5241eb84fa104b61dc8ec3"
      ],
      "author": {
        "name": "Lai Jiangshan",
        "email": "laijs@cn.fujitsu.com",
        "time": "Fri May 16 11:50:42 2014 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jun 11 12:04:11 2014 -0700"
      },
      "message": "sched: Fix hotplug vs. set_cpus_allowed_ptr()\n\ncommit 6acbfb96976fc3350e30d964acb1dbbdf876d55e upstream.\n\nLai found that:\n\n  WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124 native_smp_send_reschedule+0x2d/0x4b()\n  ...\n  migration_cpu_stop+0x1d/0x22\n\nwas caused by set_cpus_allowed_ptr() assuming that cpu_active_mask is\nalways a sub-set of cpu_online_mask.\n\nThis isn\u0027t true since 5fbd036b552f (\"sched: Cleanup cpu_active madness\").\n\nSo set active and online at the same time to avoid this particular\nproblem.\n\nFixes: 5fbd036b552f (\"sched: Cleanup cpu_active madness\")\nSigned-off-by: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nCc: Gautham R. Shenoy \u003cego@linux.vnet.ibm.com\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nCc: Michael wang \u003cwangyun@linux.vnet.ibm.com\u003e\nCc: Paul Gortmaker \u003cpaul.gortmaker@windriver.com\u003e\nCc: Rafael J. Wysocki \u003crafael.j.wysocki@intel.com\u003e\nCc: Srivatsa S. Bhat \u003csrivatsa.bhat@linux.vnet.ibm.com\u003e\nCc: Toshi Kani \u003ctoshi.kani@hp.com\u003e\nLink: http://lkml.kernel.org/r/53758B12.8060609@cn.fujitsu.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "4b2cfc9508d9e509708f85748548e03db696dbcd",
      "tree": "1c3f251ef8073234984c334c59993e7b4c3b26db",
      "parents": [
        "183f99ecb6a484c142ae2fc99df3ef5cdadc3985"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "peterz@infradead.org",
        "time": "Fri May 02 16:56:01 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jun 11 12:04:11 2014 -0700"
      },
      "message": "perf: Fix race in removing an event\n\ncommit 46ce0fe97a6be7532ce6126bb26ce89fed81528c upstream.\n\nWhen removing a (sibling) event we do:\n\n\traw_spin_lock_irq(\u0026ctx-\u003elock);\n\tperf_group_detach(event);\n\traw_spin_unlock_irq(\u0026ctx-\u003elock);\n\n\t\u003chole\u003e\n\n\tperf_remove_from_context(event);\n\t\traw_spin_lock_irq(\u0026ctx-\u003elock);\n\t\t...\n\t\traw_spin_unlock_irq(\u0026ctx-\u003elock);\n\nNow, assuming the event is a sibling, it will be \u0027unreachable\u0027 for\nthings like ctx_sched_out() because that iterates the\ngroups-\u003esiblings, and we just unhooked the sibling.\n\nSo, if during \u003chole\u003e we get ctx_sched_out(), it will miss the event\nand not call event_sched_out() on it, leaving it programmed on the\nPMU.\n\nThe subsequent perf_remove_from_context() call will find the ctx is\ninactive and only call list_del_event() to remove the event from all\nother lists.\n\nHereafter we can proceed to free the event; while still programmed!\n\nClose this hole by moving perf_group_detach() inside the same\nctx-\u003elock region(s) perf_remove_from_context() has.\n\nThe condition on inherited events only in __perf_event_exit_task() is\nlikely complete crap because non-inherited events are part of groups\ntoo and we\u0027re tearing down just the same. But leave that for another\npatch.\n\nMost-likely-Fixes: e03a9a55b4e (\"perf: Change close() semantics for group events\")\nReported-by: Vince Weaver \u003cvincent.weaver@maine.edu\u003e\nTested-by: Vince Weaver \u003cvincent.weaver@maine.edu\u003e\nMuch-staring-at-traces-by: Vince Weaver \u003cvincent.weaver@maine.edu\u003e\nMuch-staring-at-traces-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Arnaldo Carvalho de Melo \u003cacme@kernel.org\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/20140505093124.GN17778@laptop.programming.kicks-ass.net\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "183f99ecb6a484c142ae2fc99df3ef5cdadc3985",
      "tree": "3058cc15bf054797ee4e2b64390b85563a627072",
      "parents": [
        "0d41f6026aa0c15d60e75f8f71f1408c32fe1ba4"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "peterz@infradead.org",
        "time": "Thu May 15 20:23:48 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jun 11 12:04:11 2014 -0700"
      },
      "message": "perf: Limit perf_event_attr::sample_period to 63 bits\n\ncommit 0819b2e30ccb93edf04876237b6205eef84ec8d2 upstream.\n\nVince reported that using a large sample_period (one with bit 63 set)\nresults in wreckage since while the sample_period is fundamentally\nunsigned (negative periods don\u0027t make sense) the way we implement\nthings very much rely on signed logic.\n\nSo limit sample_period to 63 bits to avoid tripping over this.\n\nReported-by: Vince Weaver \u003cvincent.weaver@maine.edu\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/n/tip-p25fhunibl4y3qi0zuqmyf4b@git.kernel.org\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "0d41f6026aa0c15d60e75f8f71f1408c32fe1ba4",
      "tree": "1e398bd28e5334c5074a97939a672c168f6d7168",
      "parents": [
        "4e0d105c09b8bec501ff5455b774bf3a845d017c"
      ],
      "author": {
        "name": "Jiri Olsa",
        "email": "jolsa@redhat.com",
        "time": "Mon Apr 07 11:04:08 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jun 11 12:04:10 2014 -0700"
      },
      "message": "perf: Prevent false warning in perf_swevent_add\n\ncommit 39af6b1678afa5880dda7e375cf3f9d395087f6d upstream.\n\nThe perf cpu offline callback takes down all cpu context\nevents and releases swhash-\u003eswevent_hlist.\n\nThis could race with task context software event being just\nscheduled on this cpu via perf_swevent_add while cpu hotplug\ncode already cleaned up event\u0027s data.\n\nThe race happens in the gap between the cpu notifier code\nand the cpu being actually taken down. Note that only cpu\nctx events are terminated in the perf cpu hotplug code.\n\nIt\u0027s easily reproduced with:\n  $ perf record -e faults perf bench sched pipe\n\nwhile putting one of the cpus offline:\n  # echo 0 \u003e /sys/devices/system/cpu/cpu1/online\n\nConsole emits following warning:\n  WARNING: CPU: 1 PID: 2845 at kernel/events/core.c:5672 perf_swevent_add+0x18d/0x1a0()\n  Modules linked in:\n  CPU: 1 PID: 2845 Comm: sched-pipe Tainted: G        W    3.14.0+ #256\n  Hardware name: Intel Corporation Montevina platform/To be filled by O.E.M., BIOS AMVACRB1.86C.0066.B00.0805070703 05/07/2008\n   0000000000000009 ffff880077233ab8 ffffffff81665a23 0000000000200005\n   0000000000000000 ffff880077233af8 ffffffff8104732c 0000000000000046\n   ffff88007467c800 0000000000000002 ffff88007a9cf2a0 0000000000000001\n  Call Trace:\n   [\u003cffffffff81665a23\u003e] dump_stack+0x4f/0x7c\n   [\u003cffffffff8104732c\u003e] warn_slowpath_common+0x8c/0xc0\n   [\u003cffffffff8104737a\u003e] warn_slowpath_null+0x1a/0x20\n   [\u003cffffffff8110fb3d\u003e] perf_swevent_add+0x18d/0x1a0\n   [\u003cffffffff811162ae\u003e] event_sched_in.isra.75+0x9e/0x1f0\n   [\u003cffffffff8111646a\u003e] group_sched_in+0x6a/0x1f0\n   [\u003cffffffff81083dd5\u003e] ? sched_clock_local+0x25/0xa0\n   [\u003cffffffff811167e6\u003e] ctx_sched_in+0x1f6/0x450\n   [\u003cffffffff8111757b\u003e] perf_event_sched_in+0x6b/0xa0\n   [\u003cffffffff81117a4b\u003e] perf_event_context_sched_in+0x7b/0xc0\n   [\u003cffffffff81117ece\u003e] __perf_event_task_sched_in+0x43e/0x460\n   [\u003cffffffff81096f1e\u003e] ? put_lock_stats.isra.18+0xe/0x30\n   [\u003cffffffff8107b3c8\u003e] finish_task_switch+0xb8/0x100\n   [\u003cffffffff8166a7de\u003e] __schedule+0x30e/0xad0\n   [\u003cffffffff81172dd2\u003e] ? pipe_read+0x3e2/0x560\n   [\u003cffffffff8166b45e\u003e] ? preempt_schedule_irq+0x3e/0x70\n   [\u003cffffffff8166b45e\u003e] ? preempt_schedule_irq+0x3e/0x70\n   [\u003cffffffff8166b464\u003e] preempt_schedule_irq+0x44/0x70\n   [\u003cffffffff816707f0\u003e] retint_kernel+0x20/0x30\n   [\u003cffffffff8109e60a\u003e] ? lockdep_sys_exit+0x1a/0x90\n   [\u003cffffffff812a4234\u003e] lockdep_sys_exit_thunk+0x35/0x67\n   [\u003cffffffff81679321\u003e] ? sysret_check+0x5/0x56\n\nFixing this by tracking the cpu hotplug state and displaying\nthe WARN only if current cpu is initialized properly.\n\nCc: Corey Ashford \u003ccjashfor@linux.vnet.ibm.com\u003e\nCc: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Paul Mackerras \u003cpaulus@samba.org\u003e\nCc: Arnaldo Carvalho de Melo \u003cacme@redhat.com\u003e\nReported-by: Fengguang Wu \u003cfengguang.wu@intel.com\u003e\nSigned-off-by: Jiri Olsa \u003cjolsa@redhat.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/1396861448-10097-1-git-send-email-jolsa@redhat.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "4e0d105c09b8bec501ff5455b774bf3a845d017c",
      "tree": "2f40d878516c7293b85309c34e3caf78cd652465",
      "parents": [
        "22feaed11f1b0c58aab5df196c0bf011e7095a62"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Sun Apr 13 09:34:53 2014 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jun 11 12:04:10 2014 -0700"
      },
      "message": "sched: Use CPUPRI_NR_PRIORITIES instead of MAX_RT_PRIO in cpupri check\n\ncommit 6227cb00cc120f9a43ce8313bb0475ddabcb7d01 upstream.\n\nThe check at the beginning of cpupri_find() makes sure that the task_pri\nvariable does not exceed the cp-\u003epri_to_cpu array length. But that length\nis CPUPRI_NR_PRIORITIES not MAX_RT_PRIO, where it will miss the last two\npriorities in that array.\n\nAs task_pri is computed from convert_prio() which should never be bigger\nthan CPUPRI_NR_PRIORITIES, if the check should cause a panic if it is\nhit.\n\nReported-by: Mike Galbraith \u003cumgwanakikbuti@gmail.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/1397015410.5212.13.camel@marge.simpson.net\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "11b9a7a786232e811cbe988543cb83b5ff1a829c",
      "tree": "c88cd9cb8e97f103f4a03d3469a112bc26533f6a",
      "parents": [
        "a8f96abb1a78f16c498cb1e03386cc1a7b55a28c"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Tue Jun 03 12:27:08 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:16 2014 -0700"
      },
      "message": "futex: Make lookup_pi_state more robust\n\ncommit 54a217887a7b658e2650c3feff22756ab80c7339 upstream.\n\nThe current implementation of lookup_pi_state has ambigous handling of\nthe TID value 0 in the user space futex.  We can get into the kernel\neven if the TID value is 0, because either there is a stale waiters bit\nor the owner died bit is set or we are called from the requeue_pi path\nor from user space just for fun.\n\nThe current code avoids an explicit sanity check for pid \u003d 0 in case\nthat kernel internal state (waiters) are found for the user space\naddress.  This can lead to state leakage and worse under some\ncircumstances.\n\nHandle the cases explicit:\n\n       Waiter | pi_state | pi-\u003eowner | uTID      | uODIED | ?\n\n  [1]  NULL   | ---      | ---       | 0         | 0/1    | Valid\n  [2]  NULL   | ---      | ---       | \u003e0        | 0/1    | Valid\n\n  [3]  Found  | NULL     | --        | Any       | 0/1    | Invalid\n\n  [4]  Found  | Found    | NULL      | 0         | 1      | Valid\n  [5]  Found  | Found    | NULL      | \u003e0        | 1      | Invalid\n\n  [6]  Found  | Found    | task      | 0         | 1      | Valid\n\n  [7]  Found  | Found    | NULL      | Any       | 0      | Invalid\n\n  [8]  Found  | Found    | task      | \u003d\u003dtaskTID | 0/1    | Valid\n  [9]  Found  | Found    | task      | 0         | 0      | Invalid\n  [10] Found  | Found    | task      | !\u003dtaskTID | 0/1    | Invalid\n\n [1] Indicates that the kernel can acquire the futex atomically. We\n     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.\n\n [2] Valid, if TID does not belong to a kernel thread. If no matching\n     thread is found then it indicates that the owner TID has died.\n\n [3] Invalid. The waiter is queued on a non PI futex\n\n [4] Valid state after exit_robust_list(), which sets the user space\n     value to FUTEX_WAITERS | FUTEX_OWNER_DIED.\n\n [5] The user space value got manipulated between exit_robust_list()\n     and exit_pi_state_list()\n\n [6] Valid state after exit_pi_state_list() which sets the new owner in\n     the pi_state but cannot access the user space value.\n\n [7] pi_state-\u003eowner can only be NULL when the OWNER_DIED bit is set.\n\n [8] Owner and user space value match\n\n [9] There is no transient state which sets the user space TID to 0\n     except exit_robust_list(), but this is indicated by the\n     FUTEX_OWNER_DIED bit. See [4]\n\n[10] There is no transient state which leaves owner and user space\n     TID out of sync.\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Kees Cook \u003ckeescook@chromium.org\u003e\nCc: Will Drewry \u003cwad@chromium.org\u003e\nCc: Darren Hart \u003cdvhart@linux.intel.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "a8f96abb1a78f16c498cb1e03386cc1a7b55a28c",
      "tree": "07c243177c4c43656c451c3a096a234d19ab5a02",
      "parents": [
        "2397889b03ef0f394e176b86ba37c421a01a9c89"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Tue Jun 03 12:27:07 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:16 2014 -0700"
      },
      "message": "futex: Always cleanup owner tid in unlock_pi\n\ncommit 13fbca4c6ecd96ec1a1cfa2e4f2ce191fe928a5e upstream.\n\nIf the owner died bit is set at futex_unlock_pi, we currently do not\ncleanup the user space futex.  So the owner TID of the current owner\n(the unlocker) persists.  That\u0027s observable inconsistant state,\nespecially when the ownership of the pi state got transferred.\n\nClean it up unconditionally.\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Kees Cook \u003ckeescook@chromium.org\u003e\nCc: Will Drewry \u003cwad@chromium.org\u003e\nCc: Darren Hart \u003cdvhart@linux.intel.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "2397889b03ef0f394e176b86ba37c421a01a9c89",
      "tree": "8596328ecedce75375bb3c51c671c3bb8d340bb7",
      "parents": [
        "4cca4db7bd5fb663660da34a3514d9fa8f5f14f3"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Tue Jun 03 12:27:06 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:16 2014 -0700"
      },
      "message": "futex: Validate atomic acquisition in futex_lock_pi_atomic()\n\ncommit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 upstream.\n\nWe need to protect the atomic acquisition in the kernel against rogue\nuser space which sets the user space futex to 0, so the kernel side\nacquisition succeeds while there is existing state in the kernel\nassociated to the real owner.\n\nVerify whether the futex has waiters associated with kernel state.  If\nit has, return -EINVAL.  The state is corrupted already, so no point in\ncleaning it up.  Subsequent calls will fail as well.  Not our problem.\n\n[ tglx: Use futex_top_waiter() and explain why we do not need to try\n  \trestoring the already corrupted user space state. ]\n\nSigned-off-by: Darren Hart \u003cdvhart@linux.intel.com\u003e\nCc: Kees Cook \u003ckeescook@chromium.org\u003e\nCc: Will Drewry \u003cwad@chromium.org\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "4cca4db7bd5fb663660da34a3514d9fa8f5f14f3",
      "tree": "31514f38e1694d440f616b23b91ac9686bbc91ed",
      "parents": [
        "c6f9d698ffd5cfbb941177bec02b43542c748d77"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Tue Jun 03 12:27:06 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:16 2014 -0700"
      },
      "message": "futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr \u003d\u003d uaddr2 in futex_requeue(..., requeue_pi\u003d1)\n\ncommit e9c243a5a6de0be8e584c604d353412584b592f8 upstream.\n\nIf uaddr \u003d\u003d uaddr2, then we have broken the rule of only requeueing from\na non-pi futex to a pi futex with this call.  If we attempt this, then\ndangling pointers may be left for rt_waiter resulting in an exploitable\ncondition.\n\nThis change brings futex_requeue() in line with futex_wait_requeue_pi()\nwhich performs the same check as per commit 6f7b0a2a5c0f (\"futex: Forbid\nuaddr \u003d\u003d uaddr2 in futex_wait_requeue_pi()\")\n\n[ tglx: Compare the resulting keys as well, as uaddrs might be\n  \tdifferent depending on the mapping ]\n\nFixes CVE-2014-3153.\n\nReported-by: Pinkie Pie\nSigned-off-by: Will Drewry \u003cwad@chromium.org\u003e\nSigned-off-by: Kees Cook \u003ckeescook@chromium.org\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nReviewed-by: Darren Hart \u003cdvhart@linux.intel.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "4652951d1202cef2798b1a0dfbf4122794594b41",
      "tree": "0c6dd14b186e021355bbb59166237711b97bf767",
      "parents": [
        "926685e95e4d6518110794b77676b3bb7f9c4be0"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Thu Mar 14 14:20:54 2013 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:04 2014 -0700"
      },
      "message": "tracing: Keep overwrite in sync between regular and snapshot buffers\n\ncommit 80902822658aab18330569587cdb69ac1dfdcea8 upstream.\n\nChanging the overwrite mode for the ring buffer via the trace\noption only sets the normal buffer. But the snapshot buffer could\nswap with it, and then the snapshot would be in non overwrite mode\nand the normal buffer would be in overwrite mode, even though the\noption flag states otherwise.\n\nKeep the two buffers overwrite modes in sync.\n\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Rui Xiang \u003crui.xiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "926685e95e4d6518110794b77676b3bb7f9c4be0",
      "tree": "ab75d5532a97420774499be869f05331e45d7e17",
      "parents": [
        "e5f1ec5d39f6d59bfe5c53f4b28a94e3a4245e02"
      ],
      "author": {
        "name": "Wei Yongjun",
        "email": "yongjun_wei@trendmicro.com.cn",
        "time": "Fri Apr 12 11:05:54 2013 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:04 2014 -0700"
      },
      "message": "perf: Fix error return code\n\ncommit c481420248c6730246d2a1b1773d5d7007ae0835 upstream.\n\nFix to return -ENOMEM in the allocation error case instead of 0\n(if pmu_bus_running \u003d\u003d 1), as done elsewhere in this function.\n\nSigned-off-by: Wei Yongjun \u003cyongjun_wei@trendmicro.com.cn\u003e\nCc: a.p.zijlstra@chello.nl\nCc: paulus@samba.org\nCc: acme@ghostprotocols.net\nLink: http://lkml.kernel.org/r/CAPgLHd8j_fWcgqe%3DKLWjpBj%2B%3Do0Pw6Z-SEq%3DNTPU08c2w1tngQ@mail.gmail.com\n[ Tweaked the error code setting placement and the changelog. ]\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Rui Xiang \u003crui.xiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "e5f1ec5d39f6d59bfe5c53f4b28a94e3a4245e02",
      "tree": "72a98a486d26d757ef26ed5e6ccf25726d7b90ce",
      "parents": [
        "4aff95ab8f985d14f585187b5f78c65a56dd716b"
      ],
      "author": {
        "name": "libin",
        "email": "huawei.libin@huawei.com",
        "time": "Mon Apr 08 14:39:12 2013 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:04 2014 -0700"
      },
      "message": "sched/debug: Fix sd-\u003e*_idx limit range avoiding overflow\n\ncommit fd9b86d37a600488dbd80fe60cca46b822bff1cd upstream.\n\nCommit 201c373e8e (\"sched/debug: Limit sd-\u003e*_idx range on\nsysctl\") was an incomplete bug fix.\n\nThis patch fixes sd-\u003e*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX-1]\navoiding array overflow caused by setting sd-\u003e*_idx to CPU_LOAD_IDX_MAX\non sysctl.\n\nSigned-off-by: Libin \u003chuawei.libin@huawei.com\u003e\nCc: \u003cjiang.liu@huawei.com\u003e\nCc: \u003cguohanjun@huawei.com\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/51626610.2040607@huawei.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Rui Xiang \u003crui.xiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "4aff95ab8f985d14f585187b5f78c65a56dd716b",
      "tree": "a009a89d60863d3681042a21b496c08758636b78",
      "parents": [
        "74d86ed74b4ddf37de24a9ad979a8aafd2d4c25f"
      ],
      "author": {
        "name": "Namhyung Kim",
        "email": "namhyung.kim@lge.com",
        "time": "Thu Aug 16 17:03:24 2012 +0900"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:04 2014 -0700"
      },
      "message": "sched/debug: Limit sd-\u003e*_idx range on sysctl\n\ncommit 201c373e8e4823700d3160d5c28e1ab18fd1193e upstream.\n\nVarious sd-\u003e*_idx\u0027s are used for refering the rq\u0027s load average table\nwhen selecting a cpu to run.  However they can be set to any number\nwith sysctl knobs so that it can crash the kernel if something bad is\ngiven. Fix it by limiting them into the actual range.\n\nSigned-off-by: Namhyung Kim \u003cnamhyung@kernel.org\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLink: http://lkml.kernel.org/r/1345104204-8317-1-git-send-email-namhyung@kernel.org\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Rui Xiang \u003crui.xiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "74d86ed74b4ddf37de24a9ad979a8aafd2d4c25f",
      "tree": "320a1abfe9bf227ea4d9e10e60f534f9de8c3cb9",
      "parents": [
        "1fbbea7be9248d652fc2bb191e6ec9e823df422c"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Tue Jul 30 00:04:32 2013 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:04 2014 -0700"
      },
      "message": "ftrace: Check module functions being traced on reload\n\ncommit 8c4f3c3fa9681dc549cd35419b259496082fef8b upstream.\n\nThere\u0027s been a nasty bug that would show up and not give much info.\nThe bug displayed the following warning:\n\n WARNING: at kernel/trace/ftrace.c:1529 __ftrace_hash_rec_update+0x1e3/0x230()\n Pid: 20903, comm: bash Tainted: G           O 3.6.11+ #38405.trunk\n Call Trace:\n  [\u003cffffffff8103e5ff\u003e] warn_slowpath_common+0x7f/0xc0\n  [\u003cffffffff8103e65a\u003e] warn_slowpath_null+0x1a/0x20\n  [\u003cffffffff810c2ee3\u003e] __ftrace_hash_rec_update+0x1e3/0x230\n  [\u003cffffffff810c4f28\u003e] ftrace_hash_move+0x28/0x1d0\n  [\u003cffffffff811401cc\u003e] ? kfree+0x2c/0x110\n  [\u003cffffffff810c68ee\u003e] ftrace_regex_release+0x8e/0x150\n  [\u003cffffffff81149f1e\u003e] __fput+0xae/0x220\n  [\u003cffffffff8114a09e\u003e] ____fput+0xe/0x10\n  [\u003cffffffff8105fa22\u003e] task_work_run+0x72/0x90\n  [\u003cffffffff810028ec\u003e] do_notify_resume+0x6c/0xc0\n  [\u003cffffffff8126596e\u003e] ? trace_hardirqs_on_thunk+0x3a/0x3c\n  [\u003cffffffff815c0f88\u003e] int_signal+0x12/0x17\n ---[ end trace 793179526ee09b2c ]---\n\nIt was finally narrowed down to unloading a module that was being traced.\n\nIt was actually more than that. When functions are being traced, there\u0027s\na table of all functions that have a ref count of the number of active\ntracers attached to that function. When a function trace callback is\nregistered to a function, the function\u0027s record ref count is incremented.\nWhen it is unregistered, the function\u0027s record ref count is decremented.\nIf an inconsistency is detected (ref count goes below zero) the above\nwarning is shown and the function tracing is permanently disabled until\nreboot.\n\nThe ftrace callback ops holds a hash of functions that it filters on\n(and/or filters off). If the hash is empty, the default means to filter\nall functions (for the filter_hash) or to disable no functions (for the\nnotrace_hash).\n\nWhen a module is unloaded, it frees the function records that represent\nthe module functions. These records exist on their own pages, that is\nfunction records for one module will not exist on the same page as\nfunction records for other modules or even the core kernel.\n\nNow when a module unloads, the records that represents its functions are\nfreed. When the module is loaded again, the records are recreated with\na default ref count of zero (unless there\u0027s a callback that traces all\nfunctions, then they will also be traced, and the ref count will be\nincremented).\n\nThe problem is that if an ftrace callback hash includes functions of the\nmodule being unloaded, those hash entries will not be removed. If the\nmodule is reloaded in the same location, the hash entries still point\nto the functions of the module but the module\u0027s ref counts do not reflect\nthat.\n\nWith the help of Steve and Joern, we found a reproducer:\n\n Using uinput module and uinput_release function.\n\n cd /sys/kernel/debug/tracing\n modprobe uinput\n echo uinput_release \u003e set_ftrace_filter\n echo function \u003e current_tracer\n rmmod uinput\n modprobe uinput\n # check /proc/modules to see if loaded in same addr, otherwise try again\n echo nop \u003e current_tracer\n\n [BOOM]\n\nThe above loads the uinput module, which creates a table of functions that\ncan be traced within the module.\n\nWe add uinput_release to the filter_hash to trace just that function.\n\nEnable function tracincg, which increments the ref count of the record\nassociated to uinput_release.\n\nRemove uinput, which frees the records including the one that represents\nuinput_release.\n\nLoad the uinput module again (and make sure it\u0027s at the same address).\nThis recreates the function records all with a ref count of zero,\nincluding uinput_release.\n\nDisable function tracing, which will decrement the ref count for uinput_release\nwhich is now zero because of the module removal and reload, and we have\na mismatch (below zero ref count).\n\nThe solution is to check all currently tracing ftrace callbacks to see if any\nare tracing any of the module\u0027s functions when a module is loaded (it already does\nthat with callbacks that trace all functions). If a callback happens to have\na module function being traced, it increments that records ref count and starts\ntracing that function.\n\nThere may be a strange side effect with this, where tracing module functions\non unload and then reloading a new module may have that new module\u0027s functions\nbeing traced. This may be something that confuses the user, but it\u0027s not\na big deal. Another approach is to disable all callback hashes on module unload,\nbut this leaves some ftrace callbacks that may not be registered, but can\nstill have hashes tracing the module\u0027s function where ftrace doesn\u0027t know about\nit. That situation can cause the same bug. This solution solves that case too.\nAnother benefit of this solution, is it is possible to trace a module\u0027s\nfunction on unload and load.\n\nLink: http://lkml.kernel.org/r/20130705142629.GA325@redhat.com\n\nReported-by: Jörn Engel \u003cjoern@logfs.org\u003e\nReported-by: Dave Jones \u003cdavej@redhat.com\u003e\nReported-by: Steve Hodgson \u003csteve@purestorage.com\u003e\nTested-by: Steve Hodgson \u003csteve@purestorage.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Rui Xiang \u003crui.xiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "1fbbea7be9248d652fc2bb191e6ec9e823df422c",
      "tree": "4daa4b37c31c09bdd68827752b46a52195a79f60",
      "parents": [
        "76504c2489ad9e9bdc20fc8e24d23ac5e39b88b6"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "peterz@infradead.org",
        "time": "Mon Oct 28 13:55:29 2013 +0100"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:04 2014 -0700"
      },
      "message": "perf: Fix perf ring buffer memory ordering\n\ncommit bf378d341e4873ed928dc3c636252e6895a21f50 upstream.\n\nThe PPC64 people noticed a missing memory barrier and crufty old\ncomments in the perf ring buffer code. So update all the comments and\nadd the missing barrier.\n\nWhen the architecture implements local_t using atomic_long_t there\nwill be double barriers issued; but short of introducing more\nconditional barrier primitives this is the best we can do.\n\nReported-by: Victor Kaplansky \u003cvictork@il.ibm.com\u003e\nTested-by: Victor Kaplansky \u003cvictork@il.ibm.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nCc: michael@ellerman.id.au\nCc: Paul McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nCc: Michael Neuling \u003cmikey@neuling.org\u003e\nCc: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nCc: anton@samba.org\nCc: benh@kernel.crashing.org\nLink: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lan\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\n[bwh: Backported to 3.2: adjust filename]\nSigned-off-by: Ben Hutchings \u003cben@decadent.org.uk\u003e\nCc: Rui Xiang \u003crui.xiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "11f87a6a6049455cd0d1e6db13c0b984a888a4b4",
      "tree": "36d4fb7786b3450b65f85e6d8c0910f53f7d08f8",
      "parents": [
        "a91ccfcaaaa358eba4579965d9a85dbb756c2596"
      ],
      "author": {
        "name": "Viresh Kumar",
        "email": "viresh.kumar@linaro.org",
        "time": "Mon May 12 13:42:29 2014 +0530"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:01 2014 -0700"
      },
      "message": "hrtimer: Set expiry time before switch_hrtimer_base()\n\ncommit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream.\n\nswitch_hrtimer_base() calls hrtimer_check_target() which ensures that\nwe do not migrate a timer to a remote cpu if the timer expires before\nthe current programmed expiry time on that remote cpu.\n\nBut __hrtimer_start_range_ns() calls switch_hrtimer_base() before the\nnew expiry time is set. So the sanity check in hrtimer_check_target()\nis operating on stale or even uninitialized data.\n\nUpdate expiry time before calling switch_hrtimer_base().\n\n[ tglx: Rewrote changelog once again ]\n\nSigned-off-by: Viresh Kumar \u003cviresh.kumar@linaro.org\u003e\nCc: linaro-kernel@lists.linaro.org\nCc: linaro-networking@linaro.org\nCc: fweisbec@gmail.com\nCc: arvind.chauhan@arm.com\nLink: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.1399882253.git.viresh.kumar@linaro.org\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "a91ccfcaaaa358eba4579965d9a85dbb756c2596",
      "tree": "c7232861d3241f50f6726b949419b3fba8e5ae87",
      "parents": [
        "3d8b2f5e4007d4b28ac760e1aa72e91f4021ea90"
      ],
      "author": {
        "name": "Leon Ma",
        "email": "xindong.ma@intel.com",
        "time": "Wed Apr 30 16:43:10 2014 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:01 2014 -0700"
      },
      "message": "hrtimer: Prevent remote enqueue of leftmost timers\n\ncommit 012a45e3f4af68e86d85cce060c6c2fed56498b2 upstream.\n\nIf a cpu is idle and starts an hrtimer which is not pinned on that\nsame cpu, the nohz code might target the timer to a different cpu.\n\nIn the case that we switch the cpu base of the timer we already have a\nsanity check in place, which determines whether the timer is earlier\nthan the current leftmost timer on the target cpu. In that case we\nenqueue the timer on the current cpu because we cannot reprogram the\nclock event device on the target.\n\nIf the timers base is already the target CPU we do not have this\nsanity check in place so we enqueue the timer as the leftmost timer in\nthe target cpus rb tree, but we cannot reprogram the clock event\ndevice on the target cpu. So the timer expires late and subsequently\nprevents the reprogramming of the target cpu clock event device until\nthe previously programmed event fires or a timer with an earlier\nexpiry time gets enqueued on the target cpu itself.\n\nAdd the same target check as we have for the switch base case and\nstart the timer on the current cpu if it would become the leftmost\ntimer on the target.\n\n[ tglx: Rewrote subject and changelog ]\n\nSigned-off-by: Leon Ma \u003cxindong.ma@intel.com\u003e\nLink: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "3d8b2f5e4007d4b28ac760e1aa72e91f4021ea90",
      "tree": "6b53e12b48f5f721ae7e66f8cd8de1e92b387f18",
      "parents": [
        "9dbdf25ec58ee67beee56e9bcc2f193ee29cc7b3"
      ],
      "author": {
        "name": "Stuart Hayes",
        "email": "stuart.w.hayes@gmail.com",
        "time": "Tue Apr 29 17:55:02 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:01 2014 -0700"
      },
      "message": "hrtimer: Prevent all reprogramming if hang detected\n\ncommit 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 upstream.\n\nIf the last hrtimer interrupt detected a hang it sets hang_detected\u003d1\nand programs the clock event device with a delay to let the system\nmake progress.\n\nIf hang_detected \u003d\u003d 1, we prevent reprogramming of the clock event\ndevice in hrtimer_reprogram() but not in hrtimer_force_reprogram().\n\nThis can lead to the following situation:\n\nhrtimer_interrupt()\n   hang_detected \u003d 1;\n   program ce device to Xms from now (hang delay)\n\nWe have two timers pending:\n   T1 expires 50ms from now\n   T2 expires 5s from now\n\nNow T1 gets canceled, which causes hrtimer_force_reprogram() to be\ninvoked, which in turn programs the clock event device to T2 (5\nseconds from now).\n\nAny hrtimer_start after that will not reprogram the hardware due to\nhang_detected still being set. So we effectivly block all timers until\nthe T2 event fires and cleans up the hang situation.\n\nAdd a check for hang_detected to hrtimer_force_reprogram() which\nprevents the reprogramming of the hang delay in the hardware\ntimer. The subsequent hrtimer_interrupt will resolve all outstanding\nissues.\n\n[ tglx: Rewrote subject and changelog and fixed up the comment in\n  \thrtimer_force_reprogram() ]\n\nSigned-off-by: Stuart Hayes \u003cstuart.w.hayes@gmail.com\u003e\nLink: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "11e69564f65b6c7a1089c5d45929714e3ed6a921",
      "tree": "455bbb4c582db9e54b9c06965caeab60a34c5ccc",
      "parents": [
        "3be2bb4956e5d9d849329d5d1b92f6510ac12315"
      ],
      "author": {
        "name": "Jiri Bohac",
        "email": "jbohac@suse.cz",
        "time": "Fri Apr 18 17:23:11 2014 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:00 2014 -0700"
      },
      "message": "timer: Prevent overflow in apply_slack\n\ncommit 98a01e779f3c66b0b11cd7e64d531c0e41c95762 upstream.\n\nOn architectures with sizeof(int) \u003c sizeof (long), the\ncomputation of mask inside apply_slack() can be undefined if the\ncomputed bit is \u003e 32.\n\nE.g. with: expires \u003d 0xffffe6f5 and slack \u003d 25, we get:\n\nexpires_limit \u003d 0x20000000e\nbit \u003d 33\nmask \u003d (1 \u003c\u003c 33) - 1  /* undefined */\n\nOn x86, mask becomes 1 and and the slack is not applied properly.\nOn s390, mask is -1, expires is set to 0 and the timer fires immediately.\n\nUse 1UL \u003c\u003c bit to solve that issue.\n\nSuggested-by: Deborah Townsend \u003cdstownse@us.ibm.com\u003e\nSigned-off-by: Jiri Bohac \u003cjbohac@suse.cz\u003e\nLink: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.cz\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "8f4c0e8b5438725d66c6c27f11cb2a1c61c6d6c5",
      "tree": "d417790dc59d960c950e83511df582551c029b91",
      "parents": [
        "6427aede5eaac2e39a1d2b3306d960a603d7c3d9"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Thu Apr 24 10:40:12 2014 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:00 2014 -0700"
      },
      "message": "ftrace/module: Hardcode ftrace_module_init() call into load_module()\n\ncommit a949ae560a511fe4e3adf48fa44fefded93e5c2b upstream.\n\nA race exists between module loading and enabling of function tracer.\n\n\tCPU 1\t\t\t\tCPU 2\n\t-----\t\t\t\t-----\n  load_module()\n   module-\u003estate \u003d MODULE_STATE_COMING\n\n\t\t\t\tregister_ftrace_function()\n\t\t\t\t mutex_lock(\u0026ftrace_lock);\n\t\t\t\t ftrace_startup()\n\t\t\t\t  update_ftrace_function();\n\t\t\t\t   ftrace_arch_code_modify_prepare()\n\t\t\t\t    set_all_module_text_rw();\n\t\t\t\t   \u003cenables-ftrace\u003e\n\t\t\t\t    ftrace_arch_code_modify_post_process()\n\t\t\t\t     set_all_module_text_ro();\n\n\t\t\t\t[ here all module text is set to RO,\n\t\t\t\t  including the module that is\n\t\t\t\t  loading!! ]\n\n   blocking_notifier_call_chain(MODULE_STATE_COMING);\n    ftrace_init_module()\n\n     [ tries to modify code, but it\u0027s RO, and fails!\n       ftrace_bug() is called]\n\nWhen this race happens, ftrace_bug() will produces a nasty warning and\nall of the function tracing features will be disabled until reboot.\n\nThe simple solution is to treate module load the same way the core\nkernel is treated at boot. To hardcode the ftrace function modification\nof converting calls to mcount into nops. This is done in init/main.c\nthere\u0027s no reason it could not be done in load_module(). This gives\na better control of the changes and doesn\u0027t tie the state of the\nmodule to its notifiers as much. Ftrace is special, it needs to be\ntreated as such.\n\nThe reason this would work, is that the ftrace_module_init() would be\ncalled while the module is in MODULE_STATE_UNFORMED, which is ignored\nby the set_all_module_text_ro() call.\n\nLink: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.com\n\nReported-by: Takao Indoh \u003cindou.takao@jp.fujitsu.com\u003e\nAcked-by: Rusty Russell \u003crusty@rustcorp.com.au\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "6427aede5eaac2e39a1d2b3306d960a603d7c3d9",
      "tree": "acbc0a7b38d6164aa34c82259eef8780a51ccf03",
      "parents": [
        "7bf0aee237176a3edcd054b80dba2dad3e2be7ff"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Mon May 12 20:45:35 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:00 2014 -0700"
      },
      "message": "futex: Prevent attaching to kernel threads\n\ncommit f0d71b3dcb8332f7971b5f2363632573e6d9486a upstream.\n\nWe happily allow userspace to declare a random kernel thread to be the\nowner of a user space PI futex.\n\nFound while analysing the fallout of Dave Jones syscall fuzzer.\n\nWe also should validate the thread group for private futexes and find\nsome fast way to validate whether the \"alleged\" owner has RW access on\nthe file which backs the SHM, but that\u0027s a separate issue.\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Dave Jones \u003cdavej@redhat.com\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Darren Hart \u003cdarren@dvhart.com\u003e\nCc: Davidlohr Bueso \u003cdavidlohr@hp.com\u003e\nCc: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Clark Williams \u003cwilliams@redhat.com\u003e\nCc: Paul McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nCc: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nCc: Roland McGrath \u003croland@hack.frob.com\u003e\nCc: Carlos ODonell \u003ccarlos@redhat.com\u003e\nCc: Jakub Jelinek \u003cjakub@redhat.com\u003e\nCc: Michael Kerrisk \u003cmtk.manpages@gmail.com\u003e\nCc: Sebastian Andrzej Siewior \u003cbigeasy@linutronix.de\u003e\nLink: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "7bf0aee237176a3edcd054b80dba2dad3e2be7ff",
      "tree": "13ea381ebc701d1c0004ace18980530d48e3c116",
      "parents": [
        "d16beab575e17e46a4b187fb9f8211fab3adfbae"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Mon May 12 20:45:34 2014 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:02:00 2014 -0700"
      },
      "message": "futex: Add another early deadlock detection check\n\ncommit 866293ee54227584ffcb4a42f69c1f365974ba7f upstream.\n\nDave Jones trinity syscall fuzzer exposed an issue in the deadlock\ndetection code of rtmutex:\n  http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com\n\nThat underlying issue has been fixed with a patch to the rtmutex code,\nbut the futex code must not call into rtmutex in that case because\n    - it can detect that issue early\n    - it avoids a different and more complex fixup for backing out\n\nIf the user space variable got manipulated to 0x80000000 which means\nno lock holder, but the waiters bit set and an active pi_state in the\nkernel is found we can figure out the recursive locking issue by\nlooking at the pi_state owner. If that is the current task, then we\ncan safely return -EDEADLK.\n\nThe check should have been added in commit 59fa62451 (futex: Handle\nfutex_pi OWNER_DIED take over correctly) already, but I did not see\nthe above issue caused by user space manipulation back then.\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Dave Jones \u003cdavej@redhat.com\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Darren Hart \u003cdarren@dvhart.com\u003e\nCc: Davidlohr Bueso \u003cdavidlohr@hp.com\u003e\nCc: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Clark Williams \u003cwilliams@redhat.com\u003e\nCc: Paul McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nCc: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nCc: Roland McGrath \u003croland@hack.frob.com\u003e\nCc: Carlos ODonell \u003ccarlos@redhat.com\u003e\nCc: Jakub Jelinek \u003cjakub@redhat.com\u003e\nCc: Michael Kerrisk \u003cmtk.manpages@gmail.com\u003e\nCc: Sebastian Andrzej Siewior \u003cbigeasy@linutronix.de\u003e\nLink: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "fce85b081c08c1326d9bcab0ff9ea1c85b7e9858",
      "tree": "b8dca480b76cecd52287d243766c84d52ade153e",
      "parents": [
        "ced68efe273377c2f525418da0b75f8d2d6d2402"
      ],
      "author": {
        "name": "Oleg Nesterov",
        "email": "oleg@redhat.com",
        "time": "Tue Nov 12 15:10:01 2013 -0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Jun 07 16:01:58 2014 -0700"
      },
      "message": "list: introduce list_next_entry() and list_prev_entry()\n\n[ Upstream commit 008208c6b26f21c2648c250a09c55e737c02c5f8 ]\n\nAdd two trivial helpers list_next_entry() and list_prev_entry(), they\ncan have a lot of users including list.h itself.  In fact the 1st one is\nalready defined in events/core.c and bnx2x_sp.c, so the patch simply\nmoves the definition to list.h.\n\nSigned-off-by: Oleg Nesterov \u003coleg@redhat.com\u003e\nCc: Eilon Greenstein \u003ceilong@broadcom.com\u003e\nCc: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nCc: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    },
    {
      "commit": "7bd3c53d12e0e454091ad35090410267af0e4a84",
      "tree": "98acc75a24ce0b6d632d2eb1daa8d510f3daea94",
      "parents": [
        "8ed40c122919cd79bc3c059e5864e5e7d9d455f0"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Wed Feb 26 10:54:36 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sun May 18 05:25:56 2014 -0700"
      },
      "message": "tracepoint: Do not waste memory on mods with no tracepoints\n\ncommit 7dec935a3aa04412cba2cebe1524ae0d34a30c24 upstream.\n\nNo reason to allocate tp_module structures for modules that have no\ntracepoints. This just wastes memory.\n\nFixes: b75ef8b44b1c \"Tracepoint: Dissociate from module mutex\"\nAcked-by: Mathieu Desnoyers \u003cmathieu.desnoyers@efficios.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "14eee5bd065d6aac0acbdc6092a25ba68c55b9c8",
      "tree": "6a5be23dd8205130a59ea2d9b9ce13e54c7c518f",
      "parents": [
        "664c0fc651b6ca2ab43ddbb73bbda2acdb2c9915"
      ],
      "author": {
        "name": "Roman Pen",
        "email": "r.peniaev@gmail.com",
        "time": "Tue Mar 04 23:13:10 2014 +0900"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sun May 18 05:25:55 2014 -0700"
      },
      "message": "blktrace: fix accounting of partially completed requests\n\ncommit af5040da01ef980670b3741b3e10733ee3e33566 upstream.\n\ntrace_block_rq_complete does not take into account that request can\nbe partially completed, so we can get the following incorrect output\nof blkparser:\n\n  C   R 232 + 240 [0]\n  C   R 240 + 232 [0]\n  C   R 248 + 224 [0]\n  C   R 256 + 216 [0]\n\nbut should be:\n\n  C   R 232 + 8 [0]\n  C   R 240 + 8 [0]\n  C   R 248 + 8 [0]\n  C   R 256 + 8 [0]\n\nAlso, the whole output summary statistics of completed requests and\nfinal throughput will be incorrect.\n\nThis patch takes into account real completion size of the request and\nfixes wrong completion accounting.\n\nSigned-off-by: Roman Pen \u003cr.peniaev@gmail.com\u003e\nCC: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCC: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nCC: Ingo Molnar \u003cmingo@redhat.com\u003e\nCC: linux-kernel@vger.kernel.org\nSigned-off-by: Jens Axboe \u003caxboe@fb.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "96f6aea2715b25edfc9b982f9e372bd87db6c04e",
      "tree": "36c4f98e3e0c9e2a8ac02ccfbdd320577478abc5",
      "parents": [
        "af4acfaf3ca2f1da6e48d67e50f27f5e22fa3308"
      ],
      "author": {
        "name": "Liu Hua",
        "email": "sdu.liu@huawei.com",
        "time": "Mon Apr 07 15:38:57 2014 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue May 06 07:51:45 2014 -0700"
      },
      "message": "hung_task: check the value of \"sysctl_hung_task_timeout_sec\"\n\ncommit 80df28476505ed4e6701c3448c63c9229a50c655 upstream.\n\nAs sysctl_hung_task_timeout_sec is unsigned long, when this value is\nlarger then LONG_MAX/HZ, the function schedule_timeout_interruptible in\nwatchdog will return immediately without sleep and with print :\n\n  schedule_timeout: wrong timeout value ffffffffffffff83\n\nand then the funtion watchdog will call schedule_timeout_interruptible\nagain and again.  The screen will be filled with\n\n\t\"schedule_timeout: wrong timeout value ffffffffffffff83\"\n\nThis patch does some check and correction in sysctl, to let the function\nschedule_timeout_interruptible allways get the valid parameter.\n\nSigned-off-by: Liu Hua \u003csdu.liu@huawei.com\u003e\nTested-by: Satoru Takeuchi \u003csatoru.takeuchi@gmail.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "d66d2078181ddf2d26585c6737ea43ea8a6f52e6",
      "tree": "6ef8e1786836c5e8872d6ecd9b9625a13bfe807a",
      "parents": [
        "371d9bb7dab6293e79aafb5481b842629a60aa5e"
      ],
      "author": {
        "name": "Oleg Nesterov",
        "email": "oleg@redhat.com",
        "time": "Mon Apr 07 15:38:41 2014 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Apr 26 17:13:20 2014 -0700"
      },
      "message": "wait: fix reparent_leader() vs EXIT_DEAD-\u003eEXIT_ZOMBIE race\n\ncommit dfccbb5e49a621c1b21a62527d61fc4305617aca upstream.\n\nwait_task_zombie() first does EXIT_ZOMBIE-\u003eEXIT_DEAD transition and\ndrops tasklist_lock.  If this task is not the natural child and it is\ntraced, we change its state back to EXIT_ZOMBIE for -\u003ereal_parent.\n\nThe last transition is racy, this is even documented in 50b8d257486a\n\"ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD-\u003eEXIT_ZOMBIE\nrace\".  wait_consider_task() tries to detect this transition and clear\n-\u003enotask_error but we can\u0027t rely on ptrace_reparented(), debugger can\nexit and do ptrace_unlink() before its sub-thread sets EXIT_ZOMBIE.\n\nAnd there is another problem which were missed before: this transition\ncan also race with reparent_leader() which doesn\u0027t reset \u003eexit_signal if\nEXIT_DEAD, assuming that this task must be reaped by someone else.  So\nthe tracee can be re-parented with -\u003eexit_signal !\u003d SIGCHLD, and if\n/sbin/init doesn\u0027t use __WALL it becomes unreapable.\n\nChange reparent_leader() to update -\u003eexit_signal even if EXIT_DEAD.\nNote: this is the simple temporary hack for -stable, it doesn\u0027t try to\nsolve all problems, it will be reverted by the next changes.\n\nSigned-off-by: Oleg Nesterov \u003coleg@redhat.com\u003e\nReported-by: Jan Kratochvil \u003cjan.kratochvil@redhat.com\u003e\nReported-by: Michal Schmidt \u003cmschmidt@redhat.com\u003e\nTested-by: Michal Schmidt \u003cmschmidt@redhat.com\u003e\nCc: Al Viro \u003cviro@ZenIV.linux.org.uk\u003e\nCc: Lennart Poettering \u003clpoetter@redhat.com\u003e\nCc: Roland McGrath \u003croland@hack.frob.com\u003e\nCc: Tejun Heo \u003ctj@kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "00cef7a5e0766f0f4bedc9da1c80fbe992cf68ef",
      "tree": "cf6eee93fbfe7eb5bfbc934f26391c69aa454f5c",
      "parents": [
        "aa34e62c2f0d4a105606971a1eb666f22338993b"
      ],
      "author": {
        "name": "Tejun Heo",
        "email": "tj@kernel.org",
        "time": "Wed Aug 28 17:33:37 2013 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Apr 14 06:44:16 2014 -0700"
      },
      "message": "workqueue: cond_resched() after processing each work item\n\ncommit b22ce2785d97423846206cceec4efee0c4afd980 upstream.\n\nIf !PREEMPT, a kworker running work items back to back can hog CPU.\nThis becomes dangerous when a self-requeueing work item which is\nwaiting for something to happen races against stop_machine.  Such\nself-requeueing work item would requeue itself indefinitely hogging\nthe kworker and CPU it\u0027s running on while stop_machine would wait for\nthat CPU to enter stop_machine while preventing anything else from\nhappening on all other CPUs.  The two would deadlock.\n\nJamie Liu reports that this deadlock scenario exists around\nscsi_requeue_run_queue() and libata port multiplier support, where one\nport may exclude command processing from other ports.  With the right\ntiming, scsi_requeue_run_queue() can end up requeueing itself trying\nto execute an IO which is asked to be retried while another device has\nan exclusive access, which in turn can\u0027t make forward progress due to\nstop_machine.\n\nFix it by invoking cond_resched() after executing each work item.\n\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nReported-by: Jamie Liu \u003cjamieliu@google.com\u003e\nReferences: http://thread.gmane.org/gmane.linux.kernel/1552567\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings \u003cben@decadent.org.uk\u003e\nCc: Qiang Huang \u003ch.huangqiang@huawei.com\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nCc: Jianguo Wu \u003cwujianguo@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "aa34e62c2f0d4a105606971a1eb666f22338993b",
      "tree": "0dff0ab9129f77e0e510a1c82c29027751959313",
      "parents": [
        "0df19efa7549d47aa906b8316665e46366b56061"
      ],
      "author": {
        "name": "Bu, Yitian",
        "email": "ybu@qti.qualcomm.com",
        "time": "Mon Feb 18 12:53:37 2013 +0000"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Apr 14 06:44:16 2014 -0700"
      },
      "message": "printk: Fix rq-\u003elock vs logbuf_lock unlock lock inversion\n\ncommit dbda92d16f8655044e082930e4e9d244b87fde77 upstream.\n\ncommit 07354eb1a74d1 (\"locking printk: Annotate logbuf_lock as raw\")\nreintroduced a lock inversion problem which was fixed in commit\n0b5e1c5255 (\"printk: Release console_sem after logbuf_lock\"). This\nhappened probably when fixing up patch rejects.\n\nRestore the ordering and unlock logbuf_lock before releasing\nconsole_sem.\n\nSigned-off-by: ybu \u003cybu@qti.qualcomm.com\u003e\nCc: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLink: http://lkml.kernel.org/r/E807E903FE6CBE4D95E420FBFCC273B827413C@nasanexd01h.na.qualcomm.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings \u003cben@decadent.org.uk\u003e\nCc: Qiang Huang \u003ch.huangqiang@huawei.com\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nCc: Jianguo Wu \u003cwujianguo@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "0df19efa7549d47aa906b8316665e46366b56061",
      "tree": "d2fd1a086837d4050a88062036f72ce49a0e63ec",
      "parents": [
        "c45821f729ca087f87aa9ea08ffe964584a0d605"
      ],
      "author": {
        "name": "Oleg Nesterov",
        "email": "oleg@redhat.com",
        "time": "Wed Jun 12 14:04:46 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Mon Apr 14 06:44:15 2014 -0700"
      },
      "message": "audit: wait_for_auditd() should use TASK_UNINTERRUPTIBLE\n\ncommit f000cfdde5de4fc15dead5ccf524359c07eadf2b upstream.\n\naudit_log_start() does wait_for_auditd() in a loop until\naudit_backlog_wait_time passes or audit_skb_queue has a room.\n\nIf signal_pending() is true this becomes a busy-wait loop, schedule() in\nTASK_INTERRUPTIBLE won\u0027t block.\n\nThanks to Guy for fully investigating and explaining the problem.\n\n(akpm: that\u0027ll cause the system to lock up on a non-preemptible\nuniprocessor kernel)\n\n(Guy: \"Our customer was in fact running a uniprocessor machine, and they\nreported a system hang.\")\n\nSigned-off-by: Oleg Nesterov \u003coleg@redhat.com\u003e\nReported-by: Guy Streeter \u003cstreeter@redhat.com\u003e\nCc: Eric Paris \u003ceparis@redhat.com\u003e\nCc: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n[bwh: Backported to 3.2: adjust context, indentation]\nSigned-off-by: Ben Hutchings \u003cben@decadent.org.uk\u003e\nCc: Qiang Huang \u003ch.huangqiang@huawei.com\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nCc: Jianguo Wu \u003cwujianguo@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "a299804140325db7b93173419b0724056b60f34d",
      "tree": "bd83dcad3466c51e0f3a731ec15b5b09be562814",
      "parents": [
        "c5ad4fdec0ae15d197508185643c68470868121d"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Wed Feb 26 13:37:38 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sun Mar 23 21:37:06 2014 -0700"
      },
      "message": "tracing: Do not add event files for modules that fail tracepoints\n\ncommit 45ab2813d40d88fc575e753c38478de242d03f88 upstream.\n\nIf a module fails to add its tracepoints due to module tainting, do not\ncreate the module event infrastructure in the debugfs directory. As the events\nwill not work and worse yet, they will silently fail, making the user wonder\nwhy the events they enable do not display anything.\n\nHaving a warning on module load and the events not visible to the users\nwill make the cause of the problem much clearer.\n\nLink: http://lkml.kernel.org/r/20140227154923.265882695@goodmis.org\n\nFixes: 6d723736e472 \"tracing/events: add support for modules to TRACE_EVENT\"\nAcked-by: Mathieu Desnoyers \u003cmathieu.desnoyers@efficios.com\u003e\nCc: Rusty Russell \u003crusty@rustcorp.com.au\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "c5ad4fdec0ae15d197508185643c68470868121d",
      "tree": "d665cfe6c40a7e0f950aefbba227fcd691e2416e",
      "parents": [
        "b46741f24d1c0d0d8dcfb3c63439338d2dc0337e"
      ],
      "author": {
        "name": "Li Zefan",
        "email": "lizefan@huawei.com",
        "time": "Thu Feb 27 18:19:36 2014 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sun Mar 23 21:37:05 2014 -0700"
      },
      "message": "cpuset: fix a race condition in __cpuset_node_allowed_softwall()\n\ncommit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream.\n\nIt\u0027s not safe to access task\u0027s cpuset after releasing task_lock().\nHolding callback_mutex won\u0027t help.\n\nSigned-off-by: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "b46741f24d1c0d0d8dcfb3c63439338d2dc0337e",
      "tree": "e5c655ff39f3806adcd5601e44dcc67a49e74e04",
      "parents": [
        "bb7d79fc8250eaa01ac6f82f9001ffcec0e7ca36"
      ],
      "author": {
        "name": "Chuansheng Liu",
        "email": "chuansheng.liu@intel.com",
        "time": "Mon Feb 24 11:29:50 2014 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sun Mar 23 21:37:05 2014 -0700"
      },
      "message": "genirq: Remove racy waitqueue_active check\n\ncommit c685689fd24d310343ac33942e9a54a974ae9c43 upstream.\n\nWe hit one rare case below:\n\nT1 calling disable_irq(), but hanging at synchronize_irq()\nalways;\nThe corresponding irq thread is in sleeping state;\nAnd all CPUs are in idle state;\n\nAfter analysis, we found there is one possible scenerio which\ncauses T1 is waiting there forever:\nCPU0                                       CPU1\n synchronize_irq()\n  wait_event()\n    spin_lock()\n                                           atomic_dec_and_test(\u0026threads_active)\n      insert the __wait into queue\n    spin_unlock()\n                                           if(waitqueue_active)\n    atomic_read(\u0026threads_active)\n                                             wake_up()\n\nHere after inserted the __wait into queue on CPU0, and before\ntest if queue is empty on CPU1, there is no barrier, it maybe\ncause it is not visible for CPU1 immediately, although CPU0 has\nupdated the queue list.\nIt is similar for CPU0 atomic_read() threads_active also.\n\nSo we\u0027d need one smp_mb() before waitqueue_active.that, but removing\nthe waitqueue_active() check solves it as wel l and it makes\nthings simple and clear.\n\nSigned-off-by: Chuansheng Liu \u003cchuansheng.liu@intel.com\u003e\nCc: Xiaoming Wang \u003cxiaoming.wang@intel.com\u003e\nLink: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "6ba4d1d9112b3f6bf0f634870bb950b5b59fa86f",
      "tree": "f6089b725009d95c6686bb6bb02022231c3f0a88",
      "parents": [
        "efcb9185af1155146326a850aaa6617a5bb55172"
      ],
      "author": {
        "name": "George McCollister",
        "email": "george.mccollister@gmail.com",
        "time": "Tue Feb 18 17:56:51 2014 -0600"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sun Mar 23 21:37:03 2014 -0700"
      },
      "message": "sched: Fix double normalization of vruntime\n\ncommit 791c9e0292671a3bfa95286bb5c08129d8605618 upstream.\n\ndequeue_entity() is called when p-\u003eon_rq and sets se-\u003eon_rq \u003d 0\nwhich appears to guarentee that the !se-\u003eon_rq condition is met.\nIf the task has done set_current_state(TASK_INTERRUPTIBLE) without\nschedule() the second condition will be met and vruntime will be\nincorrectly adjusted twice.\n\nIn certain cases this can result in the task\u0027s vruntime never increasing\npast the vruntime of other tasks on the CFS\u0027 run queue, starving them of\nCPU time.\n\nThis patch changes switched_from_fair() to use !p-\u003eon_rq instead of\n!se-\u003eon_rq.\n\nI\u0027m able to cause a task with a priority of 120 to starve all other\ntasks with the same priority on an ARM platform running 3.2.51-rt72\nPREEMPT RT by writing one character at time to a serial tty (16550 UART)\nin a tight loop. I\u0027m also able to verify making this change corrects the\nproblem on that platform and kernel version.\n\nSigned-off-by: George McCollister \u003cgeorge.mccollister@gmail.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/1392767811-28916-1-git-send-email-george.mccollister@gmail.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "30ec268be37bdb5b1614cce40af8083f1a7c27f3",
      "tree": "0304a8573785798584cbd36ed30f69621410ba64",
      "parents": [
        "f47929fd5093c4b5c134ff2b2811ae327102bafd"
      ],
      "author": {
        "name": "Tejun Heo",
        "email": "tj@kernel.org",
        "time": "Tue Oct 16 15:03:14 2012 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue Mar 11 16:10:03 2014 -0700"
      },
      "message": "cgroup: cgroup_subsys-\u003efork() should be called after the task is added to css_set\n\ncommit 5edee61edeaaebafe584f8fb7074c1ef4658596b upstream.\n\ncgroup core has a bug which violates a basic rule about event\nnotifications - when a new entity needs to be added, you add that to\nthe notification list first and then make the new entity conform to\nthe current state.  If done in the reverse order, an event happening\ninbetween will be lost.\n\ncgroup_subsys-\u003efork() is invoked way before the new task is added to\nthe css_set.  Currently, cgroup_freezer is the only user of -\u003efork()\nand uses it to make new tasks conform to the current state of the\nfreezer.  If FROZEN state is requested while fork is in progress\nbetween cgroup_fork_callbacks() and cgroup_post_fork(), the child\ncould escape freezing - the cgroup isn\u0027t frozen when -\u003efork() is\ncalled and the freezer couldn\u0027t see the new task on the css_set.\n\nThis patch moves cgroup_subsys-\u003efork() invocation to\ncgroup_post_fork() after the new task is added to the css_set.\ncgroup_fork_callbacks() is removed.\n\nBecause now a task may be migrated during cgroup_subsys-\u003efork(),\nfreezer_fork() is updated so that it adheres to the usual RCU locking\nand the rather pointless comment on why locking can be different there\nis removed (if it doesn\u0027t make anything simpler, why even bother?).\n\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nCc: Oleg Nesterov \u003coleg@redhat.com\u003e\nCc: Rafael J. Wysocki \u003crjw@sisk.pl\u003e\n[hq: Backported to 3.4:\n - Adjust context\n - Iterate over first CGROUP_BUILTIN_SUBSYS_COUNT elements of subsys]\nSigned-off-by: Qiang Huang \u003ch.huangqiang@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "f80747a43fc2613b9f5e1ded16f50ef28815652e",
      "tree": "17481b7c5f2b6165a1c78faefe549e0c4dd53b2e",
      "parents": [
        "23f0913c2b3816b11f32dcf774758b3f63b81f60"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "peterz@infradead.org",
        "time": "Mon Feb 24 12:06:12 2014 +0100"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue Mar 11 16:10:02 2014 -0700"
      },
      "message": "perf: Fix hotplug splat\n\ncommit e3703f8cdfcf39c25c4338c3ad8e68891cca3731 upstream.\n\nDrew Richardson reported that he could make the kernel go *boom* when hotplugging\nwhile having perf events active.\n\nIt turned out that when you have a group event, the code in\n__perf_event_exit_context() fails to remove the group siblings from\nthe context.\n\nWe then proceed with destroying and freeing the event, and when you\nre-plug the CPU and try and add another event to that CPU, things go\n*boom* because you\u0027ve still got dead entries there.\n\nReported-by: Drew Richardson \u003cdrew.richardson@arm.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Will Deacon \u003cwill.deacon@arm.com\u003e\nLink: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.org\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "23f0913c2b3816b11f32dcf774758b3f63b81f60",
      "tree": "60ca6fbcf16e2e18dfbe6235ab5764f232c2b88c",
      "parents": [
        "8d36299431351e5c3a893d9c1eae7579ebc57ad5"
      ],
      "author": {
        "name": "Lai Jiangshan",
        "email": "laijs@cn.fujitsu.com",
        "time": "Sat Feb 15 22:02:28 2014 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue Mar 11 16:10:02 2014 -0700"
      },
      "message": "workqueue: ensure @task is valid across kthread_stop()\n\ncommit 5bdfff96c69a4d5ab9c49e60abf9e070ecd2acbb upstream.\n\nWhen a kworker should die, the kworkre is notified through WORKER_DIE\nflag instead of kthread_should_stop().  This, IIRC, is primarily to\nkeep the test synchronized inside worker_pool lock.  WORKER_DIE is\nfirst set while holding pool-\u003elock, the lock is dropped and\nkthread_stop() is called.\n\nUnfortunately, this means that there\u0027s a slight chance that the target\nkworker may see WORKER_DIE before kthread_stop() finishes and exits\nand frees the target task before or during kthread_stop().\n\nFix it by pinning the target task before setting WORKER_DIE and\nputting it after kthread_stop() is done.\n\ntj: Improved patch description and comment.  Moved pinning above\n    WORKER_DIE for better signify what it\u0027s protecting.\n\nSigned-off-by: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "df1cc7da2a599bde8f28f94601b7ec4c85ec441b",
      "tree": "be91297f18aa7fe689ca548c6ee5a9deca62d992",
      "parents": [
        "17ff13b428cc2900bc04570f3a74d746856f35e6"
      ],
      "author": {
        "name": "Paul Gortmaker",
        "email": "paul.gortmaker@windriver.com",
        "time": "Mon Feb 10 13:39:53 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Feb 22 10:32:46 2014 -0800"
      },
      "message": "genirq: Add missing irq_to_desc export for CONFIG_SPARSE_IRQ\u003dn\n\ncommit 2c45aada341121438affc4cb8d5b4cfaa2813d3d upstream.\n\nIn allmodconfig builds for sparc and any other arch which does\nnot set CONFIG_SPARSE_IRQ, the following will be seen at modpost:\n\n  CC [M]  lib/cpu-notifier-error-inject.o\n  CC [M]  lib/pm-notifier-error-inject.o\nERROR: \"irq_to_desc\" [drivers/gpio/gpio-mcp23s08.ko] undefined!\nmake[2]: *** [__modpost] Error 1\n\nThis happens because commit 3911ff30f5 (\"genirq: export\nhandle_edge_irq() and irq_to_desc()\") added one export for it, but\nthere were actually two instances of it, in an if/else clause for\nCONFIG_SPARSE_IRQ.  Add the second one.\n\nSigned-off-by: Paul Gortmaker \u003cpaul.gortmaker@windriver.com\u003e\nCc: Jiri Kosina \u003cjkosina@suse.cz\u003e\nLink: http://lkml.kernel.org/r/1392057610-11514-1-git-send-email-paul.gortmaker@windriver.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "17ff13b428cc2900bc04570f3a74d746856f35e6",
      "tree": "3e705c590d8f6b57b0279fc0d5c11d7c6f5ed5d0",
      "parents": [
        "7db019a232f3577a92a2a81d34e4add1c4b80483"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Tue Feb 11 13:38:54 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Feb 22 10:32:46 2014 -0800"
      },
      "message": "ring-buffer: Fix first commit on sub-buffer having non-zero delta\n\ncommit d651aa1d68a2f0a7ee65697b04c6a92f8c0a12f2 upstream.\n\nEach sub-buffer (buffer page) has a full 64 bit timestamp. The events on\nthat page use a 27 bit delta against that timestamp in order to save on\nbits written to the ring buffer. If the time between events is larger than\nwhat the 27 bits can hold, a \"time extend\" event is added to hold the\nentire 64 bit timestamp again and the events after that hold a delta from\nthat timestamp.\n\nAs a \"time extend\" is always paired with an event, it is logical to just\nallocate the event with the time extend, to make things a bit more efficient.\n\nUnfortunately, when the pairing code was written, it removed the \"delta \u003d 0\"\nfrom the first commit on a page, causing the events on the page to be\nslightly skewed.\n\nFixes: 69d1b839f7ee \"ring-buffer: Bind time extend and data events together\"\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "d6e20e8145341ed1b5d605a8d9ab8463b0ca6ed8",
      "tree": "4e83c6dc0f10988e10a9341d33d47aef3a93e744",
      "parents": [
        "cd6f6b709eebe70d80a3e542d218228bcf189654"
      ],
      "author": {
        "name": "Mikulas Patocka",
        "email": "mpatocka@redhat.com",
        "time": "Fri Jan 24 16:41:36 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Sat Feb 22 10:32:46 2014 -0800"
      },
      "message": "time: Fix overflow when HZ is smaller than 60\n\ncommit 80d767d770fd9c697e434fd080c2db7b5c60c6dd upstream.\n\nWhen compiling for the IA-64 ski emulator, HZ is set to 32 because the\nemulation is slow and we don\u0027t want to waste too many cycles processing\ntimers. Alpha also has an option to set HZ to 32.\n\nThis causes integer underflow in\nkernel/time/jiffies.c:\nkernel/time/jiffies.c:66:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]\n  .mult  \u003d NSEC_PER_JIFFY \u003c\u003c JIFFIES_SHIFT, /* details above */\n  ^\n\nThis patch reduces the JIFFIES_SHIFT value to avoid the overflow.\n\nSigned-off-by: Mikulas Patocka \u003cmikulas@artax.karlin.mff.cuni.cz\u003e\nLink: http://lkml.kernel.org/r/alpine.LRH.2.02.1401241639100.23871@file01.intranet.prod.int.rdu2.redhat.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "b249f99c023402a192e1af812326c5092e64175f",
      "tree": "49b94c6486350105fe8334c9e81b105dc557f6af",
      "parents": [
        "ec90b6113735a9f9fcb64a604b28f446fe03ded2"
      ],
      "author": {
        "name": "Bojan Smojver",
        "email": "bojan@rexursive.com",
        "time": "Sun Apr 29 22:42:06 2012 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 20 10:45:33 2014 -0800"
      },
      "message": "PM / Hibernate: Hibernate/thaw fixes/improvements\n\ncommit 5a21d489fd9541a4a66b9a500659abaca1b19a51 upstream.\n\n 1. Do not allocate memory for buffers from emergency pools, unless\n    absolutely required. Do not warn about and do not retry non-essential\n    failed allocations.\n\n 2. Do not check the amount of free pages left on every single page\n    write, but wait until one map is completely populated and then check.\n\n 3. Set maximum number of pages for read buffering consistently, instead\n    of inadvertently depending on the size of the sector type.\n\n 4. Fix copyright line, which I missed when I submitted the hibernation\n    threading patch.\n\n 5. Dispense with bit shifting arithmetic to improve readability.\n\n 6. Really recalculate the number of pages required to be free after all\n    allocations have been done.\n\n 7. Fix calculation of pages required for read buffering. Only count in\n    pages that do not belong to high memory.\n\nSigned-off-by: Bojan Smojver \u003cbojan@rexursive.com\u003e\nSigned-off-by: Rafael J. Wysocki \u003crjw@sisk.pl\u003e\nSigned-off-by: Ben Hutchings \u003cben@decadent.org.uk\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "f5a4c4b79e57f875b6788f6f8352ca246bfd8450",
      "tree": "936b2200d4581b36faa0c94fab560013486885be",
      "parents": [
        "e2d51f27e382be7b70a755f3ea2fbbeacdb50834"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "a.p.zijlstra@chello.nl",
        "time": "Thu May 17 17:15:29 2012 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 20 10:45:32 2014 -0800"
      },
      "message": "sched/nohz: Fix rq-\u003ecpu_load calculations some more\n\ncommit 5aaa0b7a2ed5b12692c9ffb5222182bd558d3146 upstream.\n\nFollow up on commit 556061b00 (\"sched/nohz: Fix rq-\u003ecpu_load[]\ncalculations\") since while that fixed the busy case it regressed the\nmostly idle case.\n\nAdd a callback from the nohz exit to also age the rq-\u003ecpu_load[]\narray. This closes the hole where either there was no nohz load\nbalance pass during the nohz, or there was a \u0027significant\u0027 amount of\nidle time between the last nohz balance and the nohz exit.\n\nSo we\u0027ll update unconditionally from the tick to not insert any\naccidental 0 load periods while busy, and we try and catch up from\nnohz idle balance and nohz exit. Both these are still prone to missing\na jiffy, but that has always been the case.\n\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nCc: pjt@google.com\nCc: Venkatesh Pallipadi \u003cvenki@google.com\u003e\nLink: http://lkml.kernel.org/n/tip-kt0trz0apodbf84ucjfdbr1a@git.kernel.org\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "e2d51f27e382be7b70a755f3ea2fbbeacdb50834",
      "tree": "893a14b43a9eda39df07c1a6879c74f197977358",
      "parents": [
        "1c2bd0db1189643691557ff34406906b053cef92"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "a.p.zijlstra@chello.nl",
        "time": "Fri May 11 17:31:26 2012 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 20 10:45:32 2014 -0800"
      },
      "message": "sched/nohz: Fix rq-\u003ecpu_load[] calculations\n\ncommit 556061b00c9f2fd6a5524b6bde823ef12f299ecf upstream.\n\nWhile investigating why the load-balancer did funny I found that the\nrq-\u003ecpu_load[] tables were completely screwy.. a bit more digging\nrevealed that the updates that got through were missing ticks followed\nby a catchup of 2 ticks.\n\nThe catchup assumes the cpu was idle during that time (since only nohz\ncan cause missed ticks and the machine is idle etc..) this means that\nesp. the higher indices were significantly lower than they ought to\nbe.\n\nThe reason for this is that its not correct to compare against jiffies\non every jiffy on any other cpu than the cpu that updates jiffies.\n\nThis patch cludges around it by only doing the catch-up stuff from\nnohz_idle_balance() and doing the regular stuff unconditionally from\nthe tick.\n\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nCc: pjt@google.com\nCc: Venkatesh Pallipadi \u003cvenki@google.com\u003e\nLink: http://lkml.kernel.org/n/tip-tp4kj18xdd5aj4vvj0qg55s2@git.kernel.org\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "1c2bd0db1189643691557ff34406906b053cef92",
      "tree": "7ca9b005df493f23b9d3230decc8dd7e8e6d60e7",
      "parents": [
        "2955866584c57545061dc38dc69de3461437aa9a"
      ],
      "author": {
        "name": "Steven Rostedt",
        "email": "rostedt@goodmis.org",
        "time": "Tue Feb 11 14:50:01 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 20 10:45:32 2014 -0800"
      },
      "message": "ftrace: Have function graph only trace based on global_ops filters\n\ncommit 23a8e8441a0a74dd612edf81dc89d1600bc0a3d1 upstream.\n\nDoing some different tests, I discovered that function graph tracing, when\nfiltered via the set_ftrace_filter and set_ftrace_notrace files, does\nnot always keep with them if another function ftrace_ops is registered\nto trace functions.\n\nThe reason is that function graph just happens to trace all functions\nthat the function tracer enables. When there was only one user of\nfunction tracing, the function graph tracer did not need to worry about\nbeing called by functions that it did not want to trace. But now that there\nare other users, this becomes a problem.\n\nFor example, one just needs to do the following:\n\n # cd /sys/kernel/debug/tracing\n # echo schedule \u003e set_ftrace_filter\n # echo function_graph \u003e current_tracer\n # cat trace\n[..]\n 0)               |  schedule() {\n ------------------------------------------\n 0)    \u003cidle\u003e-0    \u003d\u003e   rcu_pre-7\n ------------------------------------------\n\n 0) ! 2980.314 us |  }\n 0)               |  schedule() {\n ------------------------------------------\n 0)   rcu_pre-7    \u003d\u003e    \u003cidle\u003e-0\n ------------------------------------------\n\n 0) + 20.701 us   |  }\n\n # echo 1 \u003e /proc/sys/kernel/stack_tracer_enabled\n # cat trace\n[..]\n 1) + 20.825 us   |      }\n 1) + 21.651 us   |    }\n 1) + 30.924 us   |  } /* SyS_ioctl */\n 1)               |  do_page_fault() {\n 1)               |    __do_page_fault() {\n 1)   0.274 us    |      down_read_trylock();\n 1)   0.098 us    |      find_vma();\n 1)               |      handle_mm_fault() {\n 1)               |        _raw_spin_lock() {\n 1)   0.102 us    |          preempt_count_add();\n 1)   0.097 us    |          do_raw_spin_lock();\n 1)   2.173 us    |        }\n 1)               |        do_wp_page() {\n 1)   0.079 us    |          vm_normal_page();\n 1)   0.086 us    |          reuse_swap_page();\n 1)   0.076 us    |          page_move_anon_rmap();\n 1)               |          unlock_page() {\n 1)   0.082 us    |            page_waitqueue();\n 1)   0.086 us    |            __wake_up_bit();\n 1)   1.801 us    |          }\n 1)   0.075 us    |          ptep_set_access_flags();\n 1)               |          _raw_spin_unlock() {\n 1)   0.098 us    |            do_raw_spin_unlock();\n 1)   0.105 us    |            preempt_count_sub();\n 1)   1.884 us    |          }\n 1)   9.149 us    |        }\n 1) + 13.083 us   |      }\n 1)   0.146 us    |      up_read();\n\nWhen the stack tracer was enabled, it enabled all functions to be traced, which\nnow the function graph tracer also traces. This is a side effect that should\nnot occur.\n\nTo fix this a test is added when the function tracing is changed, as well as when\nthe graph tracer is enabled, to see if anything other than the ftrace global_ops\nfunction tracer is enabled. If so, then the graph tracer calls a test trampoline\nthat will look at the function that is being traced and compare it with the\nfilters defined by the global_ops.\n\nAs an optimization, if there\u0027s no other function tracers registered, or if\nthe only registered function tracers also use the global ops, the function\ngraph infrastructure will call the registered function graph callback directly\nand not go through the test trampoline.\n\nFixes: d2d45c7a03a2 \"tracing: Have stack_tracer use a separate list of functions\"\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    },
    {
      "commit": "2955866584c57545061dc38dc69de3461437aa9a",
      "tree": "bd8336f3d3d943f71733da5980c4729460652a34",
      "parents": [
        "95bcd16ee7ce1cfb3fea853e38023f65d9d21c7c"
      ],
      "author": {
        "name": "Steven Rostedt",
        "email": "rostedt@goodmis.org",
        "time": "Tue Feb 11 14:49:37 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 20 10:45:32 2014 -0800"
      },
      "message": "ftrace: Fix synchronization location disabling and freeing ftrace_ops\n\ncommit a4c35ed241129dd142be4cadb1e5a474a56d5464 upstream.\n\nThe synchronization needed after ftrace_ops are unregistered must happen\nafter the callback is disabled from becing called by functions.\n\nThe current location happens after the function is being removed from the\ninternal lists, but not after the function callbacks were disabled, leaving\nthe functions susceptible of being called after their callbacks are freed.\n\nThis affects perf and any externel users of function tracing (LTTng and\nSystemTap).\n\nFixes: cdbe61bfe704 \"ftrace: Allow dynamically allocated function tracers\"\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    },
    {
      "commit": "95bcd16ee7ce1cfb3fea853e38023f65d9d21c7c",
      "tree": "412a793ec08d91d0f2949ee315c4969e645d4613",
      "parents": [
        "a7333f3d237f3007d14a2ee0456b96a4b33522d0"
      ],
      "author": {
        "name": "Steven Rostedt",
        "email": "rostedt@goodmis.org",
        "time": "Tue Feb 11 14:49:07 2014 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 20 10:45:32 2014 -0800"
      },
      "message": "ftrace: Synchronize setting function_trace_op with ftrace_trace_function\n\ncommit 405e1d834807e51b2ebd3dea81cb51e53fb61504 upstream.\n\n[ Partial commit backported to 3.4. The ftrace_sync() code by this is\n  required for other fixes that 3.4 needs. ]\n\nftrace_trace_function is a variable that holds what function will be called\ndirectly by the assembly code (mcount). If just a single function is\nregistered and it handles recursion itself, then the assembly will call that\nfunction directly without any helper function. It also passes in the\nftrace_op that was registered with the callback. The ftrace_op to send is\nstored in the function_trace_op variable.\n\nThe ftrace_trace_function and function_trace_op needs to be coordinated such\nthat the called callback wont be called with the wrong ftrace_op, otherwise\nbad things can happen if it expected a different op. Luckily, there\u0027s no\ncallback that doesn\u0027t use the helper functions that requires this. But\nthere soon will be and this needs to be fixed.\n\nUse a set_function_trace_op to store the ftrace_op to set the\nfunction_trace_op to when it is safe to do so (during the update function\nwithin the breakpoint or stop machine calls). Or if dynamic ftrace is not\nbeing used (static tracing) then we have to do a bit more synchronization\nwhen the ftrace_trace_function is set as that takes affect immediately\n(as oppose to dynamic ftrace doing it with the modification of the trampoline).\n\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    },
    {
      "commit": "5e23efd0c1d6c67761f859c141ba67bac80b81e0",
      "tree": "1de16dc6a5c06a7fae118e8e3e2553645892a778",
      "parents": [
        "36f0c45db55e2e840deefc286a33c2c7aef2f18e"
      ],
      "author": {
        "name": "Paul E. McKenney",
        "email": "paulmck@linux.vnet.ibm.com",
        "time": "Mon Oct 15 21:35:59 2012 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 20 10:45:32 2014 -0800"
      },
      "message": "printk: Fix scheduling-while-atomic problem in console_cpu_notify()\n\ncommit 85eae82a0855d49852b87deac8653e4ebc8b291f upstream.\n\nThe console_cpu_notify() function runs with interrupts disabled in the\nCPU_DYING case.  It therefore cannot block, for example, as will happen\nwhen it calls console_lock().  Therefore, remove the CPU_DYING leg of\nthe switch statement to avoid this problem.\n\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nReviewed-by: Srivatsa S. Bhat \u003csrivatsa.bhat@linux.vnet.ibm.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nCc: Guillaume Morin \u003cguillaume@morinfr.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "cd34de10471a5ddad397739fae33555d47e53769",
      "tree": "99e2e27194d72d5767093568a956751b835fdf43",
      "parents": [
        "cf85cc93b24891b7e57b1d9939742b5774570b19"
      ],
      "author": {
        "name": "Colin Cross",
        "email": "ccross@android.com",
        "time": "Mon Feb 10 13:16:29 2014 -0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 13 11:51:21 2014 -0800"
      },
      "message": "3.4.y: timekeeping: fix 32-bit overflow in get_monotonic_boottime\n\nfixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c\n\nget_monotonic_boottime adds three nanonsecond values stored\nin longs, followed by an s64.  If the long values are all\nclose to 1e9 the first three additions can overflow and\nbecome negative when added to the s64.  Cast the first\nvalue to s64 so that all additions are 64 bit.\n\nSigned-off-by: Colin Cross \u003cccross@android.com\u003e\n[jstultz: Fished this out of the AOSP commong.git tree. This was\nfixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c]\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    },
    {
      "commit": "cf85cc93b24891b7e57b1d9939742b5774570b19",
      "tree": "2a4719b1695dc561a13ea93b3083a60bca871e7b",
      "parents": [
        "ab99a94d45f5db1ed178ed986f93b938bc018a87"
      ],
      "author": {
        "name": "John Stultz",
        "email": "john.stultz@linaro.org",
        "time": "Tue Dec 10 17:18:18 2013 -0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 13 11:51:20 2014 -0800"
      },
      "message": "timekeeping: Avoid possible deadlock from clock_was_set_delayed\n\ncommit 6fdda9a9c5db367130cf32df5d6618d08b89f46a upstream.\n\nAs part of normal operaions, the hrtimer subsystem frequently calls\ninto the timekeeping code, creating a locking order of\n  hrtimer locks -\u003e timekeeping locks\n\nclock_was_set_delayed() was suppoed to allow us to avoid deadlocks\nbetween the timekeeping the hrtimer subsystem, so that we could\nnotify the hrtimer subsytem the time had changed while holding\nthe timekeeping locks. This was done by scheduling delayed work\nthat would run later once we were out of the timekeeing code.\n\nBut unfortunately the lock chains are complex enoguh that in\nscheduling delayed work, we end up eventually trying to grab\nan hrtimer lock.\n\nSasha Levin noticed this in testing when the new seqlock lockdep\nenablement triggered the following (somewhat abrieviated) message:\n\n[  251.100221] \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n[  251.100221] [ INFO: possible circular locking dependency detected ]\n[  251.100221] 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053 Not tainted\n[  251.101967] -------------------------------------------------------\n[  251.101967] kworker/10:1/4506 is trying to acquire lock:\n[  251.101967]  (timekeeper_seq){----..}, at: [\u003cffffffff81160e96\u003e] retrigger_next_event+0x56/0x70\n[  251.101967]\n[  251.101967] but task is already holding lock:\n[  251.101967]  (hrtimer_bases.lock#11){-.-...}, at: [\u003cffffffff81160e7c\u003e] retrigger_next_event+0x3c/0x70\n[  251.101967]\n[  251.101967] which lock already depends on the new lock.\n[  251.101967]\n[  251.101967]\n[  251.101967] the existing dependency chain (in reverse order) is:\n[  251.101967]\n-\u003e #5 (hrtimer_bases.lock#11){-.-...}:\n[snipped]\n-\u003e #4 (\u0026rt_b-\u003ert_runtime_lock){-.-...}:\n[snipped]\n-\u003e #3 (\u0026rq-\u003elock){-.-.-.}:\n[snipped]\n-\u003e #2 (\u0026p-\u003epi_lock){-.-.-.}:\n[snipped]\n-\u003e #1 (\u0026(\u0026pool-\u003elock)-\u003erlock){-.-...}:\n[  251.101967]        [\u003cffffffff81194803\u003e] validate_chain+0x6c3/0x7b0\n[  251.101967]        [\u003cffffffff81194d9d\u003e] __lock_acquire+0x4ad/0x580\n[  251.101967]        [\u003cffffffff81194ff2\u003e] lock_acquire+0x182/0x1d0\n[  251.101967]        [\u003cffffffff84398500\u003e] _raw_spin_lock+0x40/0x80\n[  251.101967]        [\u003cffffffff81153e69\u003e] __queue_work+0x1a9/0x3f0\n[  251.101967]        [\u003cffffffff81154168\u003e] queue_work_on+0x98/0x120\n[  251.101967]        [\u003cffffffff81161351\u003e] clock_was_set_delayed+0x21/0x30\n[  251.101967]        [\u003cffffffff811c4bd1\u003e] do_adjtimex+0x111/0x160\n[  251.101967]        [\u003cffffffff811e2711\u003e] compat_sys_adjtimex+0x41/0x70\n[  251.101967]        [\u003cffffffff843a4b49\u003e] ia32_sysret+0x0/0x5\n[  251.101967]\n-\u003e #0 (timekeeper_seq){----..}:\n[snipped]\n[  251.101967] other info that might help us debug this:\n[  251.101967]\n[  251.101967] Chain exists of:\n  timekeeper_seq --\u003e \u0026rt_b-\u003ert_runtime_lock --\u003e hrtimer_bases.lock#11\n\n[  251.101967]  Possible unsafe locking scenario:\n[  251.101967]\n[  251.101967]        CPU0                    CPU1\n[  251.101967]        ----                    ----\n[  251.101967]   lock(hrtimer_bases.lock#11);\n[  251.101967]                                lock(\u0026rt_b-\u003ert_runtime_lock);\n[  251.101967]                                lock(hrtimer_bases.lock#11);\n[  251.101967]   lock(timekeeper_seq);\n[  251.101967]\n[  251.101967]  *** DEADLOCK ***\n[  251.101967]\n[  251.101967] 3 locks held by kworker/10:1/4506:\n[  251.101967]  #0:  (events){.+.+.+}, at: [\u003cffffffff81154960\u003e] process_one_work+0x200/0x530\n[  251.101967]  #1:  (hrtimer_work){+.+...}, at: [\u003cffffffff81154960\u003e] process_one_work+0x200/0x530\n[  251.101967]  #2:  (hrtimer_bases.lock#11){-.-...}, at: [\u003cffffffff81160e7c\u003e] retrigger_next_event+0x3c/0x70\n[  251.101967]\n[  251.101967] stack backtrace:\n[  251.101967] CPU: 10 PID: 4506 Comm: kworker/10:1 Not tainted 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053\n[  251.101967] Workqueue: events clock_was_set_work\n\nSo the best solution is to avoid calling clock_was_set_delayed() while\nholding the timekeeping lock, and instead using a flag variable to\ndecide if we should call clock_was_set() once we\u0027ve released the locks.\n\nThis works for the case here, where the do_adjtimex() was the deadlock\ntrigger point. Unfortuantely, in update_wall_time() we still hold\nthe jiffies lock, which would deadlock with the ipi triggered by\nclock_was_set(), preventing us from calling it even after we drop the\ntimekeeping lock. So instead call clock_was_set_delayed() at that point.\n\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Prarit Bhargava \u003cprarit@redhat.com\u003e\nCc: Richard Cochran \u003crichardcochran@gmail.com\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Sasha Levin \u003csasha.levin@oracle.com\u003e\nReported-by: Sasha Levin \u003csasha.levin@oracle.com\u003e\nTested-by: Sasha Levin \u003csasha.levin@oracle.com\u003e\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n\n"
    },
    {
      "commit": "dbf3239455b155c3e72deacda93ef3a041e190c9",
      "tree": "c7a8cfce370fa0de4cdeaab1b75925061fe9ccf1",
      "parents": [
        "f61eb9ceb26cee3fdbb8c7a4920f171f7661fb4f"
      ],
      "author": {
        "name": "Ying Xue",
        "email": "ying.xue@windriver.com",
        "time": "Tue Jul 17 15:03:43 2012 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 13 11:51:19 2014 -0800"
      },
      "message": "sched/rt: Avoid updating RT entry timeout twice within one tick period\n\ncommit 57d2aa00dcec67afa52478730f2b524521af14fb upstream.\n\nThe issue below was found in 2.6.34-rt rather than mainline rt\nkernel, but the issue still exists upstream as well.\n\nSo please let me describe how it was noticed on 2.6.34-rt:\n\nOn this version, each softirq has its own thread, it means there\nis at least one RT FIFO task per cpu. The priority of these\ntasks is set to 49 by default. If user launches an RT FIFO task\nwith priority lower than 49 of softirq RT tasks, it\u0027s possible\nthere are two RT FIFO tasks enqueued one cpu runqueue at one\nmoment. By current strategy of balancing RT tasks, when it comes\nto RT tasks, we really need to put them off to a CPU that they\ncan run on as soon as possible. Even if it means a bit of cache\nline flushing, we want RT tasks to be run with the least latency.\n\nWhen the user RT FIFO task which just launched before is\nrunning, the sched timer tick of the current cpu happens. In this\ntick period, the timeout value of the user RT task will be\nupdated once. Subsequently, we try to wake up one softirq RT\ntask on its local cpu. As the priority of current user RT task\nis lower than the softirq RT task, the current task will be\npreempted by the higher priority softirq RT task. Before\npreemption, we check to see if current can readily move to a\ndifferent cpu. If so, we will reschedule to allow the RT push logic\nto try to move current somewhere else. Whenever the woken\nsoftirq RT task runs, it first tries to migrate the user FIFO RT\ntask over to a cpu that is running a task of lesser priority. If\nmigration is done, it will send a reschedule request to the found\ncpu by IPI interrupt. Once the target cpu responds the IPI\ninterrupt, it will pick the migrated user RT task to preempt its\ncurrent task. When the user RT task is running on the new cpu,\nthe sched timer tick of the cpu fires. So it will tick the user\nRT task again. This also means the RT task timeout value will be\nupdated again. As the migration may be done in one tick period,\nit means the user RT task timeout value will be updated twice\nwithin one tick.\n\nIf we set a limit on the amount of cpu time for the user RT task\nby setrlimit(RLIMIT_RTTIME), the SIGXCPU signal should be posted\nupon reaching the soft limit.\n\nBut exactly when the SIGXCPU signal should be sent depends on the\nRT task timeout value. In fact the timeout mechanism of sending\nthe SIGXCPU signal assumes the RT task timeout is increased once\nevery tick.\n\nHowever, currently the timeout value may be added twice per\ntick. So it results in the SIGXCPU signal being sent earlier\nthan expected.\n\nTo solve this issue, we prevent the timeout value from increasing\ntwice within one tick time by remembering the jiffies value of\nlast updating the timeout. As long as the RT task\u0027s jiffies is\ndifferent with the global jiffies value, we allow its timeout to\nbe updated.\n\nSigned-off-by: Ying Xue \u003cying.xue@windriver.com\u003e\nSigned-off-by: Fan Du \u003cfan.du@windriver.com\u003e\nReviewed-by: Yong Zhang \u003cyong.zhang0@gmail.com\u003e\nAcked-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/1342508623-2887-1-git-send-email-ying.xue@windriver.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\n[ lizf: backported to 3.4: adjust context ]\nSigned-off-by: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "f61eb9ceb26cee3fdbb8c7a4920f171f7661fb4f",
      "tree": "7ef1b69d19fdc57f57ce58dc78988ce4a653aa8e",
      "parents": [
        "1e5c13ec422f665432bfc9f7c5fc1f9fd614afd3"
      ],
      "author": {
        "name": "Peter Boonstoppel",
        "email": "pboonstoppel@nvidia.com",
        "time": "Thu Aug 09 15:34:47 2012 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 13 11:51:19 2014 -0800"
      },
      "message": "sched: Unthrottle rt runqueues in __disable_runtime()\n\ncommit a4c96ae319b8047f62dedbe1eac79e321c185749 upstream.\n\nmigrate_tasks() uses _pick_next_task_rt() to get tasks from the\nreal-time runqueues to be migrated. When rt_rq is throttled\n_pick_next_task_rt() won\u0027t return anything, in which case\nmigrate_tasks() can\u0027t move all threads over and gets stuck in an\ninfinite loop.\n\nInstead unthrottle rt runqueues before migrating tasks.\n\nAdditionally: move unthrottle_offline_cfs_rqs() to rq_offline_fair()\n\nSigned-off-by: Peter Boonstoppel \u003cpboonstoppel@nvidia.com\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nCc: Paul Turner \u003cpjt@google.com\u003e\nLink: http://lkml.kernel.org/r/5FBF8E85CA34454794F0F7ECBA79798F379D3648B7@HQMAIL04.nvidia.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\n[ lizf: backported to 3.4: adjust context ]\nSigned-off-by: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "1e5c13ec422f665432bfc9f7c5fc1f9fd614afd3",
      "tree": "8588210c14890e4a797a9ea5402d6fa42ba3ceb6",
      "parents": [
        "21b53baf40aecb134593ec74eb787f16c569cfc5"
      ],
      "author": {
        "name": "Mike Galbraith",
        "email": "efault@gmx.de",
        "time": "Tue Aug 07 10:02:38 2012 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 13 11:51:18 2014 -0800"
      },
      "message": "sched,rt: fix isolated CPUs leaving root_task_group indefinitely throttled\n\ncommit e221d028bb08b47e624c5f0a31732c642db9d19a upstream.\n\nRoot task group bandwidth replenishment must service all CPUs, regardless of\nwhere the timer was last started, and regardless of the isolation mechanism,\nlest \u0027Quoth the Raven, \"Nevermore\"\u0027 become rt scheduling policy.\n\nSigned-off-by: Mike Galbraith \u003cefault@gmx.de\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLink: http://lkml.kernel.org/r/1344326558.6968.25.camel@marge.simpson.net\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "21b53baf40aecb134593ec74eb787f16c569cfc5",
      "tree": "c4c8bb46216c1baf4fe84d8787f5f6b7e01fe2f9",
      "parents": [
        "d5c20298b6d817b069c69d94df9cd8ed76b2ff15"
      ],
      "author": {
        "name": "Colin Cross",
        "email": "ccross@android.com",
        "time": "Wed May 16 21:34:23 2012 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Thu Feb 13 11:51:18 2014 -0800"
      },
      "message": "sched/rt: Fix SCHED_RR across cgroups\n\ncommit 454c79999f7eaedcdf4c15c449e43902980cbdf5 upstream.\n\ntask_tick_rt() has an optimization to only reschedule SCHED_RR tasks\nif they were the only element on their rq.  However, with cgroups\na SCHED_RR task could be the only element on its per-cgroup rq but\nstill be competing with other SCHED_RR tasks in its parent\u0027s\ncgroup.  In this case, the SCHED_RR task in the child cgroup would\nnever yield at the end of its timeslice.  If the child cgroup\nrt_runtime_us was the same as the parent cgroup rt_runtime_us,\nthe task in the parent cgroup would starve completely.\n\nModify task_tick_rt() to check that the task is the only task on its\nrq, and that the each of the scheduling entities of its ancestors\nis also the only entity on its rq.\n\nSigned-off-by: Colin Cross \u003cccross@android.com\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLink: http://lkml.kernel.org/r/1337229266-15798-1-git-send-email-ccross@android.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "9af6b695ac764184cdbdd42b77da3e600d337d14",
      "tree": "c4a5ae98b8872f62d290396b457f72d57ac72330",
      "parents": [
        "03d35a39f4de9f2e9d7fbc5c2d03dbcc5b882df7"
      ],
      "author": {
        "name": "Paul Turner",
        "email": "pjt@google.com",
        "time": "Wed Oct 16 11:16:27 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jan 15 15:27:12 2014 -0800"
      },
      "message": "sched: Guarantee new group-entities always have weight\n\ncommit 0ac9b1c21874d2490331233b3242085f8151e166 upstream.\n\nCurrently, group entity load-weights are initialized to zero. This\nadmits some races with respect to the first time they are re-weighted in\nearlty use. ( Let g[x] denote the se for \"g\" on cpu \"x\". )\n\nSuppose that we have root-\u003ea and that a enters a throttled state,\nimmediately followed by a[0]-\u003et1 (the only task running on cpu[0])\nblocking:\n\n  put_prev_task(group_cfs_rq(a[0]), t1)\n  put_prev_entity(..., t1)\n  check_cfs_rq_runtime(group_cfs_rq(a[0]))\n  throttle_cfs_rq(group_cfs_rq(a[0]))\n\nThen, before unthrottling occurs, let a[0]-\u003eb[0]-\u003et2 wake for the first\ntime:\n\n  enqueue_task_fair(rq[0], t2)\n  enqueue_entity(group_cfs_rq(b[0]), t2)\n  enqueue_entity_load_avg(group_cfs_rq(b[0]), t2)\n  account_entity_enqueue(group_cfs_ra(b[0]), t2)\n  update_cfs_shares(group_cfs_rq(b[0]))\n  \u003c skipped because b is part of a throttled hierarchy \u003e\n  enqueue_entity(group_cfs_rq(a[0]), b[0])\n  ...\n\nWe now have b[0] enqueued, yet group_cfs_rq(a[0])-\u003eload.weight \u003d\u003d 0\nwhich violates invariants in several code-paths. Eliminate the\npossibility of this by initializing group entity weight.\n\nSigned-off-by: Paul Turner \u003cpjt@google.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/20131016181627.22647.47543.stgit@sword-of-the-dawn.mtv.corp.google.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Chris J Arges \u003cchris.j.arges@canonical.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "03d35a39f4de9f2e9d7fbc5c2d03dbcc5b882df7",
      "tree": "be90a817103d24c521ba427819374fd0600cef40",
      "parents": [
        "9b318052acd24780f4dba1349ef3a30a7aef52ad"
      ],
      "author": {
        "name": "Ben Segall",
        "email": "bsegall@google.com",
        "time": "Wed Oct 16 11:16:22 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jan 15 15:27:11 2014 -0800"
      },
      "message": "sched: Fix hrtimer_cancel()/rq-\u003elock deadlock\n\ncommit 927b54fccbf04207ec92f669dce6806848cbec7d upstream.\n\n__start_cfs_bandwidth calls hrtimer_cancel while holding rq-\u003elock,\nwaiting for the hrtimer to finish. However, if sched_cfs_period_timer\nruns for another loop iteration, the hrtimer can attempt to take\nrq-\u003elock, resulting in deadlock.\n\nFix this by ensuring that cfs_b-\u003etimer_active is cleared only if the\n_latest_ call to do_sched_cfs_period_timer is returning as idle. Then\n__start_cfs_bandwidth can just call hrtimer_try_to_cancel and wait for\nthat to succeed or timer_active \u003d\u003d 1.\n\nSigned-off-by: Ben Segall \u003cbsegall@google.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: pjt@google.com\nLink: http://lkml.kernel.org/r/20131016181622.22647.16643.stgit@sword-of-the-dawn.mtv.corp.google.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Chris J Arges \u003cchris.j.arges@canonical.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "9b318052acd24780f4dba1349ef3a30a7aef52ad",
      "tree": "0e64c6925ec778aee88dad406f04c83763ee210c",
      "parents": [
        "16e7480c23d33d9475d45be92c1ddf218575a647"
      ],
      "author": {
        "name": "Ben Segall",
        "email": "bsegall@google.com",
        "time": "Wed Oct 16 11:16:17 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jan 15 15:27:11 2014 -0800"
      },
      "message": "sched: Fix cfs_bandwidth misuse of hrtimer_expires_remaining\n\ncommit db06e78cc13d70f10877e0557becc88ab3ad2be8 upstream.\n\nhrtimer_expires_remaining does not take internal hrtimer locks and thus\nmust be guarded against concurrent __hrtimer_start_range_ns (but\nreturning HRTIMER_RESTART is safe). Use cfs_b-\u003elock to make it safe.\n\nSigned-off-by: Ben Segall \u003cbsegall@google.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: pjt@google.com\nLink: http://lkml.kernel.org/r/20131016181617.22647.73829.stgit@sword-of-the-dawn.mtv.corp.google.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Chris J Arges \u003cchris.j.arges@canonical.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "16e7480c23d33d9475d45be92c1ddf218575a647",
      "tree": "7cf3d25a05f42f95407ab5ea844d88ce451164ec",
      "parents": [
        "a63f31f1f2cdb459b121f644ccbd07ae84f45d4e"
      ],
      "author": {
        "name": "Ben Segall",
        "email": "bsegall@google.com",
        "time": "Wed Oct 16 11:16:12 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jan 15 15:27:11 2014 -0800"
      },
      "message": "sched: Fix race on toggling cfs_bandwidth_used\n\ncommit 1ee14e6c8cddeeb8a490d7b54cd9016e4bb900b4 upstream.\n\nWhen we transition cfs_bandwidth_used to false, any currently\nthrottled groups will incorrectly return false from cfs_rq_throttled.\nWhile tg_set_cfs_bandwidth will unthrottle them eventually, currently\nrunning code (including at least dequeue_task_fair and\ndistribute_cfs_runtime) will cause errors.\n\nFix this by turning off cfs_bandwidth_used only after unthrottling all\ncfs_rqs.\n\nTested: toggle bandwidth back and forth on a loaded cgroup. Caused\ncrashes in minutes without the patch, hasn\u0027t crashed with it.\n\nSigned-off-by: Ben Segall \u003cbsegall@google.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: pjt@google.com\nLink: http://lkml.kernel.org/r/20131016181611.22647.80365.stgit@sword-of-the-dawn.mtv.corp.google.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Chris J Arges \u003cchris.j.arges@canonical.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "dfb473b35096a0ffae221c7eeb49c34882ea6f9c",
      "tree": "a071f807c029cc0d39a46bceffea0f7c7990f7f3",
      "parents": [
        "05bbcdd32afbfd520c71ae8104a8bf531aed9163"
      ],
      "author": {
        "name": "Ben Segall",
        "email": "bsegall@google.com",
        "time": "Wed Oct 16 11:16:32 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jan 08 09:42:12 2014 -0800"
      },
      "message": "sched: Avoid throttle_cfs_rq() racing with period_timer stopping\n\ncommit f9f9ffc237dd924f048204e8799da74f9ecf40cf upstream.\n\nthrottle_cfs_rq() doesn\u0027t check to make sure that period_timer is running,\nand while update_curr/assign_cfs_runtime does, a concurrently running\nperiod_timer on another cpu could cancel itself between this cpu\u0027s\nupdate_curr and throttle_cfs_rq(). If there are no other cfs_rqs running\nin the tg to restart the timer, this causes the cfs_rq to be stranded\nforever.\n\nFix this by calling __start_cfs_bandwidth() in throttle if the timer is\ninactive.\n\n(Also add some sched_debug lines for cfs_bandwidth.)\n\nTested: make a run/sleep task in a cgroup, loop switching the cgroup\nbetween 1ms/100ms quota and unlimited, checking for timer_active\u003d0 and\nthrottled\u003d1 as a failure. With the throttle_cfs_rq() change commented out\nthis fails, with the full patch it passes.\n\nSigned-off-by: Ben Segall \u003cbsegall@google.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: pjt@google.com\nLink: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.com\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Chris J Arges \u003cchris.j.arges@canonical.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n"
    },
    {
      "commit": "3f8878956c833443d6c6e498e9ed6a18ee30e0f5",
      "tree": "4d82b3f085f1085301ebee2c9415ff13c09af66b",
      "parents": [
        "a1192c0e5d037def6763f3873d3340615c241fe7"
      ],
      "author": {
        "name": "Kirill Tkhai",
        "email": "tkhai@yandex.ru",
        "time": "Wed Nov 27 19:59:13 2013 +0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jan 08 09:42:11 2014 -0800"
      },
      "message": "sched/rt: Fix rq\u0027s cpupri leak while enqueue/dequeue child RT entities\n\ncommit 757dfcaa41844595964f1220f1d33182dae49976 upstream.\n\nThis patch touches the RT group scheduling case.\n\nFunctions inc_rt_prio_smp() and dec_rt_prio_smp() change (global) rq\u0027s\npriority, while rt_rq passed to them may be not the top-level rt_rq.\nThis is wrong, because changing of priority on a child level does not\nguarantee that the priority is the highest all over the rq. So, this\nleak makes RT balancing unusable.\n\nThe short example: the task having the highest priority among all rq\u0027s\nRT tasks (no one other task has the same priority) are waking on a\nthrottle rt_rq.  The rq\u0027s cpupri is set to the task\u0027s priority\nequivalent, but real rq-\u003ert.highest_prio.curr is less.\n\nThe patch below fixes the problem.\n\nSigned-off-by: Kirill Tkhai \u003ctkhai@yandex.ru\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCC: Steven Rostedt \u003crostedt@goodmis.org\u003e\nLink: http://lkml.kernel.org/r/49231385567953@web4m.yandex.ru\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "09951c9b33f8cfdc0e8c4e03fe83bc66c9d908dc",
      "tree": "4b5081c15d8231b7cb2adbb0d06a6e9f0d531150",
      "parents": [
        "58c2314ac41e8f24a2a594bd866915e38de9648e"
      ],
      "author": {
        "name": "Miao Xie",
        "email": "miaox@cn.fujitsu.com",
        "time": "Mon Dec 16 15:20:01 2013 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Jan 08 09:42:10 2014 -0800"
      },
      "message": "ftrace: Initialize the ftrace profiler for each possible cpu\n\ncommit c4602c1c818bd6626178d6d3fcc152d9f2f48ac0 upstream.\n\nFtrace currently initializes only the online CPUs. This implementation has\ntwo problems:\n- If we online a CPU after we enable the function profile, and then run the\n  test, we will lose the trace information on that CPU.\n  Steps to reproduce:\n  # echo 0 \u003e /sys/devices/system/cpu/cpu1/online\n  # cd \u003cdebugfs\u003e/tracing/\n  # echo \u003csome function name\u003e \u003e\u003e set_ftrace_filter\n  # echo 1 \u003e function_profile_enabled\n  # echo 1 \u003e /sys/devices/system/cpu/cpu1/online\n  # run test\n- If we offline a CPU before we enable the function profile, we will not clear\n  the trace information when we enable the function profile. It will trouble\n  the users.\n  Steps to reproduce:\n  # cd \u003cdebugfs\u003e/tracing/\n  # echo \u003csome function name\u003e \u003e\u003e set_ftrace_filter\n  # echo 1 \u003e function_profile_enabled\n  # run test\n  # cat trace_stat/function*\n  # echo 0 \u003e /sys/devices/system/cpu/cpu1/online\n  # echo 0 \u003e function_profile_enabled\n  # echo 1 \u003e function_profile_enabled\n  # cat trace_stat/function*\n  # run test\n  # cat trace_stat/function*\n\nSo it is better that we initialize the ftrace profiler for each possible cpu\nevery time we enable the function profile instead of just the online ones.\n\nLink: http://lkml.kernel.org/r/1387178401-10619-1-git-send-email-miaox@cn.fujitsu.com\n\nSigned-off-by: Miao Xie \u003cmiaox@cn.fujitsu.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "ee4bb2579e1182fa013694e429e6a418d6a3bb78",
      "tree": "be191e1d57a70b5fab0a943b2f4b05f1841a1086",
      "parents": [
        "894a160626d09198b104ea6702d688eca90623ad"
      ],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Thu Dec 12 09:38:42 2013 -0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Fri Dec 20 07:34:19 2013 -0800"
      },
      "message": "futex: fix handling of read-only-mapped hugepages\n\ncommit f12d5bfceb7e1f9051563381ec047f7f13956c3c upstream.\n\nThe hugepage code had the exact same bug that regular pages had in\ncommit 7485d0d3758e (\"futexes: Remove rw parameter from\nget_futex_key()\").\n\nThe regular page case was fixed by commit 9ea71503a8ed (\"futex: Fix\nregression with read only mappings\"), but the transparent hugepage case\n(added in a5b338f2b0b1: \"thp: update futex compound knowledge\") case\nremained broken.\n\nFound by Dave Jones and his trinity tool.\n\nReported-and-tested-by: Dave Jones \u003cdavej@fedoraproject.org\u003e\nAcked-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Mel Gorman \u003cmgorman@suse.de\u003e\nCc: Darren Hart \u003cdvhart@linux.intel.com\u003e\nCc: Andrea Arcangeli \u003caarcange@redhat.com\u003e\nCc: Oleg Nesterov \u003coleg@redhat.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "a8000959881be86ee8e5262d305f12accb68db70",
      "tree": "6a9b8dda7fdc42309c99584682f75f357acd067e",
      "parents": [
        "8dd978fba2216c985d6ca0801b698dae7363d1dc"
      ],
      "author": {
        "name": "Laxman Dewangan",
        "email": "ldewangan@nvidia.com",
        "time": "Mon Nov 25 19:39:47 2013 +0530"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 11 22:34:11 2013 -0800"
      },
      "message": "irq: Enable all irqs unconditionally in irq_resume\n\ncommit ac01810c9d2814238f08a227062e66a35a0e1ea2 upstream.\n\nWhen the system enters suspend, it disables all interrupts in\nsuspend_device_irqs(), including the interrupts marked EARLY_RESUME.\n\nOn the resume side things are different. The EARLY_RESUME interrupts\nare reenabled in sys_core_ops-\u003eresume and the non EARLY_RESUME\ninterrupts are reenabled in the normal system resume path.\n\nWhen suspend_noirq() failed or suspend is aborted for any other\nreason, we might omit the resume side call to sys_core_ops-\u003eresume()\nand therefor the interrupts marked EARLY_RESUME are not reenabled and\nstay disabled forever.\n\nTo solve this, enable all irqs unconditionally in irq_resume()\nregardless whether interrupts marked EARLY_RESUMEhave been already\nenabled or not.\n\nThis might try to reenable already enabled interrupts in the non\nfailure case, but the only affected platform is XEN and it has been\nconfirmed that it does not cause any side effects.\n\n[ tglx: Massaged changelog. ]\n\nSigned-off-by: Laxman Dewangan \u003cldewangan@nvidia.com\u003e\nAcked-by-and-tested-by: Konrad Rzeszutek Wilk \u003ckonrad.wilk@oracle.com\u003e\nAcked-by: Heiko Stuebner \u003cheiko@sntech.de\u003e\nReviewed-by: Pavel Machek \u003cpavel@ucw.cz\u003e\nCc: \u003cian.campbell@citrix.com\u003e\nCc: \u003crjw@rjwysocki.net\u003e\nCc: \u003clen.brown@intel.com\u003e\nCc: \u003cgregkh@linuxfoundation.org\u003e\nLink: http://lkml.kernel.org/r/1385388587-16442-1-git-send-email-ldewangan@nvidia.com\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "51d351d5b949ae7204696ada7ef502ed34d34fb0",
      "tree": "f5b337191f35ac1a8b64aebad36479ed52d8beee",
      "parents": [
        "5833570f8e15cd7a40dd6c14ec73cb53736048cf"
      ],
      "author": {
        "name": "Steven Rostedt (Red Hat)",
        "email": "rostedt@goodmis.org",
        "time": "Mon Nov 25 20:59:46 2013 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 04 10:50:34 2013 -0800"
      },
      "message": "ftrace: Fix function graph with loading of modules\n\ncommit 8a56d7761d2d041ae5e8215d20b4167d8aa93f51 upstream.\n\nCommit 8c4f3c3fa9681 \"ftrace: Check module functions being traced on reload\"\nfixed module loading and unloading with respect to function tracing, but\nit missed the function graph tracer. If you perform the following\n\n # cd /sys/kernel/debug/tracing\n # echo function_graph \u003e current_tracer\n # modprobe nfsd\n # echo nop \u003e current_tracer\n\nYou\u0027ll get the following oops message:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 2910 at /linux.git/kernel/trace/ftrace.c:1640 __ftrace_hash_rec_update.part.35+0x168/0x1b9()\n Modules linked in: nfsd exportfs nfs_acl lockd ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt\n CPU: 2 PID: 2910 Comm: bash Not tainted 3.13.0-rc1-test #7\n Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007\n  0000000000000668 ffff8800787efcf8 ffffffff814fe193 ffff88007d500000\n  0000000000000000 ffff8800787efd38 ffffffff8103b80a 0000000000000668\n  ffffffff810b2b9a ffffffff81a48370 0000000000000001 ffff880037aea000\n Call Trace:\n  [\u003cffffffff814fe193\u003e] dump_stack+0x4f/0x7c\n  [\u003cffffffff8103b80a\u003e] warn_slowpath_common+0x81/0x9b\n  [\u003cffffffff810b2b9a\u003e] ? __ftrace_hash_rec_update.part.35+0x168/0x1b9\n  [\u003cffffffff8103b83e\u003e] warn_slowpath_null+0x1a/0x1c\n  [\u003cffffffff810b2b9a\u003e] __ftrace_hash_rec_update.part.35+0x168/0x1b9\n  [\u003cffffffff81502f89\u003e] ? __mutex_lock_slowpath+0x364/0x364\n  [\u003cffffffff810b2cc2\u003e] ftrace_shutdown+0xd7/0x12b\n  [\u003cffffffff810b47f0\u003e] unregister_ftrace_graph+0x49/0x78\n  [\u003cffffffff810c4b30\u003e] graph_trace_reset+0xe/0x10\n  [\u003cffffffff810bf393\u003e] tracing_set_tracer+0xa7/0x26a\n  [\u003cffffffff810bf5e1\u003e] tracing_set_trace_write+0x8b/0xbd\n  [\u003cffffffff810c501c\u003e] ? ftrace_return_to_handler+0xb2/0xde\n  [\u003cffffffff811240a8\u003e] ? __sb_end_write+0x5e/0x5e\n  [\u003cffffffff81122aed\u003e] vfs_write+0xab/0xf6\n  [\u003cffffffff8150a185\u003e] ftrace_graph_caller+0x85/0x85\n  [\u003cffffffff81122dbd\u003e] SyS_write+0x59/0x82\n  [\u003cffffffff8150a185\u003e] ftrace_graph_caller+0x85/0x85\n  [\u003cffffffff8150a2d2\u003e] system_call_fastpath+0x16/0x1b\n ---[ end trace 940358030751eafb ]---\n\nThe above mentioned commit didn\u0027t go far enough. Well, it covered the\nfunction tracer by adding checks in __register_ftrace_function(). The\nproblem is that the function graph tracer circumvents that (for a slight\nefficiency gain when function graph trace is running with a function\ntracer. The gain was not worth this).\n\nThe problem came with ftrace_startup() which should always be called after\n__register_ftrace_function(), if you want this bug to be completely fixed.\n\nAnyway, this solution moves __register_ftrace_function() inside of\nftrace_startup() and removes the need to call them both.\n\nReported-by: Dave Wysochanski \u003cdwysocha@redhat.com\u003e\nFixes: ed926f9b35cd (\"ftrace: Use counters to enable functions to trace\")\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n\n"
    },
    {
      "commit": "fe094c412973269d2fad2e04a852771570e8edf1",
      "tree": "d0685972fcf58607e98dfe82ffa150b2f3519c09",
      "parents": [
        "df29bdd478affb8d81620e43e70635bef110a20e"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "peterz@infradead.org",
        "time": "Tue Nov 26 15:03:41 2013 +0100"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 04 10:50:34 2013 -0800"
      },
      "message": "cpuset: Fix memory allocator deadlock\n\ncommit 0fc0287c9ed1ffd3706f8b4d9b314aa102ef1245 upstream.\n\nJuri hit the below lockdep report:\n\n[    4.303391] \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n[    4.303392] [ INFO: SOFTIRQ-safe -\u003e SOFTIRQ-unsafe lock order detected ]\n[    4.303394] 3.12.0-dl-peterz+ #144 Not tainted\n[    4.303395] ------------------------------------------------------\n[    4.303397] kworker/u4:3/689 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:\n[    4.303399]  (\u0026p-\u003emems_allowed_seq){+.+...}, at: [\u003cffffffff8114e63c\u003e] new_slab+0x6c/0x290\n[    4.303417]\n[    4.303417] and this task is already holding:\n[    4.303418]  (\u0026(\u0026q-\u003e__queue_lock)-\u003erlock){..-...}, at: [\u003cffffffff812d2dfb\u003e] blk_execute_rq_nowait+0x5b/0x100\n[    4.303431] which would create a new lock dependency:\n[    4.303432]  (\u0026(\u0026q-\u003e__queue_lock)-\u003erlock){..-...} -\u003e (\u0026p-\u003emems_allowed_seq){+.+...}\n[    4.303436]\n\n[    4.303898] the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock:\n[    4.303918] -\u003e (\u0026p-\u003emems_allowed_seq){+.+...} ops: 2762 {\n[    4.303922]    HARDIRQ-ON-W at:\n[    4.303923]                     [\u003cffffffff8108ab9a\u003e] __lock_acquire+0x65a/0x1ff0\n[    4.303926]                     [\u003cffffffff8108cbe3\u003e] lock_acquire+0x93/0x140\n[    4.303929]                     [\u003cffffffff81063dd6\u003e] kthreadd+0x86/0x180\n[    4.303931]                     [\u003cffffffff816ded6c\u003e] ret_from_fork+0x7c/0xb0\n[    4.303933]    SOFTIRQ-ON-W at:\n[    4.303933]                     [\u003cffffffff8108abcc\u003e] __lock_acquire+0x68c/0x1ff0\n[    4.303935]                     [\u003cffffffff8108cbe3\u003e] lock_acquire+0x93/0x140\n[    4.303940]                     [\u003cffffffff81063dd6\u003e] kthreadd+0x86/0x180\n[    4.303955]                     [\u003cffffffff816ded6c\u003e] ret_from_fork+0x7c/0xb0\n[    4.303959]    INITIAL USE at:\n[    4.303960]                    [\u003cffffffff8108a884\u003e] __lock_acquire+0x344/0x1ff0\n[    4.303963]                    [\u003cffffffff8108cbe3\u003e] lock_acquire+0x93/0x140\n[    4.303966]                    [\u003cffffffff81063dd6\u003e] kthreadd+0x86/0x180\n[    4.303969]                    [\u003cffffffff816ded6c\u003e] ret_from_fork+0x7c/0xb0\n[    4.303972]  }\n\nWhich reports that we take mems_allowed_seq with interrupts enabled. A\nlittle digging found that this can only be from\ncpuset_change_task_nodemask().\n\nThis is an actual deadlock because an interrupt doing an allocation will\nhit get_mems_allowed()-\u003e...-\u003e__read_seqcount_begin(), which will spin\nforever waiting for the write side to complete.\n\nCc: John Stultz \u003cjohn.stultz@linaro.org\u003e\nCc: Mel Gorman \u003cmgorman@suse.de\u003e\nReported-by: Juri Lelli \u003cjuri.lelli@gmail.com\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nTested-by: Juri Lelli \u003cjuri.lelli@gmail.com\u003e\nAcked-by: Li Zefan \u003clizefan@huawei.com\u003e\nAcked-by: Mel Gorman \u003cmgorman@suse.de\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "4e0c56ab133fcb29fa3709c095f9347a033662c1",
      "tree": "4ddbc8a55d63d790669e6319b037870b4166005e",
      "parents": [
        "42979968049cc6a8ed569ae8ceb486e0637c7ce7"
      ],
      "author": {
        "name": "Mathias Krause",
        "email": "minipli@googlemail.com",
        "time": "Mon Sep 30 22:04:24 2013 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 04 10:50:32 2013 -0800"
      },
      "message": "audit: fix info leak in AUDIT_GET requests\n\ncommit 64fbff9ae0a0a843365d922e0057fc785f23f0e3 upstream.\n\nWe leak 4 bytes of kernel stack in response to an AUDIT_GET request as\nwe miss to initialize the mask member of status_set. Fix that.\n\nCc: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Eric Paris \u003ceparis@redhat.com\u003e\nSigned-off-by: Mathias Krause \u003cminipli@googlemail.com\u003e\nSigned-off-by: Richard Guy Briggs \u003crgb@redhat.com\u003e\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "42979968049cc6a8ed569ae8ceb486e0637c7ce7",
      "tree": "8e7f4c4af4dc50d16a46d74ea1a8f9beb1cbab99",
      "parents": [
        "e49ee6c66ebfdf4a4fb0cecad2523c7b61fc0282"
      ],
      "author": {
        "name": "Mathias Krause",
        "email": "minipli@googlemail.com",
        "time": "Mon Sep 30 22:04:25 2013 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 04 10:50:31 2013 -0800"
      },
      "message": "audit: use nlmsg_len() to get message payload length\n\ncommit 4d8fe7376a12bf4524783dd95cbc00f1fece6232 upstream.\n\nUsing the nlmsg_len member of the netlink header to test if the message\nis valid is wrong as it includes the size of the netlink header itself.\nThereby allowing to send short netlink messages that pass those checks.\n\nUse nlmsg_len() instead to test for the right message length. The result\nof nlmsg_len() is guaranteed to be non-negative as the netlink message\nalready passed the checks of nlmsg_ok().\n\nAlso switch to min_t() to please checkpatch.pl.\n\nCc: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Eric Paris \u003ceparis@redhat.com\u003e\nSigned-off-by: Mathias Krause \u003cminipli@googlemail.com\u003e\nSigned-off-by: Richard Guy Briggs \u003crgb@redhat.com\u003e\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "e49ee6c66ebfdf4a4fb0cecad2523c7b61fc0282",
      "tree": "6106bc4fc818042ebfb97476a4a1c1cd04572ec9",
      "parents": [
        "d4bb402d7bda612a91235444dd4cf29b464f8eec"
      ],
      "author": {
        "name": "Tyler Hicks",
        "email": "tyhicks@canonical.com",
        "time": "Thu Jul 25 18:02:55 2013 -0700"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 04 10:50:31 2013 -0800"
      },
      "message": "audit: printk USER_AVC messages when audit isn\u0027t enabled\n\ncommit 0868a5e150bc4c47e7a003367cd755811eb41e0b upstream.\n\nWhen the audit\u003d1 kernel parameter is absent and auditd is not running,\nAUDIT_USER_AVC messages are being silently discarded.\n\nAUDIT_USER_AVC messages should be sent to userspace using printk(), as\nmentioned in the commit message of 4a4cd633 (\"AUDIT: Optimise the\naudit-disabled case for discarding user messages\").\n\nWhen audit_enabled is 0, audit_receive_msg() discards all user messages\nexcept for AUDIT_USER_AVC messages. However, audit_log_common_recv_msg()\nrefuses to allocate an audit_buffer if audit_enabled is 0. The fix is to\nspecial case AUDIT_USER_AVC messages in both functions.\n\nIt looks like commit 50397bd1 (\"[AUDIT] clean up audit_receive_msg()\")\nintroduced this bug.\n\nSigned-off-by: Tyler Hicks \u003ctyhicks@canonical.com\u003e\nCc: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Eric Paris \u003ceparis@redhat.com\u003e\nCc: linux-audit@redhat.com\nAcked-by: Kees Cook \u003ckeescook@chromium.org\u003e\nSigned-off-by: Richard Guy Briggs \u003crgb@redhat.com\u003e\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "7094547c201149598a2bd90ef7f04d477dffae1b",
      "tree": "1322f341512653df7c5a93b4a26fed9aaf24217f",
      "parents": [
        "3ccb527f871a225b8eada036d24d41c59e40a2e4"
      ],
      "author": {
        "name": "Aaron Lu",
        "email": "aaron.lu@intel.com",
        "time": "Wed Nov 06 08:41:31 2013 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 04 10:50:31 2013 -0800"
      },
      "message": "PM / hibernate: Avoid overflow in hibernate_preallocate_memory()\n\ncommit fd432b9f8c7c88428a4635b9f5a9c6e174df6e36 upstream.\n\nWhen system has a lot of highmem (e.g. 16GiB using a 32 bits kernel),\nthe code to calculate how much memory we need to preallocate in\nnormal zone may cause overflow. As Leon has analysed:\n\n It looks that during computing \u0027alloc\u0027 variable there is overflow:\n alloc \u003d (3943404 - 1970542) - 1978280 \u003d -5418 (signed)\n And this function goes to err_out.\n\nFix this by avoiding that overflow.\n\nReferences: https://bugzilla.kernel.org/show_bug.cgi?id\u003d60817\nReported-and-tested-by: Leon Drugi \u003ceyak@wp.pl\u003e\nSigned-off-by: Aaron Lu \u003caaron.lu@intel.com\u003e\nSigned-off-by: Rafael J. Wysocki \u003crafael.j.wysocki@intel.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "3e05092412210f3a298ef2a4e5f58857513e9954",
      "tree": "d9bb8d5c47986907e7ac939ef90cad5a32708c2b",
      "parents": [
        "664eaaa26bca6272673eff01ba5468f95905039d"
      ],
      "author": {
        "name": "KOSAKI Motohiro",
        "email": "kosaki.motohiro@jp.fujitsu.com",
        "time": "Mon Oct 14 17:33:16 2013 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Dec 04 10:50:14 2013 -0800"
      },
      "message": "alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn\u0027t exist\n\ncommit 98d6f4dd84a134d942827584a3c5f67ffd8ec35f upstream.\n\nFedora Ruby maintainer reported latest Ruby doesn\u0027t work on Fedora Rawhide\non ARM. (http://bugs.ruby-lang.org/issues/9008)\n\nBecause of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no\nRTC device is present) intruduced to return ENOTSUPP when\nclock_get{time,res} can\u0027t find a RTC device. However this is incorrect.\n\nFirst, ENOTSUPP isn\u0027t exported to userland (ENOTSUP or EOPNOTSUP are the\nclosest userland equivlents).\n\nSecond, Posix and Linux man pages agree that clock_gettime and\nclock_getres should return EINVAL if clk_id argument is invalid.\nWhile the arugment that the clockid is valid, but just not supported\non this hardware could be made, this is just a technicality that\ndoesn\u0027t help userspace applicaitons, and only complicates error\nhandling.\n\nThus, this patch changes the code to use EINVAL.\n\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nReported-by: Vit Ondruch \u003cv.ondruch@tiscali.cz\u003e\nSigned-off-by: KOSAKI Motohiro \u003ckosaki.motohiro@jp.fujitsu.com\u003e\n[jstultz: Tweaks to commit message to include full rational]\nSigned-off-by: John Stultz \u003cjohn.stultz@linaro.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "c0d30628ff1b424f041d83fee37daea5f84eb0a2",
      "tree": "d7bc2b3b5824eeddeb687c3547c21984e1d6c422",
      "parents": [
        "7288f91dd5b55d82e1dee9f0d24e9f4730d57392"
      ],
      "author": {
        "name": "Kees Cook",
        "email": "keescook@chromium.org",
        "time": "Tue Nov 12 15:11:17 2013 -0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Fri Nov 29 10:50:34 2013 -0800"
      },
      "message": "exec/ptrace: fix get_dumpable() incorrect tests\n\ncommit d049f74f2dbe71354d43d393ac3a188947811348 upstream.\n\nThe get_dumpable() return value is not boolean.  Most users of the\nfunction actually want to be testing for non-SUID_DUMP_USER(1) rather than\nSUID_DUMP_DISABLE(0).  The SUID_DUMP_ROOT(2) is also considered a\nprotected state.  Almost all places did this correctly, excepting the two\nplaces fixed in this patch.\n\nWrong logic:\n    if (dumpable \u003d\u003d SUID_DUMP_DISABLE) { /* be protective */ }\n        or\n    if (dumpable \u003d\u003d 0) { /* be protective */ }\n        or\n    if (!dumpable) { /* be protective */ }\n\nCorrect logic:\n    if (dumpable !\u003d SUID_DUMP_USER) { /* be protective */ }\n        or\n    if (dumpable !\u003d 1) { /* be protective */ }\n\nWithout this patch, if the system had set the sysctl fs/suid_dumpable\u003d2, a\nuser was able to ptrace attach to processes that had dropped privileges to\nthat user.  (This may have been partially mitigated if Yama was enabled.)\n\nThe macros have been moved into the file that declares get/set_dumpable(),\nwhich means things like the ia64 code can see them too.\n\nCVE-2013-2929\n\nReported-by: Vasily Kulikov \u003csegoon@openwall.com\u003e\nSigned-off-by: Kees Cook \u003ckeescook@chromium.org\u003e\nCc: \"Luck, Tony\" \u003ctony.luck@intel.com\u003e\nCc: Oleg Nesterov \u003coleg@redhat.com\u003e\nCc: \"Eric W. Biederman\" \u003cebiederm@xmission.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "d134082b7a9bb0e09158a2cc2e551841a84ddfa7",
      "tree": "867255fbc644ae386cb93323401437f9167cce7e",
      "parents": [
        "f22ff9d05def87a049c5c8c7b86539bd4f8e3172"
      ],
      "author": {
        "name": "Steven Rostedt",
        "email": "rostedt@goodmis.org",
        "time": "Tue Nov 05 12:51:11 2013 -0500"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Fri Nov 29 10:50:33 2013 -0800"
      },
      "message": "perf/ftrace: Fix paranoid level for enabling function tracer\n\ncommit 12ae030d54ef250706da5642fc7697cc60ad0df7 upstream.\n\nThe current default perf paranoid level is \"1\" which has\n\"perf_paranoid_kernel()\" return false, and giving any operations that\nuse it, access to normal users. Unfortunately, this includes function\ntracing and normal users should not be allowed to enable function\ntracing by default.\n\nThe proper level is defined at \"-1\" (full perf access), which\n\"perf_paranoid_tracepoint_raw()\" will only give access to. Use that\ncheck instead for enabling function tracing.\n\nReported-by: Dave Jones \u003cdavej@redhat.com\u003e\nReported-by: Vince Weaver \u003cvincent.weaver@maine.edu\u003e\nTested-by: Vince Weaver \u003cvincent.weaver@maine.edu\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Jiri Olsa \u003cjolsa@redhat.com\u003e\nCc: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nCVE: CVE-2013-2930\nFixes: ced39002f5ea (\"ftrace, perf: Add support to use function tracepoint in perf\")\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "af15b7691766d99f0f84bae9b3444ab06e9beb29",
      "tree": "5d22a78374519c3feeabeaddad7e4f0fb58360a6",
      "parents": [
        "9736cb3f9aa9c620965d937f4ff0261f6ac32ee1"
      ],
      "author": {
        "name": "Steven Rostedt",
        "email": "rostedt@goodmis.org",
        "time": "Wed Oct 09 22:23:23 2013 -0400"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Nov 20 10:43:19 2013 -0800"
      },
      "message": "tracing: Fix potential out-of-bounds in trace_get_user()\n\ncommit 057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb upstream.\n\nAndrey reported the following report:\n\nERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3\nffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3)\nAccessed by thread T13003:\n  #0 ffffffff810dd2da (asan_report_error+0x32a/0x440)\n  #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40)\n  #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20)\n  #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)\n  #4 ffffffff812a1065 (__fput+0x155/0x360)\n  #5 ffffffff812a12de (____fput+0x1e/0x30)\n  #6 ffffffff8111708d (task_work_run+0x10d/0x140)\n  #7 ffffffff810ea043 (do_exit+0x433/0x11f0)\n  #8 ffffffff810eaee4 (do_group_exit+0x84/0x130)\n  #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30)\n  #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b)\n\nAllocated by thread T5167:\n  #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)\n  #1 ffffffff8128337c (__kmalloc+0xbc/0x500)\n  #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)\n  #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)\n  #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)\n  #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430)\n  #6 ffffffff8129b668 (finish_open+0x68/0xa0)\n  #7 ffffffff812b66ac (do_last+0xb8c/0x1710)\n  #8 ffffffff812b7350 (path_openat+0x120/0xb50)\n  #9 ffffffff812b8884 (do_filp_open+0x54/0xb0)\n  #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)\n  #11 ffffffff8129d4b7 (SyS_open+0x37/0x50)\n  #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b)\n\nShadow bytes around the buggy address:\n  ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd\n  ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa\n  ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n\u003d\u003effff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb\n  ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00\n  ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa\nShadow byte legend (one shadow byte represents 8 application bytes):\n  Addressable:           00\n  Partially addressable: 01 02 03 04 05 06 07\n  Heap redzone:          fa\n  Heap kmalloc redzone:  fb\n  Freed heap region:     fd\n  Shadow gap:            fe\n\nThe out-of-bounds access happens on \u0027parser-\u003ebuffer[parser-\u003eidx] \u003d 0;\u0027\n\nAlthough the crash happened in ftrace_regex_open() the real bug\noccurred in trace_get_user() where there\u0027s an incrementation to\nparser-\u003eidx without a check against the size. The way it is triggered\nis if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop\nthat reads the last character stores it and then breaks out because\nthere is no more characters. Then the last character is read to determine\nwhat to do next, and the index is incremented without checking size.\n\nThen the caller of trace_get_user() usually nulls out the last character\nwith a zero, but since the index is equal to the size, it writes a nul\ncharacter after the allocated space, which can corrupt memory.\n\nLuckily, only root user has write access to this file.\n\nLink: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.home\n\nReported-by: Andrey Konovalov \u003candreyknvl@google.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "f81d0a99446a0c4548d5783807529d075b06c64e",
      "tree": "b0697e8167ee4daf0d8b66f38270670498998f20",
      "parents": [
        "268417aeea96a1941c2cd14f0f8b5b39c374ad25"
      ],
      "author": {
        "name": "Thomas Gleixner",
        "email": "tglx@linutronix.de",
        "time": "Tue Sep 24 21:50:23 2013 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Wed Nov 13 12:01:48 2013 +0900"
      },
      "message": "clockevents: Sanitize ticks to nsec conversion\n\ncommit 97b9410643475d6557d2517c2aff9fd2221141a9 upstream.\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\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\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "1d48ca6f38fa39298474708abebeffef4ef2cd2d",
      "tree": "54af1961ab8589ebc3e6533c4083c0cdb2581db9",
      "parents": [
        "2cd21fa1b54efaf6b5912ef2833fa474fdcf92b7"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "a.p.zijlstra@chello.nl",
        "time": "Tue Oct 02 15:41:23 2012 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue Oct 01 09:10:52 2013 -0700"
      },
      "message": "perf: Fix perf_cgroup_switch for sw-events\n\ncommit 95cf59ea72331d0093010543b8951bb43f262cac upstream.\n\nJiri reported that he could trigger the WARN_ON_ONCE() in\nperf_cgroup_switch() using sw-events. This is because sw-events share\na cpuctx with multiple PMUs.\n\nUse the -\u003eunique_pmu pointer to limit the pmu iteration to unique\ncpuctx instances.\n\nReported-and-Tested-by: Jiri Olsa \u003cjolsa@redhat.com\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLink: http://lkml.kernel.org/n/tip-so7wi2zf3jjzrwcutm2mkz0j@git.kernel.org\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "2cd21fa1b54efaf6b5912ef2833fa474fdcf92b7",
      "tree": "17a056e20c3937a5af97acd45ac7792a420d78ab",
      "parents": [
        "2927937899b958de968119856ba659d8a4eff037"
      ],
      "author": {
        "name": "Peter Zijlstra",
        "email": "a.p.zijlstra@chello.nl",
        "time": "Tue Oct 02 15:38:52 2012 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue Oct 01 09:10:52 2013 -0700"
      },
      "message": "perf: Clarify perf_cpu_context::active_pmu usage by renaming it to ::unique_pmu\n\ncommit 3f1f33206c16c7b3839d71372bc2ac3f305aa802 upstream.\n\nStephane thought the perf_cpu_context::active_pmu name confusing and\nsuggested using \u0027unique_pmu\u0027 instead.\n\nThis pointer is a pointer to a \u0027random\u0027 pmu sharing the cpuctx\ninstance, therefore limiting a for_each_pmu loop to those where\ncpuctx-\u003eunique_pmu matches the pmu we get a loop over unique cpuctx\ninstances.\n\nSuggested-by: Stephane Eranian \u003ceranian@google.com\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLink: http://lkml.kernel.org/n/tip-kxyjqpfj2fn9gt7kwu5ag9ks@git.kernel.org\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Li Zefan \u003clizefan@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "2927937899b958de968119856ba659d8a4eff037",
      "tree": "51489c3f0826002328a8bf68dccd81c8abeccab3",
      "parents": [
        "72417b659ae9c36e1807bc930240aec202970861"
      ],
      "author": {
        "name": "Li Zefan",
        "email": "lizefan@huawei.com",
        "time": "Mon Feb 18 14:13:35 2013 +0800"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue Oct 01 09:10:51 2013 -0700"
      },
      "message": "cgroup: fail if monitored file and event_control are in different cgroup\n\ncommit f169007b2773f285e098cb84c74aac0154d65ff7 upstream.\n\nIf we pass fd of memory.usage_in_bytes of cgroup A to cgroup.event_control\nof cgroup B, then we won\u0027t get memory usage notification from A but B!\n\nWhat\u0027s worse, if A and B are in different mount hierarchy, we\u0027ll end up\naccessing NULL pointer!\n\nDisallow this kind of invalid usage.\n\nSigned-off-by: Li Zefan \u003clizefan@huawei.com\u003e\nAcked-by: Kirill A. Shutemov \u003ckirill@shutemov.name\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nCc: Weng Meiling \u003cwengmeiling.weng@huawei.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    },
    {
      "commit": "62875332eafea9ee150a6037c0a1a20669e02aa1",
      "tree": "71c673017dc9991b143ad989e6b3d20802a13719",
      "parents": [
        "ebce1a846aa297022fc372d59e6829d0453125f2"
      ],
      "author": {
        "name": "Daisuke Nishimura",
        "email": "nishimura@mxp.nes.nec.co.jp",
        "time": "Tue Sep 10 18:16:36 2013 +0900"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@linuxfoundation.org",
        "time": "Tue Oct 01 09:10:51 2013 -0700"
      },
      "message": "sched/fair: Fix small race where child-\u003ese.parent,cfs_rq might point to invalid ones\n\ncommit 6c9a27f5da9609fca46cb2b183724531b48f71ad upstream.\n\nThere is a small race between copy_process() and cgroup_attach_task()\nwhere child-\u003ese.parent,cfs_rq points to invalid (old) ones.\n\n        parent doing fork()      | someone moving the parent to another cgroup\n  -------------------------------+---------------------------------------------\n    copy_process()\n      + dup_task_struct()\n        -\u003e parent-\u003ese is copied to child-\u003ese.\n           se.parent,cfs_rq of them point to old ones.\n\n                                     cgroup_attach_task()\n                                       + cgroup_task_migrate()\n                                         -\u003e parent-\u003ecgroup is updated.\n                                       + cpu_cgroup_attach()\n                                         + sched_move_task()\n                                           + task_move_group_fair()\n                                             +- set_task_rq()\n                                                -\u003e se.parent,cfs_rq of parent\n                                                   are updated.\n\n      + cgroup_fork()\n        -\u003e parent-\u003ecgroup is copied to child-\u003ecgroup. (*1)\n      + sched_fork()\n        + task_fork_fair()\n          -\u003e se.parent,cfs_rq of child are accessed\n             while they point to old ones. (*2)\n\nIn the worst case, this bug can lead to \"use-after-free\" and cause a panic,\nbecause it\u0027s new cgroup\u0027s refcount that is incremented at (*1),\nso the old cgroup(and related data) can be freed before (*2).\n\nIn fact, a panic caused by this bug was originally caught in RHEL6.4.\n\n    BUG: unable to handle kernel NULL pointer dereference at (null)\n    IP: [\u003cffffffff81051e3e\u003e] sched_slice+0x6e/0xa0\n    [...]\n    Call Trace:\n     [\u003cffffffff81051f25\u003e] place_entity+0x75/0xa0\n     [\u003cffffffff81056a3a\u003e] task_fork_fair+0xaa/0x160\n     [\u003cffffffff81063c0b\u003e] sched_fork+0x6b/0x140\n     [\u003cffffffff8106c3c2\u003e] copy_process+0x5b2/0x1450\n     [\u003cffffffff81063b49\u003e] ? wake_up_new_task+0xd9/0x130\n     [\u003cffffffff8106d2f4\u003e] do_fork+0x94/0x460\n     [\u003cffffffff81072a9e\u003e] ? sys_wait4+0xae/0x100\n     [\u003cffffffff81009598\u003e] sys_clone+0x28/0x30\n     [\u003cffffffff8100b393\u003e] stub_clone+0x13/0x20\n     [\u003cffffffff8100b072\u003e] ? system_call_fastpath+0x16/0x1b\n\nSigned-off-by: Daisuke Nishimura \u003cnishimura@mxp.nes.nec.co.jp\u003e\nSigned-off-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nLink: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n"
    }
  ],
  "next": "55e3e1f419f0c387a2b971cc181b8dea1b099d1d"
}
