jforbes pushed to kernel (f22). "Linux v4.0.3"
notifications at fedoraproject.org
notifications at fedoraproject.org
Wed May 13 17:37:33 UTC 2015
From c22ccffa80f2108d240619e89ccf987c26bacc23 Mon Sep 17 00:00:00 2001
From: "Justin M. Forbes" <jforbes at redhat.com>
Date: Wed, 13 May 2015 12:37:21 -0500
Subject: Linux v4.0.3
diff --git a/SCSI-add-1024-max-sectors-black-list-flag.patch b/SCSI-add-1024-max-sectors-black-list-flag.patch
deleted file mode 100644
index a1ff662..0000000
--- a/SCSI-add-1024-max-sectors-black-list-flag.patch
+++ /dev/null
@@ -1,92 +0,0 @@
-From: Mike Christie <michaelc at cs.wisc.edu>
-Date: Tue, 21 Apr 2015 03:42:24 -0400
-Subject: [PATCH] SCSI: add 1024 max sectors black list flag
-
-This works around a issue with qnap iscsi targets not handling large IOs
-very well.
-
-The target returns:
-
-VPD INQUIRY: Block limits page (SBC)
- Maximum compare and write length: 1 blocks
- Optimal transfer length granularity: 1 blocks
- Maximum transfer length: 4294967295 blocks
- Optimal transfer length: 4294967295 blocks
- Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
- Maximum unmap LBA count: 8388607
- Maximum unmap block descriptor count: 1
- Optimal unmap granularity: 16383
- Unmap granularity alignment valid: 0
- Unmap granularity alignment: 0
- Maximum write same length: 0xffffffff blocks
- Maximum atomic transfer length: 0
- Atomic alignment: 0
- Atomic transfer length granularity: 0
-
-and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
-have seen in traces where it will sometimes work, but other times it
-looks like it fails and it looks like it returns failures if we send
-multiple large IOs sometimes. Also it looks like it can return 2 different
-errors. It will sometimes send iscsi reject errors indicating out of
-resources or it will send invalid cdb illegal requests check conditions.
-And then when it sends iscsi rejects it does not seem to handle retries
-when there are command sequence holes, so I could not just add code to
-try and gracefully handle that error code.
-
-The problem is that we do not have a good contact for the company,
-so we are not able to determine under what conditions it returns
-which error and why it sometimes works.
-
-So, this patch just adds a new black list flag to set targets like this to
-the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
-caused this regression, so I also ccing stable.
-
-Reported-by: Christian Hesse <list at eworm.de>
-Signed-off-by: Mike Christie <michaelc at cs.wisc.edu>
-Cc: stable at vger.kernel.org
----
- drivers/scsi/scsi_devinfo.c | 1 +
- drivers/scsi/scsi_scan.c | 6 ++++++
- include/scsi/scsi_devinfo.h | 1 +
- 3 files changed, 8 insertions(+)
-
-diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
-index 262ab837a704..9f77d23239a2 100644
---- a/drivers/scsi/scsi_devinfo.c
-+++ b/drivers/scsi/scsi_devinfo.c
-@@ -226,6 +226,7 @@ static struct {
- {"PIONEER", "CD-ROM DRM-624X", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
- {"Promise", "VTrak E610f", NULL, BLIST_SPARSELUN | BLIST_NO_RSOC},
- {"Promise", "", NULL, BLIST_SPARSELUN},
-+ {"QNAP", "iSCSI Storage", NULL, BLIST_MAX_1024},
- {"QUANTUM", "XP34301", "1071", BLIST_NOTQ},
- {"REGAL", "CDC-4X", NULL, BLIST_MAX5LUN | BLIST_SINGLELUN},
- {"SanDisk", "ImageMate CF-SD1", NULL, BLIST_FORCELUN},
-diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
-index 9c0a520d933c..3e6142f61499 100644
---- a/drivers/scsi/scsi_scan.c
-+++ b/drivers/scsi/scsi_scan.c
-@@ -897,6 +897,12 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result,
- */
- if (*bflags & BLIST_MAX_512)
- blk_queue_max_hw_sectors(sdev->request_queue, 512);
-+ /*
-+ * Max 1024 sector transfer length for targets that report incorrect
-+ * max/optimal lengths and relied on the old block layer safe default
-+ */
-+ else if (*bflags & BLIST_MAX_1024)
-+ blk_queue_max_hw_sectors(sdev->request_queue, 1024);
-
- /*
- * Some devices may not want to have a start command automatically
-diff --git a/include/scsi/scsi_devinfo.h b/include/scsi/scsi_devinfo.h
-index 183eaab7c380..96e3f56519e7 100644
---- a/include/scsi/scsi_devinfo.h
-+++ b/include/scsi/scsi_devinfo.h
-@@ -36,5 +36,6 @@
- for sequential scan */
- #define BLIST_TRY_VPD_PAGES 0x10000000 /* Attempt to read VPD pages */
- #define BLIST_NO_RSOC 0x20000000 /* don't try to issue RSOC */
-+#define BLIST_MAX_1024 0x40000000 /* maximum 1024 sector cdb length */
-
- #endif
diff --git a/ipv4-Missing-sk_nulls_node_init-in-ping_unhash.patch b/ipv4-Missing-sk_nulls_node_init-in-ping_unhash.patch
deleted file mode 100644
index 949c03f..0000000
--- a/ipv4-Missing-sk_nulls_node_init-in-ping_unhash.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From: "David S. Miller" <davem at davemloft.net>
-Date: Fri, 1 May 2015 22:02:47 -0400
-Subject: [PATCH] ipv4: Missing sk_nulls_node_init() in ping_unhash().
-
-If we don't do that, then the poison value is left in the ->pprev
-backlink.
-
-This can cause crashes if we do a disconnect, followed by a connect().
-
-Tested-by: Linus Torvalds <torvalds at linux-foundation.org>
-Reported-by: Wen Xu <hotdog3645 at gmail.com>
-Signed-off-by: David S. Miller <davem at davemloft.net>
----
- net/ipv4/ping.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
-index 208d5439e59b..787b0d699969 100644
---- a/net/ipv4/ping.c
-+++ b/net/ipv4/ping.c
-@@ -158,6 +158,7 @@ void ping_unhash(struct sock *sk)
- if (sk_hashed(sk)) {
- write_lock_bh(&ping_table.lock);
- hlist_nulls_del(&sk->sk_nulls_node);
-+ sk_nulls_node_init(&sk->sk_nulls_node);
- sock_put(sk);
- isk->inet_num = 0;
- isk->inet_sport = 0;
diff --git a/kernel.spec b/kernel.spec
index 38a65be..018f183 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -52,7 +52,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
-%define stable_update 2
+%define stable_update 3
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev %{stable_update}
@@ -636,18 +636,12 @@ Patch26182: Input-atmel_mxt_ts-add-support-for-Google-Pixel-2.patch
Patch26183: 0001-ALSA-hda-realtek-Support-Dell-headset-mode-for-ALC28.patch
Patch26184: 0001-ALSA-hda-realtek-Support-headset-mode-for-ALC286-288.patch
-#rhbz 1208999
-Patch26177: SCSI-add-1024-max-sectors-black-list-flag.patch
-
#rhbz 1210857
Patch26192: blk-loop-avoid-too-many-pending-per-work-IO.patch
#rhbz 1206036 1215989
Patch26193: toshiba_acpi-Do-not-register-vendor-backlight-when-a.patch
-#CVE-2015-3636 rhbz 1218074 1218110
-Patch26194: ipv4-Missing-sk_nulls_node_init-in-ping_unhash.patch
-
#rhbz 1218662
Patch26199: libata-Blacklist-queued-TRIM-on-all-Samsung-800-seri.patch
@@ -1401,18 +1395,12 @@ ApplyPatch Input-atmel_mxt_ts-add-support-for-Google-Pixel-2.patch
ApplyPatch 0001-ALSA-hda-realtek-Support-Dell-headset-mode-for-ALC28.patch
ApplyPatch 0001-ALSA-hda-realtek-Support-headset-mode-for-ALC286-288.patch
-#rhbz 1208999
-ApplyPatch SCSI-add-1024-max-sectors-black-list-flag.patch
-
#rhbz 1210857
ApplyPatch blk-loop-avoid-too-many-pending-per-work-IO.patch
#rhbz 1206036 1215989
ApplyPatch toshiba_acpi-Do-not-register-vendor-backlight-when-a.patch
-#CVE-2015-3636 rhbz 1218074 1218110
-ApplyPatch ipv4-Missing-sk_nulls_node_init-in-ping_unhash.patch
-
#rhbz 1218662
ApplyPatch libata-Blacklist-queued-TRIM-on-all-Samsung-800-seri.patch
@@ -2266,6 +2254,9 @@ fi
#
#
%changelog
+* Wed May 13 2015 Justin M. Forbes <jforbes at fedoraproject.org> - 4.0.3-300
+- Linux v4.0.3
+
* Sat May 9 2015 Peter Robinson <pbrobinson at fedoraproject.org>
- Minor ARMv7 updates
diff --git a/sources b/sources
index c3d2521..8f13e05 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
a86916bd12798220da9eb4a1eec3616d linux-4.0.tar.xz
d125eecce68ab6fb5f1f23523c2c04b8 perf-man-4.0.tar.gz
-a5a2d31a62688759482968b9c1dc135c patch-4.0.2.xz
+0ccd3969e595402f4f6bed790d5481a6 patch-4.0.3.xz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?h=f22&id=c22ccffa80f2108d240619e89ccf987c26bacc23
More information about the scm-commits
mailing list