Patch Detail

HTTP 200 OK
Allow: GET, PUT, PATCH, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "id": 810307,
    "url": "http://patchwork.ozlabs.org/api/patches/810307/?format=api",
    "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/patch/20170905223541.20594-9-ross.zwisler@linux.intel.com/",
    "project": {
        "id": 8,
        "url": "http://patchwork.ozlabs.org/api/projects/8/?format=api",
        "name": "Linux ext4 filesystem development",
        "link_name": "linux-ext4",
        "list_id": "linux-ext4.vger.kernel.org",
        "list_email": "linux-ext4@vger.kernel.org",
        "web_url": null,
        "scm_url": null,
        "webscm_url": null,
        "list_archive_url": "",
        "list_archive_url_format": "",
        "commit_url_format": ""
    },
    "msgid": "<20170905223541.20594-9-ross.zwisler@linux.intel.com>",
    "list_archive_url": null,
    "date": "2017-09-05T22:35:40",
    "name": "[8/9] ext4: add sanity check for encryption + DAX",
    "commit_ref": null,
    "pull_url": null,
    "state": "new",
    "archived": true,
    "hash": "21c567555bb742d0095d00ca2c31812c5b60b417",
    "submitter": {
        "id": 46514,
        "url": "http://patchwork.ozlabs.org/api/people/46514/?format=api",
        "name": "Ross Zwisler",
        "email": "ross.zwisler@linux.intel.com"
    },
    "delegate": null,
    "mbox": "http://patchwork.ozlabs.org/project/linux-ext4/patch/20170905223541.20594-9-ross.zwisler@linux.intel.com/mbox/",
    "series": [
        {
            "id": 1660,
            "url": "http://patchwork.ozlabs.org/api/series/1660/?format=api",
            "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/list/?series=1660",
            "date": "2017-09-05T22:35:36",
            "name": "add ext4 per-inode DAX flag",
            "version": 1,
            "mbox": "http://patchwork.ozlabs.org/series/1660/mbox/"
        }
    ],
    "comments": "http://patchwork.ozlabs.org/api/patches/810307/comments/",
    "check": "pending",
    "checks": "http://patchwork.ozlabs.org/api/patches/810307/checks/",
    "tags": {},
    "related": [],
    "headers": {
        "Return-Path": "<linux-ext4-owner@vger.kernel.org>",
        "X-Original-To": "patchwork-incoming@ozlabs.org",
        "Delivered-To": "patchwork-incoming@ozlabs.org",
        "Authentication-Results": "ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-ext4-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)",
        "Received": [
            "from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xn1nS5Rrgz9t2v\n\tfor <patchwork-incoming@ozlabs.org>;\n\tWed,  6 Sep 2017 08:37:48 +1000 (AEST)",
            "(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754085AbdIEWhp (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tTue, 5 Sep 2017 18:37:45 -0400",
            "from mga01.intel.com ([192.55.52.88]:63245 \"EHLO mga01.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754060AbdIEWgW (ORCPT <rfc822;linux-ext4@vger.kernel.org>);\n\tTue, 5 Sep 2017 18:36:22 -0400",
            "from fmsmga004.fm.intel.com ([10.253.24.48])\n\tby fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t05 Sep 2017 15:36:18 -0700",
            "from theros.lm.intel.com ([10.232.112.77])\n\tby fmsmga004.fm.intel.com with ESMTP; 05 Sep 2017 15:36:18 -0700"
        ],
        "X-ExtLoop1": "1",
        "X-IronPort-AV": "E=Sophos;i=\"5.41,481,1498546800\"; d=\"scan'208\";a=\"308314895\"",
        "From": "Ross Zwisler <ross.zwisler@linux.intel.com>",
        "To": "Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org",
        "Cc": "Ross Zwisler <ross.zwisler@linux.intel.com>,\n\t\"Darrick J. Wong\" <darrick.wong@oracle.com>,\n\t\"Theodore Ts'o\" <tytso@mit.edu>,\n\tAndreas Dilger <adilger.kernel@dilger.ca>,\n\tChristoph Hellwig <hch@lst.de>, Dan Williams <dan.j.williams@intel.com>,\n\tDave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,\n\tlinux-ext4@vger.kernel.org, linux-nvdimm@lists.01.org,\n\tlinux-xfs@vger.kernel.org, stable@vger.kernel.org",
        "Subject": "[PATCH 8/9] ext4: add sanity check for encryption + DAX",
        "Date": "Tue,  5 Sep 2017 16:35:40 -0600",
        "Message-Id": "<20170905223541.20594-9-ross.zwisler@linux.intel.com>",
        "X-Mailer": "git-send-email 2.9.5",
        "In-Reply-To": "<20170905223541.20594-1-ross.zwisler@linux.intel.com>",
        "References": "<20170905223541.20594-1-ross.zwisler@linux.intel.com>",
        "Sender": "linux-ext4-owner@vger.kernel.org",
        "Precedence": "bulk",
        "List-ID": "<linux-ext4.vger.kernel.org>",
        "X-Mailing-List": "linux-ext4@vger.kernel.org"
    },
    "content": "We prevent DAX from being used on inodes which are using ext4's built in\nencryption via a check in ext4_should_use_dax().  We do have what appears\nto be an unsafe transition of S_DAX in ext4_set_context(), though, where\nS_DAX can get disabled without us doing a proper writeback + invalidate.\n\nI actually think we are safe in this case because of the following:\n\n1) You can't encrypt an existing file.  Encryption can only be set on an\nempty directory, with new inodes in that directory being created with\nencryption turned on, so I don't think it's possible to turn encryption on\nfor a file that has open DAX mmaps or outstanding I/Os.\n\n2) There is no way to turn encryption off on a given file.  Once an inode\nis encrypted, it stays encrypted for the life of that inode, so we don't\nhave to worry about the case where we turn encryption off and S_DAX\nsuddenly turns on.\n\n3) The only way we end up in ext4_set_context() to turn on encryption is\nwhen we are creating a new file in the encrypted directory.  This happens\nas part of ext4_create() before the inode has been allowed to do any I/O.\nHere's the call tree:\n\n ext4_create()\n   __ext4_new_inode()\n\t ext4_set_inode_flags() // sets S_DAX\n\t fscrypt_inherit_context()\n\t\tfscrypt_get_encryption_info();\n\t\text4_set_context() // sets EXT4_INODE_ENCRYPT, clears S_DAX\n\nSo, I actually think it's safe to transition S_DAX in ext4_set_context()\nwithout any locking, writebacks or invalidations.  I've added a\nWARN_ON_ONCE() sanity check to make sure that we are notified if we ever\nencounter a case where we are encrypting an inode that already has data,\nin which case we need to add code to safely transition S_DAX.\n\nSigned-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>\nCC: stable@vger.kernel.org\n---\n fs/ext4/super.c | 3 +++\n 1 file changed, 3 insertions(+)",
    "diff": "diff --git a/fs/ext4/super.c b/fs/ext4/super.c\nindex d549dfb..6604a18 100644\n--- a/fs/ext4/super.c\n+++ b/fs/ext4/super.c\n@@ -1159,6 +1159,9 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len,\n \tif (inode->i_ino == EXT4_ROOT_INO)\n \t\treturn -EPERM;\n \n+\tif (WARN_ON_ONCE(IS_DAX(inode) && i_size_read(inode)))\n+\t\treturn -EINVAL;\n+\n \tres = ext4_convert_inline_data(inode);\n \tif (res)\n \t\treturn res;\n",
    "prefixes": [
        "8/9"
    ]
}