kernel-small_fixes.patch

   1 --- linux-2.6.33/scripts/mod/modpost.c~ 2010-02-24 19:52:17.000000000 +0100
   2 +++ linux-2.6.33/scripts/mod/modpost.c  2010-03-07 14:26:47.242168558 +0100
   3 @@ -15,7 +15,8 @@
   4  #include <stdio.h>
   5  #include <ctype.h>
   6  #include "modpost.h"
   7 -#include "../../include/generated/autoconf.h"
   8 +// PLD architectures don't use CONFIG_SYMBOL_PREFIX
   9 +//#include "../../include/generated/autoconf.h"
  10  #include "../../include/linux/license.h"
  11
  12  /* Some toolchains use a `_' prefix for all user symbols. */
  13
  14 --- linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh~       2011-07-22 04:17:23.000000000 +0200
  15 +++ linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh        2011-08-25 21:26:04.799150642 +0200
  16 @@ -9,6 +9,12 @@
  17                         $cc -print-file-name=lib${lib}.${ext} | grep -q /
  18                         if [ $? -eq 0 ]; then
  19                                 echo "-l${lib}"
  20 +                               for libt in tinfow tinfo ; do
  21 +                                       $cc -print-file-name=lib${libt}.${ext} | grep -q /
  22 +                                       if [ $? -eq 0 ]; then
  23 +                                               echo "-l${libt}"
  24 +                                       fi
  25 +                               done
  26                                 exit
  27                         fi
  28                 done
  29
  30 From 30927520dbae297182990bb21d08762bcc35ce1d Mon Sep 17 00:00:00 2001
  31 From: Eric Dumazet <edumazet@google.com>
  32 Date: Wed, 9 Sep 2015 21:55:07 -0700
  33 Subject: [PATCH] tcp_cubic: better follow cubic curve after idle period
  34
  35 Jana Iyengar found an interesting issue on CUBIC :
  36
  37 The epoch is only updated/reset initially and when experiencing losses.
  38 The delta "t" of now - epoch_start can be arbitrary large after app idle
  39 as well as the bic_target. Consequentially the slope (inverse of
  40 ca->cnt) would be really large, and eventually ca->cnt would be
  41 lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.
  42
  43 This particularly shows up when slow_start_after_idle is disabled
  44 as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
  45 time.
  46
  47 Jana initial fix was to reset epoch_start if app limited,
  48 but Neal pointed out it would ask the CUBIC algorithm to recalculate the
  49 curve so that we again start growing steeply upward from where cwnd is
  50 now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
  51 curve to be the same shape, just shifted later in time by the amount of
  52 the idle period.
  53
  54 Reported-by: Jana Iyengar <jri@google.com>
  55 Signed-off-by: Eric Dumazet <edumazet@google.com>
  56 Signed-off-by: Yuchung Cheng <ycheng@google.com>
  57 Signed-off-by: Neal Cardwell <ncardwell@google.com>
  58 Cc: Stephen Hemminger <stephen@networkplumber.org>
  59 Cc: Sangtae Ha <sangtae.ha@gmail.com>
  60 Cc: Lawrence Brakmo <lawrence@brakmo.org>
  61 Signed-off-by: David S. Miller <davem@davemloft.net>
  62 ---
  63  net/ipv4/tcp_cubic.c | 16 ++++++++++++++++
  64  1 file changed, 16 insertions(+)
  65
  66 diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
  67 index 28011fb1..c6ded6b 100644
  68 --- a/net/ipv4/tcp_cubic.c
  69 +++ b/net/ipv4/tcp_cubic.c
  70 @@ -151,6 +151,21 @@ static void bictcp_init(struct sock *sk)
  71                 tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
  72  }
  73
  74 +static void bictcp_cwnd_event(struct sock *sk, enum tcp_ca_event event)
  75 +{
  76 +       if (event == CA_EVENT_TX_START) {
  77 +               s32 delta = tcp_time_stamp - tcp_sk(sk)->lsndtime;
  78 +               struct bictcp *ca = inet_csk_ca(sk);
  79 +
  80 +               /* We were application limited (idle) for a while.
  81 +                * Shift epoch_start to keep cwnd growth to cubic curve.
  82 +                */
  83 +               if (ca->epoch_start && delta > 0)
  84 +                       ca->epoch_start += delta;
  85 +               return;
  86 +       }
  87 +}
  88 +
  89  /* calculate the cubic root of x using a table lookup followed by one
  90   * Newton-Raphson iteration.
  91   * Avg err ~= 0.195%
  92 @@ -450,6 +465,7 @@ static struct tcp_congestion_ops cubictcp __read_mostly = {
  93         .cong_avoid     = bictcp_cong_avoid,
  94         .set_state      = bictcp_state,
  95         .undo_cwnd      = bictcp_undo_cwnd,
  96 +       .cwnd_event     = bictcp_cwnd_event,
  97         .pkts_acked     = bictcp_acked,
  98         .owner          = THIS_MODULE,
  99         .name           = "cubic",
 100 From: Tim Gardner <tim.gardner@canonical.com>
 101
 102 commit 1dadafa86a779884f14a6e7a3ddde1a57b0a0a65 upstream.
 103
 104 Commit 37b1ef31a568fc02e53587620226e5f3c66454c8 ("workqueue: move
 105 flush_scheduled_work() to workqueue.h") moved the exported non GPL
 106 flush_scheduled_work() from a function to an inline wrapper.
 107 Unfortunately, it directly calls flush_workqueue() which is a GPL function.
 108 This has the effect of changing the licensing requirement for this function
 109 and makes it unavailable to non GPL modules.
 110
 111 See commit ad7b1f841f8a54c6d61ff181451f55b68175e15a ("workqueue: Make
 112 schedule_work() available again to non GPL modules") for precedent.
 113
 114 Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
 115 Signed-off-by: Tejun Heo <tj@kernel.org>
 116 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 117
 118 ---
 119  kernel/workqueue.c |    2 +-
 120  1 file changed, 1 insertion(+), 1 deletion(-)
 121
 122 --- a/kernel/workqueue.c
 123 +++ b/kernel/workqueue.c
 124 @@ -2614,7 +2614,7 @@ void flush_workqueue(struct workqueue_st
 125  out_unlock:
 126         mutex_unlock(&wq->mutex);
 127  }
 128 -EXPORT_SYMBOL_GPL(flush_workqueue);
 129 +EXPORT_SYMBOL(flush_workqueue);
 130
 131  /**
 132   * drain_workqueue - drain a workqueue
 133
 134
 135 --
 136 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 137 the body of a message to majordomo@vger.kernel.org
 138 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 139 Please read the FAQ at  http://www.tux.org/lkml/