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 From 30927520dbae297182990bb21d08762bcc35ce1d Mon Sep 17 00:00:00 2001
  30 From: Eric Dumazet <edumazet@google.com>
  31 Date: Wed, 9 Sep 2015 21:55:07 -0700
  32 Subject: [PATCH] tcp_cubic: better follow cubic curve after idle period
  33
  34 Jana Iyengar found an interesting issue on CUBIC :
  35
  36 The epoch is only updated/reset initially and when experiencing losses.
  37 The delta "t" of now - epoch_start can be arbitrary large after app idle
  38 as well as the bic_target. Consequentially the slope (inverse of
  39 ca->cnt) would be really large, and eventually ca->cnt would be
  40 lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.
  41
  42 This particularly shows up when slow_start_after_idle is disabled
  43 as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
  44 time.
  45
  46 Jana initial fix was to reset epoch_start if app limited,
  47 but Neal pointed out it would ask the CUBIC algorithm to recalculate the
  48 curve so that we again start growing steeply upward from where cwnd is
  49 now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
  50 curve to be the same shape, just shifted later in time by the amount of
  51 the idle period.
  52
  53 Reported-by: Jana Iyengar <jri@google.com>
  54 Signed-off-by: Eric Dumazet <edumazet@google.com>
  55 Signed-off-by: Yuchung Cheng <ycheng@google.com>
  56 Signed-off-by: Neal Cardwell <ncardwell@google.com>
  57 Cc: Stephen Hemminger <stephen@networkplumber.org>
  58 Cc: Sangtae Ha <sangtae.ha@gmail.com>
  59 Cc: Lawrence Brakmo <lawrence@brakmo.org>
  60 Signed-off-by: David S. Miller <davem@davemloft.net>
  61 ---
  62  net/ipv4/tcp_cubic.c | 16 ++++++++++++++++
  63  1 file changed, 16 insertions(+)
  64
  65 diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
  66 index 28011fb1..c6ded6b 100644
  67 --- a/net/ipv4/tcp_cubic.c
  68 +++ b/net/ipv4/tcp_cubic.c
  69 @@ -151,6 +151,21 @@ static void bictcp_init(struct sock *sk)
  70                 tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
  71  }
  72
  73 +static void bictcp_cwnd_event(struct sock *sk, enum tcp_ca_event event)
  74 +{
  75 +       if (event == CA_EVENT_TX_START) {
  76 +               s32 delta = tcp_time_stamp - tcp_sk(sk)->lsndtime;
  77 +               struct bictcp *ca = inet_csk_ca(sk);
  78 +
  79 +               /* We were application limited (idle) for a while.
  80 +                * Shift epoch_start to keep cwnd growth to cubic curve.
  81 +                */
  82 +               if (ca->epoch_start && delta > 0)
  83 +                       ca->epoch_start += delta;
  84 +               return;
  85 +       }
  86 +}
  87 +
  88  /* calculate the cubic root of x using a table lookup followed by one
  89   * Newton-Raphson iteration.
  90   * Avg err ~= 0.195%
  91 @@ -450,6 +465,7 @@ static struct tcp_congestion_ops cubictcp __read_mostly = {
  92         .cong_avoid     = bictcp_cong_avoid,
  93         .set_state      = bictcp_state,
  94         .undo_cwnd      = bictcp_undo_cwnd,
  95 +       .cwnd_event     = bictcp_cwnd_event,
  96         .pkts_acked     = bictcp_acked,
  97         .owner          = THIS_MODULE,
  98         .name           = "cubic",
  99 From 7ca88764d45c209791e8813131c1457c2e9e51e7 Mon Sep 17 00:00:00 2001
 100 From: Yevgeny Pats <yevgeny@perception-point.io>
 101 Date: Mon, 11 Jan 2016 12:05:28 +0000
 102 Subject: KEYS: Fix keyring ref leak in join_session_keyring()
 103
 104 If a thread is asked to join as a session keyring the keyring that's already
 105 set as its session, we leak a keyring reference.
 106
 107 This can be tested with the following program:
 108
 109         #include <stddef.h>
 110         #include <stdio.h>
 111         #include <sys/types.h>
 112         #include <keyutils.h>
 113
 114         int main(int argc, const char *argv[])
 115         {
 116                 int i = 0;
 117                 key_serial_t serial;
 118
 119                 serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
 120                                 "leaked-keyring");
 121                 if (serial < 0) {
 122                         perror("keyctl");
 123                         return -1;
 124                 }
 125
 126                 if (keyctl(KEYCTL_SETPERM, serial,
 127                            KEY_POS_ALL | KEY_USR_ALL) < 0) {
 128                         perror("keyctl");
 129                         return -1;
 130                 }
 131
 132                 for (i = 0; i < 100; i++) {
 133                         serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
 134                                         "leaked-keyring");
 135                         if (serial < 0) {
 136                                 perror("keyctl");
 137                                 return -1;
 138                         }
 139                 }
 140
 141                 return 0;
 142         }
 143
 144 If, after the program has run, there something like the following line in
 145 /proc/keys:
 146
 147 3f3d898f I--Q---   100 perm 3f3f0000     0     0 keyring   leaked-keyring: empty
 148
 149 with a usage count of 100 * the number of times the program has been run,
 150 then the kernel is malfunctioning.  If leaked-keyring has zero usages or
 151 has been garbage collected, then the problem is fixed.
 152
 153 Reported-by: Yevgeny Pats <yevgeny@perception-point.io>
 154 Signed-off-by: David Howells <dhowells@redhat.com>
 155 ---
 156  security/keys/process_keys.c | 1 +
 157  1 file changed, 1 insertion(+)
 158
 159 diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
 160 index a3f85d2..e6d50172 100644
 161 --- a/security/keys/process_keys.c
 162 +++ b/security/keys/process_keys.c
 163 @@ -794,6 +794,7 @@ long join_session_keyring(const char *name)
 164                 ret = PTR_ERR(keyring);
 165                 goto error2;
 166         } else if (keyring == new->session_keyring) {
 167 +               key_put(keyring);
 168                 ret = 0;
 169                 goto error2;
 170         }
 171 --
 172 2.7.0.rc3
 173