[gentoo-commits] proj/linux-patches:4.2 commit in: /

["Mike Pagano" <mpagano@gentoo.org>]

commit:     6bc02433d40973c69bd8f87e1f849c63dc01a3c4
Author:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
AuthorDate: Fri Oct 23 17:19:17 2015 +0000
Commit:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
CommitDate: Fri Oct 23 17:19:17 2015 +0000
URL:        https://gitweb.gentoo.org/proj/linux-patches.git/commit/?id=6bc02433

Remove redundant patch.

 0000_README                                |  4 --
 1600_dm-crypt-limit-max-segment-size.patch | 84 ------------------------------
 2 files changed, 88 deletions(-)

diff --git a/0000_README b/0000_README
index 2a467c2..daafdd3 100644
--- a/0000_README
+++ b/0000_README
@@ -67,10 +67,6 @@ Patch:  1510_fs-enable-link-security-restrictions-by-default.patch
 From:   http://sources.debian.net/src/linux/3.16.7-ckt4-3/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/
 Desc:   Enable link security restrictions by default.
 
-Patch:  1600_dm-crypt-limit-max-segment-size.patch
-From:   https://bugzilla.kernel.org/show_bug.cgi?id=104421
-Desc:   dm crypt: constrain crypt device's max_segment_size to PAGE_SIZE.
-
 Patch:  2700_ThinkPad-30-brightness-control-fix.patch
 From:   Seth Forshee <seth.forshee@canonical.com>
 Desc:   ACPI: Disable Windows 8 compatibility for some Lenovo ThinkPads.

diff --git a/1600_dm-crypt-limit-max-segment-size.patch b/1600_dm-crypt-limit-max-segment-size.patch
deleted file mode 100644
index 82aca44..0000000
--- a/1600_dm-crypt-limit-max-segment-size.patch
+++ /dev/null
@@ -1,84 +0,0 @@
-From 586b286b110e94eb31840ac5afc0c24e0881fe34 Mon Sep 17 00:00:00 2001
-From: Mike Snitzer <snitzer@redhat.com>
-Date: Wed, 9 Sep 2015 21:34:51 -0400
-Subject: dm crypt: constrain crypt device's max_segment_size to PAGE_SIZE
-
-Setting the dm-crypt device's max_segment_size to PAGE_SIZE is an
-unfortunate constraint that is required to avoid the potential for
-exceeding dm-crypt's underlying device's max_segments limits -- due to
-crypt_alloc_buffer() possibly allocating pages for the encryption bio
-that are not as physically contiguous as the original bio.
-
-It is interesting to note that this problem was already fixed back in
-2007 via commit 91e106259 ("dm crypt: use bio_add_page").  But Linux 4.0
-commit cf2f1abfb ("dm crypt: don't allocate pages for a partial
-request") regressed dm-crypt back to _not_ using bio_add_page().  But
-given dm-crypt's cpu parallelization changes all depend on commit
-cf2f1abfb's abandoning of the more complex io fragments processing that
-dm-crypt previously had we cannot easily go back to using
-bio_add_page().
-
-So all said the cleanest way to resolve this issue is to fix dm-crypt to
-properly constrain the original bios entering dm-crypt so the encryption
-bios that dm-crypt generates from the original bios are always
-compatible with the underlying device's max_segments queue limits.
-
-It should be noted that technically Linux 4.3 does _not_ need this fix
-because of the block core's new late bio-splitting capability.  But, it
-is reasoned, there is little to be gained by having the block core split
-the encrypted bio that is composed of PAGE_SIZE segments.  That said, in
-the future we may revert this change.
-
-Fixes: cf2f1abfb ("dm crypt: don't allocate pages for a partial request")
-Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=104421
-Suggested-by: Jeff Moyer <jmoyer@redhat.com>
-Signed-off-by: Mike Snitzer <snitzer@redhat.com>
-Cc: stable@vger.kernel.org # 4.0+
-
-diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
-index d60c88d..4b3b6f8 100644
---- a/drivers/md/dm-crypt.c
-+++ b/drivers/md/dm-crypt.c
-@@ -968,7 +968,8 @@ static void crypt_free_buffer_pages(struct crypt_config *cc, struct bio *clone);
- 
- /*
-  * Generate a new unfragmented bio with the given size
-- * This should never violate the device limitations
-+ * This should never violate the device limitations (but only because
-+ * max_segment_size is being constrained to PAGE_SIZE).
-  *
-  * This function may be called concurrently. If we allocate from the mempool
-  * concurrently, there is a possibility of deadlock. For example, if we have
-@@ -2045,9 +2046,20 @@ static int crypt_iterate_devices(struct dm_target *ti,
- 	return fn(ti, cc->dev, cc->start, ti->len, data);
- }
- 
-+static void crypt_io_hints(struct dm_target *ti, struct queue_limits *limits)
-+{
-+	/*
-+	 * Unfortunate constraint that is required to avoid the potential
-+	 * for exceeding underlying device's max_segments limits -- due to
-+	 * crypt_alloc_buffer() possibly allocating pages for the encryption
-+	 * bio that are not as physically contiguous as the original bio.
-+	 */
-+	limits->max_segment_size = PAGE_SIZE;
-+}
-+
- static struct target_type crypt_target = {
- 	.name   = "crypt",
--	.version = {1, 14, 0},
-+	.version = {1, 14, 1},
- 	.module = THIS_MODULE,
- 	.ctr    = crypt_ctr,
- 	.dtr    = crypt_dtr,
-@@ -2058,6 +2070,7 @@ static struct target_type crypt_target = {
- 	.resume = crypt_resume,
- 	.message = crypt_message,
- 	.iterate_devices = crypt_iterate_devices,
-+	.io_hints = crypt_io_hints,
- };
- 
- static int __init dm_crypt_init(void)
--- 
-cgit v0.10.2
-