{"push_id":2928602906,"size":4,"distinct_size":4,"ref":"refs/heads/LA.UM.7.5.r1-02200-8x96.0","head":"a165c6ba26da2defd6e5c7af62870eec704ce32f","before":"cf4cba1ccdad2cc8ef03307a0e7b326fcce3017b","commits":[{"sha":"b475c68f2c8e5b9a2d251e126351576336b19732","author":{"name":"waau","email":"815a375db4c532acbd077cd9f453c1e7006569f6@gmail.com"},"message":"PTH: kernel: Improvements patchset","distinct":true,"url":"https://api.github.com/repos/waau/platform_kernel_panther/commits/b475c68f2c8e5b9a2d251e126351576336b19732"},{"sha":"7622155ca2a2237c1b12725c46d866efedb5efa7","author":{"name":"Neal Cardwell","email":"58d301c70203188c35d379474c26c9cc0636a189@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":true,"url":"https://api.github.com/repos/waau/platform_kernel_panther/commits/7622155ca2a2237c1b12725c46d866efedb5efa7"},{"sha":"7532aeae3655a09156eb123e078d267171a0f61c","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"net: less interrupt masking in NAPI\n\nnet_rx_action() can mask irqs a single time to transfert sd->poll_list\ninto a private list, for a very short duration.\n\nThen, napi_complete() can avoid masking irqs again,\nand net_rx_action() only needs to mask irq again in slow path.\n\nThis patch removes 2 couples of irq mask/unmask per typical NAPI run,\nmore if multiple napi were triggered.\n\nNote this also allows to give control back to caller (do_softirq())\nmore often, so that other softirq handlers can be called a bit earlier,\nor ksoftirqd can be wakeup earlier under pressure.\n\nThis was developed while testing an alternative to RX interrupt\nmitigation to reduce latencies while keeping or improving GRO\naggregation on fast NIC.\n\nIdea is to test napi->gro_list at the end of a napi->poll() and\nreschedule one NAPI poll, but after servicing a full round of\nsoftirqs (timers, TX, rcu, ...). This will be allowed only if softirq\nis currently serviced by idle task or ksoftirqd, and resched not needed.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Willem de Bruijn <willemb@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/waau/platform_kernel_panther/commits/7532aeae3655a09156eb123e078d267171a0f61c"},{"sha":"a165c6ba26da2defd6e5c7af62870eec704ce32f","author":{"name":"Al Viro","email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@ZenIV.linux.org.uk"},"message":"UPSTREAM: ext4: fix an endianness bug in ext4_encrypted_follow_link()\n\napplying le32_to_cpu() to 16bit value is a bad idea...\n\nCc: stable@vger.kernel.org # v4.1+\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\n\nBUG=chromium:698561\nTEST=compile\n\n(cherry picked from commit 5a1c7f47da9b32d0671e776b0f388095b7f91e2e)\nSigned-off-by: Gwendal Grignou <gwendal@chromium.org>\n\nChange-Id: Ie6d1afb4914a30da5bcbf0097d29d32464cdbcec\nReviewed-on: https://chromium-review.googlesource.com/453124\nCommit-Ready: Gwendal Grignou <gwendal@chromium.org>\nTested-by: Gwendal Grignou <gwendal@chromium.org>\nReviewed-by: Guenter Roeck <groeck@chromium.org>\n(cherry picked from commit 48006f459bde44f7fb6d92ee909246b347d68b7d)\nReviewed-on: https://chromium-review.googlesource.com/453401","distinct":true,"url":"https://api.github.com/repos/waau/platform_kernel_panther/commits/a165c6ba26da2defd6e5c7af62870eec704ce32f"}]}
{"actor":{"display_login":"waau"}}