{"push_id":820641760,"size":4,"distinct_size":4,"ref":"refs/heads/marshamallow-release","head":"afa2c486b38e6d7cca0ff4f559a3f822f75dcc78","before":"fdd79d4165a4028631a837b2b852e2234195eed7","commits":[{"sha":"db94f5c0e7b21f4e9b92f2c91fda31a209911aed","author":{"email":"8a453bad9912ffe59bc0f0b8abe03df9be19379e@zytor.com","name":"H. Peter Anvin"},"message":"kernel: Replace timeconst.pl with a bc script\n\nbc is the standard tool for multi-precision arithmetic.  We switched\nto Perl because akpm reported a hard-to-reproduce build hang, which\nwas very odd because affected and unaffected machines were all running\nthe same version of GNU bc.\n\nUnfortunately switching to Perl required a really ugly \"canning\"\nmechanism to support Perl < 5.8 installations lacking the Math::BigInt\nmodule.\n\nIt was recently pointed out to me that some very old versions of GNU\nmake had problems with pipes in subshells, which was indeed the\nconstruct used in the Makefile rules in that version of the patch;\nPerl didn't need it so switching to Perl fixed the problem for\nunrelated reasons.  With the problem (hopefully) root-caused, we can\nswitch back to bc and do the arbitrary-precision arithmetic naturally.\n\nChange-Id: I048a7fb947f2fbd7b454e85b122c0e3601c02136\nSigned-off-by: H. Peter Anvin <hpa@zytor.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nAcked-by: Sam Ravnborg <sam@ravnborg.org>\nSigned-off-by: Michal Marek <mmarek@suse.cz>\n\nConflicts:\n\tkernel/timeconst.pl","distinct":true,"url":"https://api.github.com/repos/lollipop-og/bricked-geehrc/commits/db94f5c0e7b21f4e9b92f2c91fda31a209911aed"},{"sha":"f832f41c7a78903e2b444ca47a5f16c2c74e3267","author":{"email":"7d26b35203412f18a7dea4f8e1db1a75b1c5b706@semaphore.gr","name":"Stratos Karafotis"},"message":"mach-msm: subsystem_restart: Fix CPU detection\n\nInitialization function could not detect the correct CPU type\n(apq8064). Therefore it could not register correctly subsystem\nrestart order for the panic_handler.\n\nChange-Id: Idff28e5e9f8c60cf5a497cc8c15f21793e8fb3f4\nSigned-off-by: Stratos Karafotis <stratosk@semaphore.gr>","distinct":true,"url":"https://api.github.com/repos/lollipop-og/bricked-geehrc/commits/f832f41c7a78903e2b444ca47a5f16c2c74e3267"},{"sha":"bb305e7892d2c4bdb626b66f8e4cc9c3415c8505","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"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: Ia3ff7c93097a34736d3d9bca89d93a01bf2717b7\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>","distinct":true,"url":"https://api.github.com/repos/lollipop-og/bricked-geehrc/commits/bb305e7892d2c4bdb626b66f8e4cc9c3415c8505"},{"sha":"afa2c486b38e6d7cca0ff4f559a3f822f75dcc78","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"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: Ib9b291f4c5ceb99d4ebdf5252703e60f5007e8bf\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>","distinct":true,"url":"https://api.github.com/repos/lollipop-og/bricked-geehrc/commits/afa2c486b38e6d7cca0ff4f559a3f822f75dcc78"}]}