From patchwork Wed Feb 22 21:22:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9587475 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9854B601AE for ; Wed, 22 Feb 2017 21:23:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 88B4227F94 for ; Wed, 22 Feb 2017 21:23:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7CD20286A3; Wed, 22 Feb 2017 21:23:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1250627F94 for ; Wed, 22 Feb 2017 21:23:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933829AbdBVVXK (ORCPT ); Wed, 22 Feb 2017 16:23:10 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36128 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932669AbdBVVXJ (ORCPT ); Wed, 22 Feb 2017 16:23:09 -0500 Received: by mail-pf0-f196.google.com with SMTP id c193so278242pfb.3; Wed, 22 Feb 2017 13:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=qIRreeh7Zwf6pLUvutHg2XGzGCDiPRvg9uVUlN0TG3M=; b=OrJe8eXMlrAEki+poM5cJqIbYS+N3H7zAi7tWwT31gcGVkG59aHNBIB0/7/ZIQGc8W rf/qPxKm9FG1bTfp4wM20lAw01KPYBR2zXfsRARgJc5uV/ZnhaRn9rIdh/Lry95W6BUG T+YRTZysvVvTmucHtzkCkEv/RHALJu/DA9rbQn3TKp2OfVA8QwNWMdjHkEN5Hr6YXbu7 /0oGfl4M84EYWh18oO7xiwClgqUYToA72XFCzJwyDZDF8Po59qnS1iixGNhfTaPemPz2 5QCq03HZgHV6ubbg4vScJPaSeUiI5YDG+GGZeBAWBcHPCPbin/0GoCQbFhNZj/xjSRQB qofQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=qIRreeh7Zwf6pLUvutHg2XGzGCDiPRvg9uVUlN0TG3M=; b=H5MozgqWn7I3E1Bto10EArCSLshkTOYrZFBgtu/fHkBcvuM0J8lcy6PYbaM4utuFiS bOsrQFEuyEK2125Uin0AHx4BIpmfMKMgnRpwQvcO15XEXvZdHdeK4zj4jLvOMQy49Yoq roJDtIsbunxqKcoWFnAoTHt1MXFE6XiYGSy6GM+LutBBIk1c14NKNj1HvGVXjI5dlF+A Rb/iDe++de5U9ZHCRxSvZ9qVgjJMxeWh43dYfKhfTEJannzm9hFXuI6l6b5nKp2wo8Dg +2CEon5+PTpo+K4L1xG9mHMzFFOtato2iot9ZHNnWKTYhJlg9tCiOOAiDGtxascalClw VIUw== X-Gm-Message-State: AMke39mCuPrPO8YY8+xzQ7Bx4VS0N3UpiZ5lqbJdVi7s04g3j2U6g+agffD0avVffEbLMA== X-Received: by 10.84.134.36 with SMTP id 33mr23180448plg.34.1487798588751; Wed, 22 Feb 2017 13:23:08 -0800 (PST) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.119.30.131]) by smtp.gmail.com with ESMTPSA id o66sm5325134pfa.119.2017.02.22.13.23.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Feb 2017 13:23:08 -0800 (PST) From: Eric Biggers To: linux-ext4@vger.kernel.org Cc: "Theodore Y . Ts'o" , Andreas Dilger , linux-fscrypt@vger.kernel.org, Eric Biggers , stable@vger.kernel.org Subject: [PATCH] ext4: mark inode dirty after converting inline directory Date: Wed, 22 Feb 2017 13:22:46 -0800 Message-Id: <20170222212246.60931-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.11.0.483.g087da7b7c-goog Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers If ext4_convert_inline_data() was called on a directory with inline data, the filesystem was left in an inconsistent state (as considered by e2fsck) because the file size was not increased to cover the new block. This happened because the inode was not marked dirty after i_disksize was updated. Fix this by marking the inode dirty at the end of ext4_finish_convert_inline_dir(). This bug was probably not noticed before because most users mark the inode dirty afterwards for other reasons. But if userspace executed FS_IOC_SET_ENCRYPTION_POLICY with invalid parameters, as exercised by 'kvm-xfstests -c adv generic/396', then the inode was never marked dirty after updating i_disksize. Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers --- fs/ext4/inline.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index 3a1f2822541b..75b29c25313c 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -1169,10 +1169,9 @@ static int ext4_finish_convert_inline_dir(handle_t *handle, set_buffer_uptodate(dir_block); err = ext4_handle_dirty_dirent_node(handle, inode, dir_block); if (err) - goto out; + return err; set_buffer_verified(dir_block); -out: - return err; + return ext4_mark_inode_dirty(handle, inode); } static int ext4_convert_inline_data_nolock(handle_t *handle,