summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Pagano <mpagano@gentoo.org>2015-09-28 20:05:46 -0400
committerMike Pagano <mpagano@gentoo.org>2015-09-28 20:05:46 -0400
commit5f1fcf42d2b9edd5baca2940182eb948753faf2a (patch)
tree19c961cdadfc6cf072506f31a66f384e441230a8
parentLinux patch 4.0.9 (diff)
downloadlinux-patches-4.0.tar.gz
linux-patches-4.0.tar.bz2
linux-patches-4.0.zip
dm crypt: constrain crypt device's max_segment_size to PAGE_SIZE. See bug #561558. Thanks to kipplasterjoe for reporting.4.0
-rw-r--r--0000_README4
-rw-r--r--1600_dm-crypt-limit-max-segment-size.patch84
2 files changed, 88 insertions, 0 deletions
diff --git a/0000_README b/0000_README
index 3ff77bb0..142ec40e 100644
--- a/0000_README
+++ b/0000_README
@@ -87,6 +87,10 @@ 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: 2600_select-REGMAP_IRQ-for-rt5033.patch
From: http://git.kernel.org/
Desc: mfd: rt5033: MFD_RT5033 needs to select REGMAP_IRQ. See bug #546938.
diff --git a/1600_dm-crypt-limit-max-segment-size.patch b/1600_dm-crypt-limit-max-segment-size.patch
new file mode 100644
index 00000000..82aca44e
--- /dev/null
+++ b/1600_dm-crypt-limit-max-segment-size.patch
@@ -0,0 +1,84 @@
+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
+