The patch below does not apply to the 4.2-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 36086d43f6575c081067de9855786a2fc91df77b Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <[email protected]>
Date: Sat, 3 Oct 2015 10:49:29 -0400
Subject: [PATCH] ext4 crypto: fix bugs in ext4_encrypted_zeroout()

Fix multiple bugs in ext4_encrypted_zeroout(), including one that
could cause us to write an encrypted zero page to the wrong location
on disk, potentially causing data and file system corruption.
Fortunately, this tends to only show up in stress tests, but even with
these fixes, we are seeing some test failures with generic/127 --- but
these are now caused by data failures instead of metadata corruption.

Since ext4_encrypted_zeroout() is only used for some optimizations to
keep the extent tree from being too fragmented, and
ext4_encrypted_zeroout() itself isn't all that optimized from a time
or IOPS perspective, disable the extent tree optimization for
encrypted inodes for now.  This prevents the data corruption issues
reported by generic/127 until we can figure out what's going wrong.

Signed-off-by: Theodore Ts'o <[email protected]>
Cc: [email protected]

diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c
index 879cb15b7a21..af06830bfc00 100644
--- a/fs/ext4/crypto.c
+++ b/fs/ext4/crypto.c
@@ -392,7 +392,13 @@ int ext4_encrypted_zeroout(struct inode *inode, struct 
ext4_extent *ex)
        ext4_lblk_t             lblk = ex->ee_block;
        ext4_fsblk_t            pblk = ext4_ext_pblock(ex);
        unsigned int            len = ext4_ext_get_actual_len(ex);
-       int                     err = 0;
+       int                     ret, err = 0;
+
+#if 0
+       ext4_msg(inode->i_sb, KERN_CRIT,
+                "ext4_encrypted_zeroout ino %lu lblk %u len %u",
+                (unsigned long) inode->i_ino, lblk, len);
+#endif
 
        BUG_ON(inode->i_sb->s_blocksize != PAGE_CACHE_SIZE);
 
@@ -418,17 +424,26 @@ int ext4_encrypted_zeroout(struct inode *inode, struct 
ext4_extent *ex)
                        goto errout;
                }
                bio->bi_bdev = inode->i_sb->s_bdev;
-               bio->bi_iter.bi_sector = pblk;
-               err = bio_add_page(bio, ciphertext_page,
+               bio->bi_iter.bi_sector =
+                       pblk << (inode->i_sb->s_blocksize_bits - 9);
+               ret = bio_add_page(bio, ciphertext_page,
                                   inode->i_sb->s_blocksize, 0);
-               if (err) {
+               if (ret != inode->i_sb->s_blocksize) {
+                       /* should never happen! */
+                       ext4_msg(inode->i_sb, KERN_ERR,
+                                "bio_add_page failed: %d", ret);
+                       WARN_ON(1);
                        bio_put(bio);
+                       err = -EIO;
                        goto errout;
                }
                err = submit_bio_wait(WRITE, bio);
+               if ((err == 0) && bio->bi_error)
+                       err = -EIO;
                bio_put(bio);
                if (err)
                        goto errout;
+               lblk++; pblk++;
        }
        err = 0;
 errout:
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 2553aa8b608d..7f486e350d15 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3558,6 +3558,9 @@ static int ext4_ext_convert_to_initialized(handle_t 
*handle,
                max_zeroout = sbi->s_extent_max_zeroout_kb >>
                        (inode->i_sb->s_blocksize_bits - 10);
 
+       if (ext4_encrypted_inode(inode))
+               max_zeroout = 0;
+
        /* If extent is less than s_max_zeroout_kb, zeroout directly */
        if (max_zeroout && (ee_len <= max_zeroout)) {
                err = ext4_ext_zeroout(inode, ex);

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to