fi
done
-diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
-index 7a0c800..ec5ebbb 100644
---- a/drivers/net/ethernet/realtek/r8169.c
-+++ b/drivers/net/ethernet/realtek/r8169.c
-@@ -6927,6 +6927,14 @@ rtl_init_one(struct pci_dev *pdev, const
- for (i = 0; i < ETH_ALEN; i++)
- dev->dev_addr[i] = RTL_R8(MAC0 + i);
-
-+ if (!is_valid_ether_addr(dev->dev_addr)) {
-+ /* Report it and use a random ethernet address instead */
-+ netdev_err(dev, "Invalid MAC address: %pM\n", dev->dev_addr);
-+ random_ether_addr(dev->dev_addr);
-+ netdev_info(dev, "Using random MAC address: %pM\n",
-+ dev->dev_addr);
-+ }
-+
- SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
- dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
-
-[PATCH] SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
-
-If a device has the skip_vpd_pages flag set we should simply fail the
-scsi_get_vpd_page() call.
-
-Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
-Acked-by: Alan Stern <stern@rowland.harvard.edu>
-Tested-by: Stuart Foster <smf.linux@ntlworld.com>
-Cc: stable@vger.kernel.org
-
-diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
-index 3b1ea34..eaa808e 100644
---- a/drivers/scsi/scsi.c
-+++ b/drivers/scsi/scsi.c
-@@ -1031,6 +1031,9 @@
- {
- int i, result;
-
-+ if (sdev->skip_vpd_pages)
-+ goto fail;
-+
- /* Ask for all the pages supported by this device */
- result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
- if (result)
-commit 4d0ed18277cc6f07513ee0b04475f19cd69e75ef
-Author: Peter Hurley <peter@hurleysoftware.com>
-Date: Tue Dec 10 17:12:02 2013 -0500
-
- n_tty: Fix buffer overruns with larger-than-4k pastes
-
- readline() inadvertently triggers an error recovery path when
- pastes larger than 4k overrun the line discipline buffer. The
- error recovery path discards input when the line discipline buffer
- is full and operating in canonical mode and no newline has been
- received. Because readline() changes the termios to non-canonical
- mode to read the line char-by-char, the line discipline buffer
- can become full, and then when readline() restores termios back
- to canonical mode for the caller, the now-full line discipline
- buffer triggers the error recovery.
-
- When changing termios from non-canon to canon mode and the read
- buffer contains data, simulate an EOF push _without_ the
- DISABLED_CHAR in the read buffer.
-
- Importantly for the readline() problem, the termios can be
- changed back to non-canonical mode without changes to the read
- buffer occurring; ie., as if the previous termios change had not
- happened (as long as no intervening read took place).
-
- Preserve existing userspace behavior which allows '\0's already
- received in non-canon mode to be read as '\0's in canon mode
- (rather than trigger add'l EOF pushes or an actual EOF).
-
- Patch based on original proposal and discussion here
- https://bugzilla.kernel.org/show_bug.cgi?id=55991
- by Stas Sergeev <stsp@users.sourceforge.net>
-
- Reported-by: Margarita Manterola <margamanterola@gmail.com>
- Cc: Maximiliano Curia <maxy@gnuservers.com.ar>
- Cc: Pavel Machek <pavel@ucw.cz>
- Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
- Acked-by: Stas Sergeev <stsp@users.sourceforge.net>
- Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
- Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
-diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
-index fdc2ecd..961e6a9 100644
---- a/drivers/tty/n_tty.c
-+++ b/drivers/tty/n_tty.c
-@@ -104,6 +104,7 @@ struct n_tty_data {
-
- /* must hold exclusive termios_rwsem to reset these */
- unsigned char lnext:1, erasing:1, raw:1, real_raw:1, icanon:1;
-+ unsigned char push:1;
-
- /* shared by producer and consumer */
- char read_buf[N_TTY_BUF_SIZE];
-@@ -341,6 +342,7 @@ static void reset_buffer_flags(struct n_tty_data *ldata)
-
- ldata->erasing = 0;
- bitmap_zero(ldata->read_flags, N_TTY_BUF_SIZE);
-+ ldata->push = 0;
- }
-
- static void n_tty_packet_mode_flush(struct tty_struct *tty)
-@@ -1745,7 +1747,16 @@ static void n_tty_set_termios(struct tty_struct *tty, struct ktermios *old)
-
- if (!old || (old->c_lflag ^ tty->termios.c_lflag) & ICANON) {
- bitmap_zero(ldata->read_flags, N_TTY_BUF_SIZE);
-- ldata->line_start = ldata->canon_head = ldata->read_tail;
-+ ldata->line_start = ldata->read_tail;
-+ if (!L_ICANON(tty) || !read_cnt(ldata)) {
-+ ldata->canon_head = ldata->read_tail;
-+ ldata->push = 0;
-+ } else {
-+ set_bit((ldata->read_head - 1) & (N_TTY_BUF_SIZE - 1),
-+ ldata->read_flags);
-+ ldata->canon_head = ldata->read_head;
-+ ldata->push = 1;
-+ }
- ldata->erasing = 0;
- ldata->lnext = 0;
- }
-@@ -1951,6 +1962,12 @@ static int copy_from_read_buf(struct tty_struct *tty,
- * it copies one line of input up to and including the line-delimiting
- * character into the user-space buffer.
- *
-+ * NB: When termios is changed from non-canonical to canonical mode and
-+ * the read buffer contains data, n_tty_set_termios() simulates an EOF
-+ * push (as if C-d were input) _without_ the DISABLED_CHAR in the buffer.
-+ * This causes data already processed as input to be immediately available
-+ * as input although a newline has not been received.
-+ *
- * Called under the atomic_read_lock mutex
- *
- * n_tty_read()/consumer path:
-@@ -1997,7 +2014,7 @@ static int canon_copy_from_read_buf(struct tty_struct *tty,
- n += found;
- c = n;
-
-- if (found && read_buf(ldata, eol) == __DISABLED_CHAR) {
-+ if (found && !ldata->push && read_buf(ldata, eol) == __DISABLED_CHAR) {
- n--;
- eof_push = !n && ldata->read_tail != ldata->line_start;
- }
-@@ -2024,7 +2041,10 @@ static int canon_copy_from_read_buf(struct tty_struct *tty,
- ldata->read_tail += c;
-
- if (found) {
-- ldata->line_start = ldata->read_tail;
-+ if (!ldata->push)
-+ ldata->line_start = ldata->read_tail;
-+ else
-+ ldata->push = 0;
- tty_audit_push(tty);
- }
- return eof_push ? -EAGAIN : 0;
+
+Hi all,
+ There is a risk of data loss with md/raid6 arrays running on Linux since
+ 2.6.32.
+ If:
+ - the array is doubly degraded
+ - one or both failed devices are being recovered, and
+ - the array is written to
+
+ then it is possible for data on the array to be lost. The patch below fixes
+ the problem. If you apply the patch to an older kernel which has separate
+ handle_stripe5() and handle_stripe6() functions, be sure that patch changes
+ handle_stripe6().
+
+ There is no risk to an optimal array or a singly-degraded array. There is
+ also no risk on a doubly-degraded array which is not recovering a device or
+ is not receiving write requests.
+
+ If you have data on a RAID6 array, please consider how to avoid corruption,
+ possibly by applying the patch, possibly by removing any hot spares so
+ recovery does not automatically start.
+
+ This patch will be sent upstream shortly and will subsequently appear in
+ future "-stable" kernels.
+
+NeilBrown
+
+From f94e37dce722ec7b6666fd04be357f422daa02b5 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Wed, 13 Aug 2014 09:57:07 +1000
+Subject: [PATCH] md/raid6: avoid data corruption during recovery of
+ double-degraded RAID6
+
+During recovery of a double-degraded RAID6 it is possible for
+some blocks not to be recovered properly, leading to corruption.
+
+If a write happens to one block in a stripe that would be written to a
+missing device, and at the same time that stripe is recovering data
+to the other missing device, then that recovered data may not be written.
+
+This patch skips, in the double-degraded case, an optimisation that is
+only safe for single-degraded arrays.
+
+Bug was introduced in 2.6.32 and fix is suitable for any kernel since
+then. In an older kernel with separate handle_stripe5() and
+handle_stripe6() functions that patch must change handle_stripe6().
+
+Cc: stable@vger.kernel.org (2.6.32+)
+Fixes: 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8
+Cc: Yuri Tikhonov <yur@emcraft.com>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Reported-by: "Manibalan P" <pmanibalan@amiindia.co.in>
+Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423
+Signed-off-by: NeilBrown <neilb@suse.de>
+
+diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
+index 6b2d615d1094..183588b11fc1 100644
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -3817,6 +3817,8 @@ static void handle_stripe(struct stripe_head *sh)
+ set_bit(R5_Wantwrite, &dev->flags);
+ if (prexor)
+ continue;
++ if (s.failed > 1)
++ continue;
+ if (!test_bit(R5_Insync, &dev->flags) ||
+ ((i == sh->pd_idx || i == sh->qd_idx) &&
+ s.failed == 0))
+
+
projects / packages / kernel.git / blobdiff