kernel-small_fixes.patch

   1 --- linux-2.6.32/drivers/infiniband/Kconfig~    2009-12-05 00:26:03.663774916 +0100
   2 +++ linux-2.6.32/drivers/infiniband/Kconfig     2009-12-05 00:26:05.914179759 +0100
   3 @@ -37,7 +37,6 @@
   4  config INFINIBAND_ADDR_TRANS
   5         bool
   6         depends on INET
   7 -       depends on !(INFINIBAND = y && IPV6 = m)
   8         default y
   9
  10  source "drivers/infiniband/hw/mthca/Kconfig"
  11 --- linux-2.6.33/scripts/mod/modpost.c~ 2010-02-24 19:52:17.000000000 +0100
  12 +++ linux-2.6.33/scripts/mod/modpost.c  2010-03-07 14:26:47.242168558 +0100
  13 @@ -15,7 +15,8 @@
  14  #include <stdio.h>
  15  #include <ctype.h>
  16  #include "modpost.h"
  17 -#include "../../include/generated/autoconf.h"
  18 +// PLD architectures don't use CONFIG_SYMBOL_PREFIX
  19 +//#include "../../include/generated/autoconf.h"
  20  #include "../../include/linux/license.h"
  21
  22  /* Some toolchains use a `_' prefix for all user symbols. */
  23
  24 commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511
  25 Author: stephen hemminger <shemminger@vyatta.com>
  26 Date:   Fri Feb 12 06:58:00 2010 +0000
  27
  28     sky2: dont enable PME legacy mode
  29
  30     This bit is not changed by vendor driver, and should be left alone.
  31     The documentation implies this a debug bit.
  32       0 = WAKE# only asserted when VMAIN not available
  33       1 = WAKE# is depend on wake events and independent of VMAIN.
  34
  35     Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
  36     Signed-off-by: David S. Miller <davem@davemloft.net>
  37
  38 diff --git b/drivers/net/sky2.c a/drivers/net/sky2.c
  39 index 2494842..edf37aa 100644
  40 --- b/drivers/net/sky2.c
  41 +++ a/drivers/net/sky2.c
  42 @@ -733,6 +733,7 @@ static void sky2_wol_init(struct sky2_port *sky2)
  43         unsigned port = sky2->port;
  44         enum flow_control save_mode;
  45         u16 ctrl;
  46 +       u32 reg1;
  47
  48         /* Bring hardware out of reset */
  49         sky2_write16(hw, B0_CTST, CS_RST_CLR);
  50 @@ -786,6 +787,11 @@ static void sky2_wol_init(struct sky2_port *sky2)
  51         /* Disable PiG firmware */
  52         sky2_write16(hw, B0_CTST, Y2_HW_WOL_OFF);
  53
  54 +       /* Turn on legacy PCI-Express PME mode */
  55 +       reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
  56 +       reg1 |= PCI_Y2_PME_LEGACY;
  57 +       sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
  58 +
  59         /* block receiver */
  60         sky2_write8(hw, SK_REG(port, RX_GMF_CTRL_T), GMF_RST_SET);
  61  }
  62 On Sat, 2 Jul 2011, Andi Kleen wrote:
  63
  64 > > The problem is that blk_peek_request() calls scsi_prep_fn(), which
  65 > > does this:
  66 > >
  67 > >     struct scsi_device *sdev = q->queuedata;
  68 > >     int ret = BLKPREP_KILL;
  69 > >
  70 > >     if (req->cmd_type == REQ_TYPE_BLOCK_PC)
  71 > >             ret = scsi_setup_blk_pc_cmnd(sdev, req);
  72 > >     return scsi_prep_return(q, req, ret);
  73 > >
  74 > > It doesn't check to see if sdev is NULL, nor does
  75 > > scsi_setup_blk_pc_cmnd().  That accounts for this error:
  76 >
  77 > I actually added a NULL check in scsi_setup_blk_pc_cmnd early on,
  78 > but that just caused RCU CPU stalls afterwards and then eventually
  79 > a hung system.
  80
  81 The RCU problem is likely to be a separate issue.  It might even be a
  82 result of the use-after-free problem with the elevator.
  83
  84 At any rate, it's clear that the crash in the refcounting log you
  85 posted occurred because scsi_setup_blk_pc_cmnd() called
  86 scsi_prep_state_check(), which tried to dereference the NULL pointer.
  87
  88 Would you like to try this patch to see if it fixes the problem?  As I
  89 said before, I'm not certain it's the best thing to do, but it worked
  90 on my system.
  91
  92 Alan Stern
  93
  94
  95
  96
  97 Index: usb-3.0/drivers/scsi/scsi_lib.c
  98 ===================================================================
  99 --- usb-3.0.orig/drivers/scsi/scsi_lib.c
 100 +++ usb-3.0/drivers/scsi/scsi_lib.c
 101 @@ -1247,6 +1247,8 @@ int scsi_prep_fn(struct request_queue *q
 102         struct scsi_device *sdev = q->queuedata;
 103         int ret = BLKPREP_KILL;
 104
 105 +       if (!sdev)
 106 +               return ret;
 107         if (req->cmd_type == REQ_TYPE_BLOCK_PC)
 108                 ret = scsi_setup_blk_pc_cmnd(sdev, req);
 109         return scsi_prep_return(q, req, ret);
 110 Index: usb-3.0/drivers/scsi/scsi_sysfs.c
 111 ===================================================================
 112 --- usb-3.0.orig/drivers/scsi/scsi_sysfs.c
 113 +++ usb-3.0/drivers/scsi/scsi_sysfs.c
 114 @@ -322,6 +322,8 @@ static void scsi_device_dev_release_user
 115                 kfree(evt);
 116         }
 117
 118 +       /* Freeing the queue signals to block that we're done */
 119 +       scsi_free_queue(sdev->request_queue);
 120         blk_put_queue(sdev->request_queue);
 121         /* NULL queue means the device can't be used */
 122         sdev->request_queue = NULL;
 123 @@ -936,8 +938,6 @@ void __scsi_remove_device(struct scsi_de
 124         /* cause the request function to reject all I/O requests */
 125         sdev->request_queue->queuedata = NULL;
 126
 127 -       /* Freeing the queue signals to block that we're done */
 128 -       scsi_free_queue(sdev->request_queue);
 129         put_device(dev);
 130  }
 131
 132
 133
 134 --
 135 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 136 the body of a message to majordomo@vger.kernel.org
 137 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 138 Please read the FAQ at  http://www.tux.org/lkml/
 139 --- linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh~       2011-07-22 04:17:23.000000000 +0200
 140 +++ linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh        2011-08-25 21:26:04.799150642 +0200
 141 @@ -9,6 +9,12 @@
 142                         $cc -print-file-name=lib${lib}.${ext} | grep -q /
 143                         if [ $? -eq 0 ]; then
 144                                 echo "-l${lib}"
 145 +                               for libt in tinfow tinfo ; do
 146 +                                       $cc -print-file-name=lib${libt}.${ext} | grep -q /
 147 +                                       if [ $? -eq 0 ]; then
 148 +                                               echo "-l${libt}"
 149 +                                       fi
 150 +                               done
 151                                 exit
 152                         fi
 153                 done
 154
 155
 156 Fixes a possible memory corruption when the link is larger than
 157 MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the
 158 S_ISLNK assert, since the inode mode is checked previously in
 159 xfs_readlink_by_handle() and via VFS.
 160
 161 Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
 162 ---
 163  fs/xfs/xfs_vnodeops.c |   11 ++++++++---
 164  1 files changed, 8 insertions(+), 3 deletions(-)
 165
 166 diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c
 167 index 51fc429..c3288be 100644
 168 --- a/fs/xfs/xfs_vnodeops.c
 169 +++ b/fs/xfs/xfs_vnodeops.c
 170 @@ -123,13 +123,18 @@ xfs_readlink(
 171
 172         xfs_ilock(ip, XFS_ILOCK_SHARED);
 173
 174 -       ASSERT(S_ISLNK(ip->i_d.di_mode));
 175 -       ASSERT(ip->i_d.di_size <= MAXPATHLEN);
 176 -
 177         pathlen = ip->i_d.di_size;
 178         if (!pathlen)
 179                 goto out;
 180
 181 +       if (pathlen > MAXPATHLEN) {
 182 +               xfs_alert(mp, "%s: inode (%llu) symlink length (%d) too long",
 183 +                        __func__, (unsigned long long)ip->i_ino, pathlen);
 184 +               ASSERT(0);
 185 +               return XFS_ERROR(EFSCORRUPTED);
 186 +       }
 187 +
 188 +
 189         if (ip->i_df.if_flags & XFS_IFINLINE) {
 190                 memcpy(link, ip->i_df.if_u1.if_data, pathlen);
 191                 link[pathlen] = '\0';
 192 --
 193 1.7.6.2
 194
 195 _______________________________________________
 196 xfs mailing list
 197 xfs@oss.sgi.com
 198 http://oss.sgi.com/mailman/listinfo/xfs
 199
 200 An integer overflow will happen on 64bit archs if task's sum of rss, swapents
 201 and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit
 202
 203 f755a04 oom: use pte pages in OOM score
 204
 205 where the oom score computation was divided into several steps and it's no
 206 longer computed as one expression in unsigned long(rss, swapents, nr_pte are
 207 unsigned long), where the result value assigned to points(int) is in
 208 range(1..1000). So there could be an int overflow while computing
 209
 210 176          points *= 1000;
 211
 212 and points may have negative value. Meaning the oom score for a mem hog task
 213 will be one.
 214
 215 196          if (points <= 0)
 216 197                  return 1;
 217
 218 For example:
 219 [ 3366]     0  3366 35390480 24303939   5       0             0 oom01
 220 Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child
 221
 222 Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
 223 memory, but it's oom score is one.
 224
 225 In this situation the mem hog task is skipped and oom killer kills another and
 226 most probably innocent task with oom score greater than one.
 227
 228 The points variable should be of type long instead of int to prevent the int
 229 overflow.
 230
 231 Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
 232 ---
 233  mm/oom_kill.c |    2 +-
 234  1 files changed, 1 insertions(+), 1 deletions(-)
 235
 236 diff --git a/mm/oom_kill.c b/mm/oom_kill.c
 237 index 626303b..e9a1785 100644
 238 --- a/mm/oom_kill.c
 239 +++ b/mm/oom_kill.c
 240 @@ -162,7 +162,7 @@ static bool oom_unkillable_task(struct task_struct *p,
 241  unsigned int oom_badness(struct task_struct *p, struct mem_cgroup *mem,
 242                       const nodemask_t *nodemask, unsigned long totalpages)
 243  {
 244 -       int points;
 245 +       long points;
 246
 247         if (oom_unkillable_task(p, mem, nodemask))
 248                 return 0;
 249 --
 250 1.7.6.4
 251
 252 --
 253 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 254 the body of a message to majordomo@vger.kernel.org
 255 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 256 Please read the FAQ at  http://www.tux.org/lkml/
 257