]> git.pld-linux.org Git - packages/kernel.git/blame - kernel-small_fixes.patch
add vserver patch info to package description
[packages/kernel.git] / kernel-small_fixes.patch
CommitLineData
08aa9d92 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
2136e199
AM
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
44c0f99c 29
59e60efc
AM
30diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
31index 7a0c800..ec5ebbb 100644
32--- a/drivers/net/ethernet/realtek/r8169.c
33+++ b/drivers/net/ethernet/realtek/r8169.c
514e5dae 34@@ -6927,6 +6927,14 @@ rtl_init_one(struct pci_dev *pdev, const
59e60efc
AM
35 for (i = 0; i < ETH_ALEN; i++)
36 dev->dev_addr[i] = RTL_R8(MAC0 + i);
514e5dae 37
59e60efc
AM
38+ if (!is_valid_ether_addr(dev->dev_addr)) {
39+ /* Report it and use a random ethernet address instead */
40+ netdev_err(dev, "Invalid MAC address: %pM\n", dev->dev_addr);
41+ random_ether_addr(dev->dev_addr);
42+ netdev_info(dev, "Using random MAC address: %pM\n",
514e5dae 43+ dev->dev_addr);
59e60efc 44+ }
514e5dae 45+
59e60efc 46 SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
514e5dae
AM
47 dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
48
20e3bfd4
KK
49[PATCH] SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
50
51If a device has the skip_vpd_pages flag set we should simply fail the
52scsi_get_vpd_page() call.
53
54Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
55Acked-by: Alan Stern <stern@rowland.harvard.edu>
56Tested-by: Stuart Foster <smf.linux@ntlworld.com>
57Cc: stable@vger.kernel.org
58
59diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
60index 3b1ea34..eaa808e 100644
61--- a/drivers/scsi/scsi.c
62+++ b/drivers/scsi/scsi.c
63@@ -1031,6 +1031,9 @@
64 {
65 int i, result;
66
67+ if (sdev->skip_vpd_pages)
68+ goto fail;
69+
70 /* Ask for all the pages supported by this device */
71 result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
72 if (result)
89e90749 73
4619f982
AM
74From 1e2ee49f7f1b79f0b14884fe6a602f0411b39552 Mon Sep 17 00:00:00 2001
75From: Will Woods <wwoods@redhat.com>
76Date: Tue, 6 May 2014 12:50:10 -0700
77Subject: fanotify: fix -EOVERFLOW with large files on 64-bit
78
79On 64-bit systems, O_LARGEFILE is automatically added to flags inside
80the open() syscall (also openat(), blkdev_open(), etc). Userspace
81therefore defines O_LARGEFILE to be 0 - you can use it, but it's a
82no-op. Everything should be O_LARGEFILE by default.
83
84But: when fanotify does create_fd() it uses dentry_open(), which skips
85all that. And userspace can't set O_LARGEFILE in fanotify_init()
86because it's defined to 0. So if fanotify gets an event regarding a
87large file, the read() will just fail with -EOVERFLOW.
88
89This patch adds O_LARGEFILE to fanotify_init()'s event_f_flags on 64-bit
90systems, using the same test as open()/openat()/etc.
91
92Addresses https://bugzilla.redhat.com/show_bug.cgi?id=696821
93
94Signed-off-by: Will Woods <wwoods@redhat.com>
95Acked-by: Eric Paris <eparis@redhat.com>
96Reviewed-by: Jan Kara <jack@suse.cz>
97Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
98Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
99
100diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
101index 4e565c8..732648b 100644
102--- a/fs/notify/fanotify/fanotify_user.c
103+++ b/fs/notify/fanotify/fanotify_user.c
104@@ -698,6 +698,8 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags)
105 }
106 group->overflow_event = &oevent->fse;
107
108+ if (force_o_largefile())
109+ event_f_flags |= O_LARGEFILE;
110 group->fanotify_data.f_flags = event_f_flags;
111 #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
112 spin_lock_init(&group->fanotify_data.access_lock);
113--
114cgit v0.10.1
115
69ea3bb8
AM
116
117Hi all,
118 There is a risk of data loss with md/raid6 arrays running on Linux since
119 2.6.32.
120 If:
121 - the array is doubly degraded
122 - one or both failed devices are being recovered, and
123 - the array is written to
124
125 then it is possible for data on the array to be lost. The patch below fixes
126 the problem. If you apply the patch to an older kernel which has separate
127 handle_stripe5() and handle_stripe6() functions, be sure that patch changes
128 handle_stripe6().
129
130 There is no risk to an optimal array or a singly-degraded array. There is
131 also no risk on a doubly-degraded array which is not recovering a device or
132 is not receiving write requests.
133
134 If you have data on a RAID6 array, please consider how to avoid corruption,
135 possibly by applying the patch, possibly by removing any hot spares so
136 recovery does not automatically start.
137
138 This patch will be sent upstream shortly and will subsequently appear in
139 future "-stable" kernels.
140
141NeilBrown
142
143From f94e37dce722ec7b6666fd04be357f422daa02b5 Mon Sep 17 00:00:00 2001
144From: NeilBrown <neilb@suse.de>
145Date: Wed, 13 Aug 2014 09:57:07 +1000
146Subject: [PATCH] md/raid6: avoid data corruption during recovery of
147 double-degraded RAID6
148
149During recovery of a double-degraded RAID6 it is possible for
150some blocks not to be recovered properly, leading to corruption.
151
152If a write happens to one block in a stripe that would be written to a
153missing device, and at the same time that stripe is recovering data
154to the other missing device, then that recovered data may not be written.
155
156This patch skips, in the double-degraded case, an optimisation that is
157only safe for single-degraded arrays.
158
159Bug was introduced in 2.6.32 and fix is suitable for any kernel since
160then. In an older kernel with separate handle_stripe5() and
161handle_stripe6() functions that patch must change handle_stripe6().
162
163Cc: stable@vger.kernel.org (2.6.32+)
164Fixes: 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8
165Cc: Yuri Tikhonov <yur@emcraft.com>
166Cc: Dan Williams <dan.j.williams@intel.com>
167Reported-by: "Manibalan P" <pmanibalan@amiindia.co.in>
168Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423
169Signed-off-by: NeilBrown <neilb@suse.de>
170
171diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
172index 6b2d615d1094..183588b11fc1 100644
173--- a/drivers/md/raid5.c
174+++ b/drivers/md/raid5.c
175@@ -3817,6 +3817,8 @@ static void handle_stripe(struct stripe_head *sh)
176 set_bit(R5_Wantwrite, &dev->flags);
177 if (prexor)
178 continue;
179+ if (s.failed > 1)
180+ continue;
181 if (!test_bit(R5_Insync, &dev->flags) ||
182 ((i == sh->pd_idx || i == sh->qd_idx) &&
183 s.failed == 0))
184
185
This page took 0.763152 seconds and 4 git commands to generate.