{"push_id":2751830173,"size":36,"distinct_size":36,"ref":"refs/heads/dev","head":"259d87e7d2d8c1da3054f89c9e2d7d69934f2894","before":"1376a8ac1d0a61c2c81f7e48f783c17e28e7f6a1","commits":[{"sha":"e27f168334f8854716914e5cc02d0a5e5bf6847b","author":{"name":"Hannes Frederic Sowa","email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org"},"message":"BACKPORT: random32: add periodic reseeding\n\nClean cherry pick of commmit 6d31920246a9fc80be4f16acd27c0bbe8d7b8494.\n\nThe current Tausworthe PRNG is never reseeded with truly random data after\nthe first attempt in late_initcall. As this PRNG is used for some critical\nrandom data as e.g. UDP port randomization we should try better and reseed\nthe PRNG once in a while with truly random data from get_random_bytes().\n\nWhen we reseed with prandom_seed we now make also sure to throw the first\noutput away. This suffices the reseeding procedure.\n\nThe delay calculation is based on a proposal from Eric Dumazet.\n\nJoint work with Daniel Borkmann.\n\nCc: Eric Dumazet <eric.dumazet@gmail.com>\nCc: Theodore Ts'o <tytso@mit.edu>\nSigned-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\n\nBug: http://b/29621447\nChange-Id: I990d00f4a29a56a22357cec1c17477c4721054ae\n(cherry picked from commit 6d31920246a9fc80be4f16acd27c0bbe8d7b8494)","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/e27f168334f8854716914e5cc02d0a5e5bf6847b"},{"sha":"84731155fce8038d8abb9eae0935e3d8129bc395","author":{"name":"Hannes Frederic Sowa","email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org"},"message":"BACKPORT: random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized\n\nClean cherry pick of commit 4af712e8df998475736f3e2727701bd31e3751a9.\n\nThe Tausworthe PRNG is initialized at late_initcall time. At that time the\nentropy pool serving get_random_bytes is not filled sufficiently. This\npatch adds an additional reseeding step as soon as the nonblocking pool\ngets marked as initialized.\n\nOn some machines it might be possible that late_initcall gets called after\nthe pool has been initialized. In this situation we won't reseed again.\n\n(A call to prandom_seed_late blocks later invocations of early reseed\nattempts.)\n\nJoint work with Daniel Borkmann.\n\nCc: Eric Dumazet <eric.dumazet@gmail.com>\nCc: Theodore Ts'o <tytso@mit.edu>\nSigned-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nAcked-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: David S. Miller <davem@davemloft.net>\n\nBug: http://b/29621447\nChange-Id: I4d20e60b5df16228f3a3699d16ed2b1dddcceb2b\n(cherry picked from commit 4af712e8df998475736f3e2727701bd31e3751a9)","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/84731155fce8038d8abb9eae0935e3d8129bc395"},{"sha":"0379d63fb65ced15f6fa89309be424ba0f9dc3a2","author":{"name":"stenkinevgeniy","email":"ce29643fb343924821142e7d3cb7266b9190eff7@gmail.com"},"message":"Always inlcude irq.h","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/0379d63fb65ced15f6fa89309be424ba0f9dc3a2"},{"sha":"58570558997659ffd606cdd199da2b94f989460e","author":{"name":"Theodore Ts'o","email":"4ed386e0495d3e109932df055831d9ec2f824927@mit.edu"},"message":"BACKPORT: random: introduce getrandom(2) system call\n\nAlmost clean cherry pick of c6e9d6f38894798696f23c8084ca7edbf16ee895,\nincludes change made by merge 0891ad829d2a0501053703df66029e843e3b8365.\n\nThe getrandom(2) system call was requested by the LibreSSL Portable\ndevelopers.  It is analoguous to the getentropy(2) system call in\nOpenBSD.\n\nThe rationale of this system call is to provide resiliance against\nfile descriptor exhaustion attacks, where the attacker consumes all\navailable file descriptors, forcing the use of the fallback code where\n/dev/[u]random is not available.  Since the fallback code is often not\nwell-tested, it is better to eliminate this potential failure mode\nentirely.\n\nThe other feature provided by this new system call is the ability to\nrequest randomness from the /dev/urandom entropy pool, but to block\nuntil at least 128 bits of entropy has been accumulated in the\n/dev/urandom entropy pool.  Historically, the emphasis in the\n/dev/urandom development has been to ensure that urandom pool is\ninitialized as quickly as possible after system boot, and preferably\nbefore the init scripts start execution.\n\nThis is because changing /dev/urandom reads to block represents an\ninterface change that could potentially break userspace which is not\nacceptable.  In practice, on most x86 desktop and server systems, in\ngeneral the entropy pool can be initialized before it is needed (and\nin modern kernels, we will printk a warning message if not).  However,\non an embedded system, this may not be the case.  And so with this new\ninterface, we can provide the functionality of blocking until the\nurandom pool has been initialized.  Any userspace program which uses\nthis new functionality must take care to assure that if it is used\nduring the boot process, that it will not cause the init scripts or\nother portions of the system startup to hang indefinitely.\n\nSYNOPSIS\n\t#include <linux/random.h>\n\n\tint getrandom(void *buf, size_t buflen, unsigned int flags);\n\nDESCRIPTION\n\tThe system call getrandom() fills the buffer pointed to by buf\n\twith up to buflen random bytes which can be used to seed user\n\tspace random number generators (i.e., DRBG's) or for other\n\tcryptographic uses.  It should not be used for Monte Carlo\n\tsimulations or other programs/algorithms which are doing\n\tprobabilistic sampling.\n\n\tIf the GRND_RANDOM flags bit is set, then draw from the\n\t/dev/random pool instead of the /dev/urandom pool.  The\n\t/dev/random pool is limited based on the entropy that can be\n\tobtained from environmental noise, so if there is insufficient\n\tentropy, the requested number of bytes may not be returned.\n\tIf there is no entropy available at all, getrandom(2) will\n\teither block, or return an error with errno set to EAGAIN if\n\tthe GRND_NONBLOCK bit is set in flags.\n\n\tIf the GRND_RANDOM bit is not set, then the /dev/urandom pool\n\twill be used.  Unlike using read(2) to fetch data from\n\t/dev/urandom, if the urandom pool has not been sufficiently\n\tinitialized, getrandom(2) will block (or return -1 with the\n\terrno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).\n\n\tThe getentropy(2) system call in OpenBSD can be emulated using\n\tthe following function:\n\n            int getentropy(void *buf, size_t buflen)\n            {\n                    int     ret;\n\n                    if (buflen > 256)\n                            goto failure;\n                    ret = getrandom(buf, buflen, 0);\n                    if (ret < 0)\n                            return ret;\n                    if (ret == buflen)\n                            return 0;\n            failure:\n                    errno = EIO;\n                    return -1;\n            }\n\nRETURN VALUE\n       On success, the number of bytes that was filled in the buf is\n       returned.  This may not be all the bytes requested by the\n       caller via buflen if insufficient entropy was present in the\n       /dev/random pool, or if the system call was interrupted by a\n       signal.\n\n       On error, -1 is returned, and errno is set appropriately.\n\nERRORS\n\tEINVAL\t\tAn invalid flag was passed to getrandom(2)\n\n\tEFAULT\t\tbuf is outside the accessible address space.\n\n\tEAGAIN\t\tThe requested entropy was not available, and\n\t\t\tgetentropy(2) would have blocked if the\n\t\t\tGRND_NONBLOCK flag was not set.\n\n\tEINTR\t\tWhile blocked waiting for entropy, the call was\n\t\t\tinterrupted by a signal handler; see the description\n\t\t\tof how interrupted read(2) calls on \"slow\" devices\n\t\t\tare handled with and without the SA_RESTART flag\n\t\t\tin the signal(7) man page.\n\nNOTES\n\tFor small requests (buflen <= 256) getrandom(2) will not\n\treturn EINTR when reading from the urandom pool once the\n\tentropy pool has been initialized, and it will return all of\n\tthe bytes that have been requested.  This is the recommended\n\tway to use getrandom(2), and is designed for compatibility\n\twith OpenBSD's getentropy() system call.\n\n\tHowever, if you are using GRND_RANDOM, then getrandom(2) may\n\tblock until the entropy accounting determines that sufficient\n\tenvironmental noise has been gathered such that getrandom(2)\n\twill be operating as a NRBG instead of a DRBG for those people\n\twho are working in the NIST SP 800-90 regime.  Since it may\n\tblock for a long time, these guarantees do *not* apply.  The\n\tuser may want to interrupt a hanging process using a signal,\n\tso blocking until all of the requested bytes are returned\n\twould be unfriendly.\n\n\tFor this reason, the user of getrandom(2) MUST always check\n\tthe return value, in case it returns some error, or if fewer\n\tbytes than requested was returned.  In the case of\n\t!GRND_RANDOM and small request, the latter should never\n\thappen, but the careful userspace code (and all crypto code\n\tshould be careful) should check for this anyway!\n\n\tFinally, unless you are doing long-term key generation (and\n\tperhaps not even then), you probably shouldn't be using\n\tGRND_RANDOM.  The cryptographic algorithms used for\n\t/dev/urandom are quite conservative, and so should be\n\tsufficient for all purposes.  The disadvantage of GRND_RANDOM\n\tis that it can block, and the increased complexity required to\n\tdeal with partially fulfilled getrandom(2) requests.\n\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReviewed-by: Zach Brown <zab@zabbo.net>\n\nBug: http://b/29621447\nChange-Id: I189ba74070dd6d918b0fdf83ff30bb74ec0f7556\n(cherry picked from commit 4af712e8df998475736f3e2727701bd31e3751a9)","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/58570558997659ffd606cdd199da2b94f989460e"},{"sha":"8023741fc94c4ac4e64ff613baa487fd38b2bda0","author":{"name":"stenkinevgeniy","email":"ce29643fb343924821142e7d3cb7266b9190eff7@gmail.com"},"message":"random32: add needed timer.h","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/8023741fc94c4ac4e64ff613baa487fd38b2bda0"},{"sha":"a8c524312d1b00a855e38e811ec4e5f64a3e6fef","author":{"name":"Jeff Ohlstein","email":"f1f648fe3894ee17052079545fcc4ebaf95f6cbc@codeaurora.org"},"message":"sched_avg: add run queue averaging\n\nAdd code to calculate the run queue depth of a cpu and iowait\ndepth of the cpu.\n\nThe scheduler calls in to sched_update_nr_prod whenever there\nis a runqueue change. This function maintains the runqueue average\nand the iowait of that cpu in that time interval.\n\nWhoever wants to know the runqueue average is expected to call\nsched_get_nr_running_avg periodically to get the accumulated\nrunqueue and iowait averages for all the cpus.\n\nChange-Id: Id8cb2ecf0ed479f090a83ccb72dd59c53fa73e0c\nSigned-off-by: Jeff Ohlstein <johlstei@codeaurora.org>\n(cherry picked from commit 0299fcaaad80e2c0ac9aa583c95107f6edc27750)","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/a8c524312d1b00a855e38e811ec4e5f64a3e6fef"},{"sha":"b2c340b8d48caf28434b1716fabb1b88f5063e19","author":{"name":"Steve Muckle","email":"d282495bfb62d367009a66784cabed6d13acc2f2@codeaurora.org"},"message":"kernel: reduce sleep duration in wait_task_inactive\n\nSleeping for an entire tick adds unnecessary latency to\nhotplugging a cpu (cpu_up).\n\nChange-Id: Iab323a79f4048bc9101ecfd368e0f275827ed4ab\nSigned-off-by: Steve Muckle <smuckle@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/b2c340b8d48caf28434b1716fabb1b88f5063e19"},{"sha":"d79252b1beaf77eaec7b7ed9aaac40d2f6bd9a85","author":{"name":"Srivatsa Vaddagiri","email":"69d4c67d027719823df1f8f9226c47bc05dc8998@codeaurora.org"},"message":"sched: fix rq->lock recursion\n\nEnabling SCHED_HRTICK currently results in rq->lock recursion and a hard\nhang at bootup.  Essentially try_to_wakeup() grabs rq->lock and tries\narming a hrtimer via hrtimer_restart(), which deep down tries waking up\nksoftirqd, which leads to a recursive call to try_to_wakeup() and thus\nattempt to take rq->lock recursively!!\n\nThis is fixed by having scheduler queue hrtimer via\n__hrtimer_start_range_ns() which avoids waking up ksoftirqd.\n\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\nChange-Id: I11a13be1d9db3a749614ccf3d4f5fb7bf6f18fa1\n(cherry picked from commit 4ca1d04ea0bdc225cc7db302172f3375a63f44de)","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/d79252b1beaf77eaec7b7ed9aaac40d2f6bd9a85"},{"sha":"f013f8a3a40bc5f0b225d16dbe55d8ca68bd079d","author":{"name":"Srivatsa Vaddagiri","email":"69d4c67d027719823df1f8f9226c47bc05dc8998@codeaurora.org"},"message":"sched: Reset rq->next_interval before going idle\n\nnext_balance, the point in jiffy time scale when a cpu will next load\nbalance, could have been calculated when the cpu was busy. A busy cpu\nwill apply its sched domain's busy_factor (usually > 1) in computing\nnext_balance for that sched domain, which causes the (busy) cpu to load\nbalance less frequently in its sched domains. However when the same cpu\nis going idle, its next_balance needs to be reset without consideration\nof busy_factor. Failure to do so would not trigger nohz idle balancer on\nthat cpu for unnecessarily long time (introducing additional scheduling\nlatencies for tasks). Fix bug in scheduler which aims to reset\nnext_balance before a cpu goes idle (as per existing comment) but is\nclearly not doing so.\n\nChange-Id: I7e027a51686528c4092d770c7d33c874d38f5df4\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/f013f8a3a40bc5f0b225d16dbe55d8ca68bd079d"},{"sha":"389bc69239b4b6ec76200f5321e05c886d66f71d","author":{"name":"Srivatsa Vaddagiri","email":"69d4c67d027719823df1f8f9226c47bc05dc8998@codeaurora.org"},"message":"sched: Fix SCHED_HRTICK bug leading to late preemption of tasks\n\nSCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot\n(just when they would have exceeded their ideal_runtime). It makes use\nof a a per-cpu hrtimer resource and hence alarming that hrtimer should\nbe based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,\nrather than being based on number of tasks in a particular cfs_rq (as\nimplemented currently). As a result, with current code, its possible for\na running task (which is the sole task in its cfs_rq) to be preempted\nmuch after its ideal_runtime has elapsed, resulting in increased latency\nfor tasks in other cfs_rq on same cpu.\n\nFix this by alarming sched hrtimer based on total number of SCHED_FAIR\ntasks a CPU has across its various cfs_rqs.\n\nChange-Id: I1f23680a64872f8ce0f451ac4bcae28e8967918f\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/389bc69239b4b6ec76200f5321e05c886d66f71d"},{"sha":"2e33cb8a85258e99c4e6e24a54d7246c59e56f56","author":{"name":"Jordan Crouse","email":"fec53db8c4887e6e95defbb5052bc6438029c1e6@codeaurora.org"},"message":"sched: Mark schedule_io_timeout() with EXPORT_SYMBOL\n\nMake schedule_io_timeout() visible to modules.\n\nChange-Id: Ic0dedbad8a591a9a721f0d2e8f6c372ec75bc4b2\nSigned-off-by: Jordan Crouse <jcrouse@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/2e33cb8a85258e99c4e6e24a54d7246c59e56f56"},{"sha":"594f7bd17aa3aa604f6c05eb741155a79668625a","author":{"name":"Srivatsa Vaddagiri","email":"69d4c67d027719823df1f8f9226c47bc05dc8998@codeaurora.org"},"message":"sched: fix reference to wrong cfs_rq\n\nCommit 7db16c8c (sched: Fix SCHED_HRTICK bug leading to late preemption\nof tasks) introduced a bug in sched_slice() calculation by using wrong\ncfs_rq for tasks. rq->cfs was incorrectly used as task's cfs_rq, rather\nthan the correct one to which they belonged.\n\nFix the bug by using correct cfs_rq for tasks.\n\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/594f7bd17aa3aa604f6c05eb741155a79668625a"},{"sha":"d30e93ee38a8973a775daaf369cbf0fd4ca4bd61","author":{"name":"stenkinevgeniy","email":"ce29643fb343924821142e7d3cb7266b9190eff7@gmail.com"},"message":"Moving sec_debug upper for fix next commits","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/d30e93ee38a8973a775daaf369cbf0fd4ca4bd61"},{"sha":"66a46ce6023fb96b32fdf816e9913c89a56a20f5","author":{"name":"stenkinevgeniy","email":"ce29643fb343924821142e7d3cb7266b9190eff7@gmail.com"},"message":"Remove hmp stuff.","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/66a46ce6023fb96b32fdf816e9913c89a56a20f5"},{"sha":"a8e5ea0f5d6e3c0c42890d5c14cc444e1bbfec4b","author":{"name":"Steve Muckle","email":"d282495bfb62d367009a66784cabed6d13acc2f2@codeaurora.org"},"message":"sched: provide per cpu-cgroup option to notify on migrations\n\nOn systems where CPUs may run asynchronously, task migrations\nbetween CPUs running at grossly different speeds can cause\nproblems.\n\nThis change provides a mechanism to notify a subsystem\nin the kernel if a task in a particular cgroup migrates to a\ndifferent CPU. Other subsystems (such as cpufreq) may then\nregister for this notifier to take appropriate action when\nsuch a task is migrated.\n\nThe cgroup attribute to set for this behavior is\n\"notify_on_migrate\" .\n\nChange-Id: Ie1868249e53ef901b89c837fdc33b0ad0c0a4590\nSigned-off-by: Steve Muckle <smuckle@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/a8e5ea0f5d6e3c0c42890d5c14cc444e1bbfec4b"},{"sha":"68c59adeac6402519712f9d01e2edb4af63c13b7","author":{"name":"Steve Muckle","email":"d282495bfb62d367009a66784cabed6d13acc2f2@codeaurora.org"},"message":"sched: remove migration notification from RT class\n\nCommit 88a7e37d265 (sched: provide per cpu-cgroup option to\nnotify on migrations) added a notifier call when a task is moved\nto a different CPU. Unfortunately the two call sites in the RT\nsched class where this occurs happens with a runqueue lock held.\nThis can result in a deadlock if the notifier call attempts to do\nsomething like wake up a task.\n\nFortunately the benefit of 88a7e37d265 comes mainly from notifying\non migration of non-RT tasks, so we can simply ignore the movements\nof RT tasks.\n\nCRs-Fixed: 491370\nChange-Id: I8849d826bf1eeaf85a6f6ad872acb475247c5926\nSigned-off-by: Steve Muckle <smuckle@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/68c59adeac6402519712f9d01e2edb4af63c13b7"},{"sha":"7087e3186f9450f18d13c10515b770d250c18e34","author":{"name":"Srivatsa Vaddagiri","email":"69d4c67d027719823df1f8f9226c47bc05dc8998@codeaurora.org"},"message":"sched: re-calculate a cpu's next_balance point upon sched domain changes\n\nCommit 55ddeb0f (sched: Reset rq->next_interval before going idle) reset\na cpu's rq->next_balance when pulled_task = 0, which will be true when\nthe cpu failed to pull any task, causing it go idle. However that patch\nrelied on next_balance being calculated as a result of traversing cpu's\nsched domain hierarchy.\n\nA cpu that is the only online cpu will however not be attached to any\nsched domain hierarchy. When such a cpu calls into idle_balance(), we\nwill end up initializing next_balance to be 1sec away! Such a CPU will\ndefer load balance check for another 1sec, even though we may bring up\nmore cpus in the meantime requiring it to check for load imbalance more\nfrequently. This could then lead to increased scheduling latency for\nsome tasks.\n\nThis patch results in a cpu's next_balance being re-calculated when its\nattaching to a new sched domain hierarchy.  This should let cpus call\nload balance checks at the right time we expect them to!\n\nChange-Id: I855cff8da5ca28d278596c3bb0163b839d4704bc\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/7087e3186f9450f18d13c10515b770d250c18e34"},{"sha":"305bd6353ec22634d2067de46c1714c8dd4b76be","author":{"name":"Arun Bharadwaj","email":"5cd93defcc4448eccb81338b7db4c7408d9204f5@codeaurora.org"},"message":"tracing/sched: Track per-cpu rt and non-rt cpu_load.\n\nAdd a new tracepoint trace_sched_enq_deq_task to track\nper-cpu rt and non-rt cpu_load during task enqueue\nand dequeue.\n\nThis is useful to visualize and compare the load on\ndifferent cpus and also to understand how balanced\nthe load is at any point of time.\n\nNote: We only print cpu_load[0] because we only care about\nthe most recent load history for tracking load balancer\neffectiveness.\n\nChange-Id: I46f0bb84e81652099ed5edf8c2686c70c8b8330c\nSigned-off-by: Arun Bharadwaj <abharadw@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/305bd6353ec22634d2067de46c1714c8dd4b76be"},{"sha":"0ef01fe0d381cfa66177a6bfc6ed1032fe0c65da","author":{"name":"Steve Muckle","email":"d282495bfb62d367009a66784cabed6d13acc2f2@codeaurora.org"},"message":"sched: change WARN_ON_ONCE to WARN_ON in try_to_wake_up_local()\n\nThe WARN_ON_ONCE() calls at the beginning of try_to_wake_up_local()\nwere recently converted from BUG_ON() calls. If these hit it indicates\nsomething is wrong and that may contribute to other system instability.\nTo eliminate the risk of an instance of one of these errors going\nun-noticed because there was an earlier instance that occured long ago,\nchange to WARN_ON(). If there ever is a flood of these there are bigger\nproblems.\n\nChange-Id: I392832e2b6ec24b3569b001b1af9ecd4ed6828e7\nSigned-off-by: Steve Muckle <smuckle@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/0ef01fe0d381cfa66177a6bfc6ed1032fe0c65da"},{"sha":"46725b37c6571c4709ec8d884b5f24663032fc59","author":{"name":"Stanislaw Gruszka","email":"1542dc81552e668e197a396f69e655c1621c300d@redhat.com"},"message":"sched/cputime: Do not scale when utime == 0\n\ncommit 5a8e01f8fa51f5cbce8f37acc050eb2319d12956 upstream.\n\nscale_stime() silently assumes that stime < rtime, otherwise\nwhen stime == rtime and both values are big enough (operations\non them do not fit in 32 bits), the resulting scaling stime can\nbe bigger than rtime. In consequence utime = rtime - stime\nresults in negative value.\n\nUser space visible symptoms of the bug are overflowed TIME\nvalues on ps/top, for example:\n\n $ ps aux | grep rcu\n root         8  0.0  0.0      0     0 ?        S    12:42   0:00 [rcuc/0]\n root         9  0.0  0.0      0     0 ?        S    12:42   0:00 [rcub/0]\n root        10 62422329  0.0  0     0 ?        R    12:42 21114581:37 [rcu_preempt]\n root        11  0.1  0.0      0     0 ?        S    12:42   0:02 [rcuop/0]\n root        12 62422329  0.0  0     0 ?        S    12:42 21114581:35 [rcuop/1]\n root        10 62422329  0.0  0     0 ?        R    12:42 21114581:37 [rcu_preempt]\n\nor overflowed utime values read directly from /proc/$PID/stat\n\nReference:\n\n  https://lkml.org/lkml/2013/8/20/259\n\nReported-and-tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>\nSigned-off-by: Stanislaw Gruszka <sgruszka@redhat.com>\nCc: stable@vger.kernel.org\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Borislav Petkov <bp@alien8.de>\nLink: http://lkml.kernel.org/r/20130904131602.GC2564@redhat.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Exynos7580/android_kernel_samsung_a3xeltexx/commits/46725b37c6571c4709ec8d884b5f24663032fc59"}]}
{"actor":{"display_login":"Sekilsgs2"}}