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)
-
-From 1e2ee49f7f1b79f0b14884fe6a602f0411b39552 Mon Sep 17 00:00:00 2001
-From: Will Woods <wwoods@redhat.com>
-Date: Tue, 6 May 2014 12:50:10 -0700
-Subject: fanotify: fix -EOVERFLOW with large files on 64-bit
-
-On 64-bit systems, O_LARGEFILE is automatically added to flags inside
-the open() syscall (also openat(), blkdev_open(), etc). Userspace
-therefore defines O_LARGEFILE to be 0 - you can use it, but it's a
-no-op. Everything should be O_LARGEFILE by default.
-
-But: when fanotify does create_fd() it uses dentry_open(), which skips
-all that. And userspace can't set O_LARGEFILE in fanotify_init()
-because it's defined to 0. So if fanotify gets an event regarding a
-large file, the read() will just fail with -EOVERFLOW.
-
-This patch adds O_LARGEFILE to fanotify_init()'s event_f_flags on 64-bit
-systems, using the same test as open()/openat()/etc.
-
-Addresses https://bugzilla.redhat.com/show_bug.cgi?id=696821
-
-Signed-off-by: Will Woods <wwoods@redhat.com>
-Acked-by: Eric Paris <eparis@redhat.com>
-Reviewed-by: Jan Kara <jack@suse.cz>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
-diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
-index 4e565c8..732648b 100644
---- a/fs/notify/fanotify/fanotify_user.c
-+++ b/fs/notify/fanotify/fanotify_user.c
-@@ -698,6 +698,8 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags)
- }
- group->overflow_event = &oevent->fse;
-
-+ if (force_o_largefile())
-+ event_f_flags |= O_LARGEFILE;
- group->fanotify_data.f_flags = event_f_flags;
- #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
- spin_lock_init(&group->fanotify_data.access_lock);
---
-cgit v0.10.1
-
-From 50c6e282bdf5e8dabf8d7cf7b162545a55645fd9 Mon Sep 17 00:00:00 2001
-From: Christoph Hellwig <hch@lst.de>
-Date: Sun, 4 May 2014 13:03:32 +0200
-Subject: posix_acl: handle NULL ACL in posix_acl_equiv_mode
-
-Various filesystems don't bother checking for a NULL ACL in
-posix_acl_equiv_mode, and thus can dereference a NULL pointer when it
-gets passed one. This usually happens from the NFS server, as the ACL tools
-never pass a NULL ACL, but instead of one representing the mode bits.
-
-Instead of adding boilerplat to all filesystems put this check into one place,
-which will allow us to remove the check from other filesystems as well later
-on.
-
-Signed-off-by: Christoph Hellwig <hch@lst.de>
-Reported-by: Ben Greear <greearb@candelatech.com>
-Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>,
-Cc: Chuck Lever <chuck.lever@oracle.com>
-Cc: stable@vger.kernel.org
-Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
-diff --git a/fs/posix_acl.c b/fs/posix_acl.c
-index 9e363e4..0855f77 100644
---- a/fs/posix_acl.c
-+++ b/fs/posix_acl.c
-@@ -246,6 +246,12 @@ posix_acl_equiv_mode(const struct posix_acl *acl, umode_t *mode_p)
- umode_t mode = 0;
- int not_equiv = 0;
-
-+ /*
-+ * A null ACL can always be presented as mode bits.
-+ */
-+ if (!acl)
-+ return 0;
-+
- FOREACH_ACL_ENTRY(pa, acl, pe) {
- switch (pa->e_tag) {
- case ACL_USER_OBJ:
---
-cgit v0.10.1
+
+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