{"push_id":1144211117,"size":67,"distinct_size":2,"ref":"refs/heads/elementalx","head":"7ad4dcd8edda5a0dc150dd622f856346f097eb53","before":"6eb6400adf9a9af8ba2fc31c48fd9e223f5a064a","commits":[{"sha":"2ac666e834bf9a565505d8de6628cf24c541afad","author":{"name":"MassStash","email":"be4fb028a69e97c47ebb9e42667e3b6ea2c234d5@gmail.com"},"message":"Switch to Sprint source\n\nSigned-off-by: MassStash <MassStash@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/2ac666e834bf9a565505d8de6628cf24c541afad"},{"sha":"02f59db9bb7d2e4b2acabf44283ad79f4bf25662","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"disable crc check\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/02f59db9bb7d2e4b2acabf44283ad79f4bf25662"},{"sha":"189eb93f6ac39f9d794c03ca7f06e62932c8e7fc","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"Add SIO and FIOPS i/o schedulers\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/189eb93f6ac39f9d794c03ca7f06e62932c8e7fc"},{"sha":"a658a5aaaab3c4c9c59fd38a744f4aadfd9b184b","author":{"name":"franciscofranco","email":"0ac3193ff3d7b4e68ae404d59f776924e2be9ac9@gmail.com"},"message":"Added fsync on/off support.\n\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/a658a5aaaab3c4c9c59fd38a744f4aadfd9b184b"},{"sha":"5ee6aec06ac0bf4c0909a230fee50accf4b0c1a5","author":{"name":"Jeff Liu","email":"7caaf2102f89e0af2e4ce8bfa65789b1f2f34247@oracle.com"},"message":"binfmt_elf.c: use get_random_int() to fix entropy depleting\n\nChanges:\n--------\nv4->v3:\n- s/random_stack_user()/get_atrandom_bytes()/\n- Move this function to ahead of its use to avoid the predeclaration.\n\nv3->v2:\n- Tweak code comments of random_stack_user().\n- Remove redundant bits mask and shift upon the random variable.\n\nv2->v1:\n- Fix random copy to check up buffer length that are not 4-byte multiples.\n\nv3 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59597.html\nv2 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59418.html\nv1 can be found at:\nhttp://www.spinics.net/lists/linux-fsdevel/msg59128.html\n\nThanks,\n-Jeff\n\nEntropy is quickly depleted under normal operations like ls(1), cat(1),\netc...  between 2.6.30 to current mainline, for instance:\n\n$ cat /proc/sys/kernel/random/entropy_avail\n3428\n$ cat /proc/sys/kernel/random/entropy_avail\n2911\n$cat /proc/sys/kernel/random/entropy_avail\n2620\n\nWe observed this problem has been occurring since 2.6.30 with\nfs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by\nf06295b44c296c8f (\"ELF: implement AT_RANDOM for glibc PRNG seeding\").\n\n/*\n * Generate 16 random bytes for userspace PRNG seeding.\n */\nget_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));\n\nThe patch introduces a wrapper around get_random_int() which has lower\noverhead than calling get_random_bytes() directly.\n\nWith this patch applied:\n$ cat /proc/sys/kernel/random/entropy_avail\n2731\n$ cat /proc/sys/kernel/random/entropy_avail\n2802\n$ cat /proc/sys/kernel/random/entropy_avail\n2878\n\nAnalyzed by John Sobecki.\n\nSigned-off-by: Jie Liu <jeff.liu@oracle.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nCc: Andreas Dilger <aedilger@gmail.com>\nCc: Alan Cox <alan@linux.intel.com>\nCc: Arnd Bergmann <arnn@arndb.de>\nCc: John Sobecki <john.sobecki@oracle.com>\nCc: James Morris <james.l.morris@oracle.com>\nCc: Jakub Jelinek <jakub@redhat.com>\nCc: Ted Ts'o <tytso@mit.edu>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Kees Cook <keescook@chromium.org>\nCc: Ulrich Drepper <drepper@redhat.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/5ee6aec06ac0bf4c0909a230fee50accf4b0c1a5"},{"sha":"38346b1d53adad8d8738d2cc90dbf4bc72d8e399","author":{"name":"Tim Murray","email":"1236fbd8e0651a86c12ed0f0b75aaeb5e5852ea8@google.com"},"message":"mmc: move to a SCHED_FIFO thread\n\nRunning mmcqd as a prio 120 thread forces it to compete with standard\nuser processes for IO performance, especially when the system is under\nsevere CPU load. Move it to a SCHED_FIFO thread to reduce the impact of\nload on IO performance.\n\nbug 25392275\n\nChange-Id: I1edfe73baa25e181367c30c1f40fee886e92b60d\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/38346b1d53adad8d8738d2cc90dbf4bc72d8e399"},{"sha":"7798bc83cfde9ee30fc52062e85c7906cbe553a2","author":{"name":"Tim Murray","email":"1236fbd8e0651a86c12ed0f0b75aaeb5e5852ea8@google.com"},"message":"dm-verity: run in a WQ_HIGHPRI workqueue\n\nRunning dm-verity in a standard workqueue results in IO competing for\nCPU time with standard user apps, which can lead to pipeline bubbles and\nseriously degraded performance. Move to a WQ_HIGHPRI workqueue to\nprotect against that.\n\nbug 25392275\n\nChange-Id: Ic65d7bd6f04e4d77780119e926a50e71323575f0\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/7798bc83cfde9ee30fc52062e85c7906cbe553a2"},{"sha":"540c908599b8706cb432b08deb0f1c35cd222c9d","author":{"name":"Tim Murray","email":"1236fbd8e0651a86c12ed0f0b75aaeb5e5852ea8@google.com"},"message":"dm-crypt: run in a WQ_HIGHPRI workqueue\n\nRunning dm-crypt in a standard workqueue results in IO competing for CPU\ntime with standard user apps, which can lead to pipeline bubbles and\nseriously degraded performance. Move to a WQ_HIGHPRI workqueue to\nprotect against that.\n\nbug 25392275\n\nChange-Id: I589149a31c7b5d322fe2ed5b2476b1f6e3d5ee6f\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/540c908599b8706cb432b08deb0f1c35cd222c9d"},{"sha":"3360743a0b148a72846b53bf217b5c037239608f","author":{"name":"Nikhilesh Reddy","email":"1e32cc90766364d327453cc38b968b137a000d78@codeaurora.org"},"message":"fs: Workaround the compiler's bad optimization\n\nWhen compiling the kernel with  the compiler\n\"aarch64-linux-android-gcc (GCC) 4.9.x-google 20140827 (prerelease)\"\nThe compiler seems to be optimizing a value out in the do_sync_write\nfunction and is incorrectly passing the pointer instead of the\ndereferenced value.\nForce the compiler to use the right value by passing the dereferenced\npointer instead of another variable that is assigned with the dereferenced\nvalue.\n\nChange-Id: I60505ffe39393f6323dcc7c6f912c74ea6aca6cd\nSigned-off-by: Nikhilesh Reddy <reddyn@codeaurora.org>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/3360743a0b148a72846b53bf217b5c037239608f"},{"sha":"c626aef3f118e2bbe7ccdc9d21e1b4758e09998e","author":{"name":"Neal Cardwell","email":"6eb0de8c52d8a3fcaae13b97cd10ce8592d0bd4f@google.com"},"message":"tcp: fix timing issue in CUBIC slope calculation\n\nThis patch fixes a bug in CUBIC that causes cwnd to increase slightly\ntoo slowly when multiple ACKs arrive in the same jiffy.\n\nIf cwnd is supposed to increase at a rate of more than once per jiffy,\nthen CUBIC was sometimes too slow. Because the bic_target is\ncalculated for a future point in time, calculated with time in\njiffies, the cwnd can increase over the course of the jiffy while the\nbic_target calculated as the proper CUBIC cwnd at time\nt=tcp_time_stamp+rtt does not increase, because tcp_time_stamp only\nincreases on jiffy tick boundaries.\n\nSo since the cnt is set to:\n\tca->cnt = cwnd / (bic_target - cwnd);\nas cwnd increases but bic_target does not increase due to jiffy\ngranularity, the cnt becomes too large, causing cwnd to increase\ntoo slowly.\n\nFor example:\n- suppose at the beginning of a jiffy, cwnd=40, bic_target=44\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 40 / (44 - 40) = 40/4 = 10\n- suppose we get 10 acks, each for 1 segment, so tcp_cong_avoid_ai()\n   increases cwnd to 41\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 41 / (44 - 41) = 41 / 3 = 13\n\nSo now CUBIC will wait for 13 packets to be ACKed before increasing\ncwnd to 42, insted of 10 as it should.\n\nThe fix is to avoid adjusting the slope (determined by ca->cnt)\nmultiple times within a jiffy, and instead skip to compute the Reno\ncwnd, the \"TCP friendliness\" code path.\n\nReported-by: Eyal Perry <eyalpe@mellanox.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/c626aef3f118e2bbe7ccdc9d21e1b4758e09998e"},{"sha":"9ae234d3b636a6efa0b086513473649b28a6d805","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: better follow cubic curve after idle period\n\nJana Iyengar found an interesting issue on CUBIC :\n\nThe epoch is only updated/reset initially and when experiencing losses.\nThe delta \"t\" of now - epoch_start can be arbitrary large after app idle\nas well as the bic_target. Consequentially the slope (inverse of\nca->cnt) would be really large, and eventually ca->cnt would be\nlower-bounded in the end to 2 to have delayed-ACK slow-start behavior.\n\nThis particularly shows up when slow_start_after_idle is disabled\nas a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle\ntime.\n\nJana initial fix was to reset epoch_start if app limited,\nbut Neal pointed out it would ask the CUBIC algorithm to recalculate the\ncurve so that we again start growing steeply upward from where cwnd is\nnow (as CUBIC does just after a loss). Ideally we'd want the cwnd growth\ncurve to be the same shape, just shifted later in time by the amount of\nthe idle period.\n\nChange-Id: Ia99e2743517729b1c0589fbb8db9965ec806043b\nReported-by: Jana Iyengar <jri@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nCc: Stephen Hemminger <stephen@networkplumber.org>\nCc: Sangtae Ha <sangtae.ha@gmail.com>\nCc: Lawrence Brakmo <lawrence@brakmo.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/9ae234d3b636a6efa0b086513473649b28a6d805"},{"sha":"ab66843c1c2ed0dc396ce3fada685a15209ce636","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: do not set epoch_start in the future\n\nTracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start\nis normally set at ACK processing time, not at send time.\n\nDoing a proper fix would need to add an additional state variable,\nand does not seem worth the trouble, given CUBIC bug has been there\nforever before Jana noticed it.\n\nLet's simply not set epoch_start in the future, otherwise\nbictcp_update() could overflow and CUBIC would again\ngrow cwnd too fast.\n\nThis was detected thanks to a packetdrill test Neal wrote that was flaky\nbefore applying this fix.\n\nChange-Id: I600d3a8ac0ed1d70f3ff5cc6b7341ac13178f4f3\nFixes: 30927520dbae (\"tcp_cubic: better follow cubic curve after idle period\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nCc: Jana Iyengar <jri@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/ab66843c1c2ed0dc396ce3fada685a15209ce636"},{"sha":"62c1fd9af1e6b9a3adaf532416a050559991cab6","author":{"name":"Mel Gorman","email":"7e4a4144b35252848d9a801e3e6fca62e0cbe9e6@suse.de"},"message":"mm: slub: Default slub_max_order to 0\n\nTo avoid locking and per-cpu overhead, SLUB optimisically uses\nhigh-order allocations up to order-3 by default and falls back to\nlower allocations if they fail. While care is taken that the caller\nand kswapd take no unusual steps in response to this, there are\nfurther consequences like shrinkers who have to free more objects to\nrelease any memory. There is anecdotal evidence that significant time\nis being spent looping in shrinkers with insufficient progress being\nmade (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.\n\nSLUB is now the default allocator and some bug reports have been\npinned down to SLUB using high orders during operations like\ncopying large amounts of data. SLUBs use of high-orders benefits\napplications that are sized to memory appropriately but this does not\nnecessarily apply to large file servers or desktops.  This patch\ncauses SLUB to use order-0 pages like SLAB does by default.\nThere is further evidence that this keeps kswapd's usage lower\n(https://lkml.org/lkml/2011/5/10/383).\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/62c1fd9af1e6b9a3adaf532416a050559991cab6"},{"sha":"5afc4382168d1b19c5d45c6111149e730343236d","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"AIO: Don't plug the I/O queue in do_io_submit()\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/5afc4382168d1b19c5d45c6111149e730343236d"},{"sha":"76dad7f006c5abc40974e87821c06e082ee5091c","author":{"name":"Sahitya Tummala","email":"b7bf508aab3e5632db28abf288bf9b4635713caf@codeaurora.org"},"message":"mmc: sdhci-msm: Set sdio_pending_processing default state to false\n\nIt seems that when we are configuring sdiowakeup_irq, we are\nreceiving a spurious interrupt which sets sdio_pending_processing\nstate to true.\nNow, if the sdio card is physically connected but wifi not enabled\nin that case suspend functionality will be broken sdhci_msm_suspend_noirq\nwill return -EBUSY if sdio_pending_processing is set to true.\n\nThus fix it by setting this flag to false after we have disabled\nsdiowakeup_irq.\n\nCRs-Fixed: 957968\nChange-Id: I755b0b5602345ad6bf557c6055b9057012de0797\nSigned-off-by: Ritesh Harjani <riteshh@codeaurora.org>\nSigned-off-by: Sahitya Tummala <stummala@codeaurora.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/76dad7f006c5abc40974e87821c06e082ee5091c"},{"sha":"5a6f0af122abc4939d5eb6b36f6716acf9f110db","author":{"name":"Venkat Gopalakrishnan","email":"1aea4bfea139e12d03cc2306ea5599fb29560086@codeaurora.org"},"message":"mmc: host: Set max frequency when disabling clock scaling\n\nThe mmc host needs to perform at its peak when clock scaling\nis disabled, hence switch the frequency to max.\n\nCRs-fixed: 981387\nChange-Id: Ie959b8e565ee2dad53cdd9d913bcb8696519d7ca\nSigned-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>\nSigned-off-by: flar2 <asegaert@gmail.com>\nSigned-off-by: MassStash <MassStash@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/5a6f0af122abc4939d5eb6b36f6716acf9f110db"},{"sha":"c9e0074ee2e6292ca12f77993d9414a8c06bad0b","author":{"name":"David Collins","email":"9b7f0fa5f32627ef23dd087d5132a7645f7a4295@codeaurora.org"},"message":"clk: msm: clock-cpu-8996: round clock rates to nearest fmax frequency\n\nModify the round_rate() callback function so that it selects\nthe nearest configured fmax frequency instead of the closest\npossible supported frequency of the parent clock.  This ensures\nthat clk_round_rate() always returns power efficient frequencies\nfor 8996 CPU clocks.\n\nChange-Id: Icc27ba64b9c8af74ee0f81443fea37c4564b9f94\nCRs-Fixed: 981475\nSigned-off-by: David Collins <collinsd@codeaurora.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/c9e0074ee2e6292ca12f77993d9414a8c06bad0b"},{"sha":"494fea10d3a9186b49b5382ee7a1ef04134e79a2","author":{"name":"Zhen Kong","email":"b999fb1d59364862997bac94d5b793be36d63b01@codeaurora.org"},"message":"ARM: dts: msm: correct CE clock setting for crypto driver on msm8996\n\nCorrect CE clock setting for crypto drivers, core_clk_src should\nlink to voting clock; otherwise, ce1 clock is set to be only half\nof 171M HZ during crypto operations.\n\nChange-Id: I0d9e048381a83d4788bf4f700d788137b59bd368\nSigned-off-by: Zhen Kong <zkong@codeaurora.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/494fea10d3a9186b49b5382ee7a1ef04134e79a2"},{"sha":"a32cad658c17a658097936d5bb683c8ef7d4e7f7","author":{"name":"Vikram Mulukutla","email":"38ccb813e5b3214898ec503d73f04341502487cd@codeaurora.org"},"message":"clk: msm: clock-cpu-8996: Update calibration settings\n\nUpdated characterization has shown the need to modify\ncertain calibration settings for hardware blocks within\nthe CPU subsystem. Modify these values.\n\nCRs-Fixed: 930377\nChange-Id: I601802746224e2abb43fd0b3aedb09e049062adf\nSigned-off-by: Vikram Mulukutla <markivx@codeaurora.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/a32cad658c17a658097936d5bb683c8ef7d4e7f7"},{"sha":"3f93c9428a90fab7bf0d4e6960a4f2b6c8753ca0","author":{"name":"flar2","email":"54baee86d9719f38bf07b54ac189c5126488f211@gmail.com"},"message":"FIOPS: update for linux 3.18","distinct":false,"url":"https://api.github.com/repos/MassStash/htc_pme_kernel_sense_6.0/commits/3f93c9428a90fab7bf0d4e6960a4f2b6c8753ca0"}]}
{"actor":{"display_login":"MassStash"}}