[{"id":1772454,"web_url":"http://patchwork.ozlabs.org/comment/1772454/","msgid":"<20170921064502.GR10621@dastard>","list_archive_url":null,"date":"2017-09-21T06:45:02","subject":"Re: [PATCH 00/25] fscrypt: add some higher-level helper functions","submitter":{"id":421,"url":"http://patchwork.ozlabs.org/api/people/421/","name":"Dave Chinner","email":"david@fromorbit.com"},"content":"On Wed, Sep 20, 2017 at 03:45:40PM -0700, Eric Biggers wrote:\n> From: Eric Biggers <ebiggers@google.com>\n> \n> This series reduces code duplication among ext4, f2fs, and ubifs by\n> introducing a S_ENCRYPTED inode flag (so we don't have to call back into\n> the filesystem to test the filesystem-specific inode flag), then\n> introducing new helper functions that are called at the beginning of the\n> open, link, rename, lookup, and setattr operations.\n> \n> In the future we maybe should even call these new helpers from the VFS\n> so that each individual filesystem doesn't have to do it.  But that's\n> not possible currently because fs/crypto/ can be built as a module.\n> \n> Making changes like this is a bit challenging due to interdependencies\n> between fscrypt and the individual filesystems, all of which have\n> different maintainers.  For now my intent is that patches 1-10 be taken\n> through the fscrypt tree --- though it's not perfect since patches 1-4\n> do make some changes to each filesystem, as everyone must set\n> S_ENCRYPTED before we can use it everywhere in the shared code.  But\n> afterwards, patches 11-25 can be picked up by the individual filesystems\n> to switch to the new helpers.\n\nThis all looks much nicer. Having just been looking at this stuff,\nit makes the code much simpler to understand. So:\n\nAcked-by: Dave Chinner <dchinner@redhat.com>\n\nWhile I'm here, the fscrypt header file includes are clunky and\nnasty. I worte a quick patch a couple of days ago to clean it up.\nSee below....\n\nCheers,\n\nDave.","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 3xyS0h3CnRz9s03\n\tfor <patchwork-incoming@ozlabs.org>;\n\tThu, 21 Sep 2017 16:50:12 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751679AbdIUGuL (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 02:50:11 -0400","from ipmail06.adl6.internode.on.net ([150.101.137.145]:38218 \"EHLO\n\tipmail06.adl6.internode.on.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751602AbdIUGuL (ORCPT\n\t<rfc822;linux-ext4@vger.kernel.org>);\n\tThu, 21 Sep 2017 02:50:11 -0400","from ppp59-167-129-252.static.internode.on.net (HELO dastard)\n\t([59.167.129.252]) by ipmail06.adl6.internode.on.net with ESMTP;\n\t21 Sep 2017 16:15:04 +0930","from dave by dastard with local (Exim 4.80)\n\t(envelope-from <david@fromorbit.com>)\n\tid 1duvEM-0001pl-Sg; Thu, 21 Sep 2017 16:45:02 +1000"],"X-Greylist":"delayed 304 seconds by postgrey-1.27 at vger.kernel.org;\n\tThu, 21 Sep 2017 02:50:10 EDT","X-IronPort-Anti-Spam-Filtered":"true","X-IronPort-Anti-Spam-Result":"A2DAAQB+XsNZ//yBpztbGQEBAQEBAQEBAQEBBwEBAQEBhSwngyuLX49FAQEBBoEqjRuJHIElA1yFPwICAQEChUABAgEBAQEBAmsohRgBAQEBAycTHCMQCAMOBwMJJQ8FJQMhE4omDKktOop+AQEBBwIBJSGDCoELggCCLIIbgQ2EQIYuBaETlEqTCJZzV04/MiEIHBWFYR2BeS42iSIBAQE","Date":"Thu, 21 Sep 2017 16:45:02 +1000","From":"Dave Chinner <david@fromorbit.com>","To":"Eric Biggers <ebiggers3@gmail.com>","Cc":"linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,\n\tlinux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,\n\tlinux-mtd@lists.infradead.org, \"Theodore Y . Ts'o\" <tytso@mit.edu>,\n\tJaegeuk Kim <jaegeuk@kernel.org>, Michael Halcrow <mhalcrow@google.com>,\n\tEric Biggers <ebiggers@google.com>","Subject":"Re: [PATCH 00/25] fscrypt: add some higher-level helper functions","Message-ID":"<20170921064502.GR10621@dastard>","References":"<20170920224605.22030-1-ebiggers3@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170920224605.22030-1-ebiggers3@gmail.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-ext4-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-ext4.vger.kernel.org>","X-Mailing-List":"linux-ext4@vger.kernel.org"}},{"id":1772834,"web_url":"http://patchwork.ozlabs.org/comment/1772834/","msgid":"<d7d91976-65b9-63d9-f34e-b322a9d0c472@kernel.org>","list_archive_url":null,"date":"2017-09-21T14:19:49","subject":"Re: [f2fs-dev] [PATCH 00/25] fscrypt: add some higher-level helper\n\tfunctions","submitter":{"id":69001,"url":"http://patchwork.ozlabs.org/api/people/69001/","name":"Chao Yu","email":"chao@kernel.org"},"content":"On 2017/9/21 6:45, Eric Biggers wrote:\n> From: Eric Biggers <ebiggers@google.com>\n> \n> This series reduces code duplication among ext4, f2fs, and ubifs by\n> introducing a S_ENCRYPTED inode flag (so we don't have to call back into\n> the filesystem to test the filesystem-specific inode flag), then\n> introducing new helper functions that are called at the beginning of the\n> open, link, rename, lookup, and setattr operations.\n> \n> In the future we maybe should even call these new helpers from the VFS\n> so that each individual filesystem doesn't have to do it.  But that's\n> not possible currently because fs/crypto/ can be built as a module.\n> \n> Making changes like this is a bit challenging due to interdependencies\n> between fscrypt and the individual filesystems, all of which have\n> different maintainers.  For now my intent is that patches 1-10 be taken\n> through the fscrypt tree --- though it's not perfect since patches 1-4\n> do make some changes to each filesystem, as everyone must set\n> S_ENCRYPTED before we can use it everywhere in the shared code.  But\n> afterwards, patches 11-25 can be picked up by the individual filesystems\n> to switch to the new helpers.\n\nFor all patches touching f2fs, looks good to me, feel free to add:\n\nReviewed-by: Chao Yu <yuchao0@huawei.com>\n\n> \n> Eric Biggers (25):\n>   fs, fscrypt: add an S_ENCRYPTED inode flag\n>   fscrypt: switch from ->is_encrypted() to IS_ENCRYPTED()\n>   fscrypt: remove ->is_encrypted()\n>   fscrypt: remove unneeded empty fscrypt_operations structs\n>   fscrypt: new helper function - fscrypt_require_key()\n>   fscrypt: new helper function - fscrypt_file_open()\n>   fscrypt: new helper function - fscrypt_prepare_link()\n>   fscrypt: new helper function - fscrypt_prepare_rename()\n>   fscrypt: new helper function - fscrypt_prepare_lookup()\n>   fscrypt: new helper function - fscrypt_prepare_setattr()\n>   ext4: switch to fscrypt_file_open()\n>   ext4: switch to fscrypt_prepare_link()\n>   ext4: switch to fscrypt_prepare_rename()\n>   ext4: switch to fscrypt_prepare_lookup()\n>   ext4: switch to fscrypt_prepare_setattr()\n>   f2fs: switch to fscrypt_file_open()\n>   f2fs: switch to fscrypt_prepare_link()\n>   f2fs: switch to fscrypt_prepare_rename()\n>   f2fs: switch to fscrypt_prepare_lookup()\n>   f2fs: switch to fscrypt_prepare_setattr()\n>   ubifs: switch to fscrypt_file_open()\n>   ubifs: switch to fscrypt_prepare_link()\n>   ubifs: switch to fscrypt_prepare_rename()\n>   ubifs: switch to fscrypt_prepare_lookup()\n>   ubifs: switch to fscrypt_prepare_setattr()\n> \n>  fs/crypto/Makefile              |   2 +-\n>  fs/crypto/crypto.c              |   2 +-\n>  fs/crypto/fname.c               |   3 +-\n>  fs/crypto/hooks.c               | 112 +++++++++++++++++++++++++++++\n>  fs/crypto/keyinfo.c             |   2 +-\n>  fs/crypto/policy.c              |   6 +-\n>  fs/ext4/file.c                  |  23 ++----\n>  fs/ext4/inode.c                 |  19 +++--\n>  fs/ext4/namei.c                 |  62 +++++-----------\n>  fs/ext4/super.c                 |  15 ++--\n>  fs/f2fs/f2fs.h                  |   1 +\n>  fs/f2fs/file.c                  |  30 ++------\n>  fs/f2fs/inode.c                 |   5 +-\n>  fs/f2fs/namei.c                 |  54 ++++----------\n>  fs/f2fs/super.c                 |   7 +-\n>  fs/ubifs/crypto.c               |   1 -\n>  fs/ubifs/dir.c                  |  43 ++++-------\n>  fs/ubifs/file.c                 |  41 ++---------\n>  fs/ubifs/ioctl.c                |   5 +-\n>  fs/ubifs/super.c                |   8 +--\n>  fs/ubifs/ubifs.h                |   9 +--\n>  fs/ubifs/xattr.c                |   1 +\n>  include/linux/fs.h              |   2 +\n>  include/linux/fscrypt_common.h  |   1 -\n>  include/linux/fscrypt_notsupp.h |  54 +++++++++++++-\n>  include/linux/fscrypt_supp.h    | 153 ++++++++++++++++++++++++++++++++++++++++\n>  26 files changed, 418 insertions(+), 243 deletions(-)\n>  create mode 100644 fs/crypto/hooks.c\n>","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>)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=chao@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyf0M5NJhz9s06\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 22 Sep 2017 00:20:35 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751926AbdIUOUd (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 10:20:33 -0400","from mail.kernel.org ([198.145.29.99]:53162 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751629AbdIUOUa (ORCPT <rfc822;linux-ext4@vger.kernel.org>);\n\tThu, 21 Sep 2017 10:20:30 -0400","from [192.168.0.101] (unknown [49.77.233.154])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id E11B1217C5;\n\tThu, 21 Sep 2017 14:20:23 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org E11B1217C5","Subject":"Re: [f2fs-dev] [PATCH 00/25] fscrypt: add some higher-level helper\n\tfunctions","To":"Eric Biggers <ebiggers3@gmail.com>, linux-fscrypt@vger.kernel.org","Cc":"\"Theodore Y . Ts'o\" <tytso@mit.edu>, Eric Biggers <ebiggers@google.com>,\n\tMichael Halcrow <mhalcrow@google.com>,\n\tlinux-f2fs-devel@lists.sourceforge.net,\n\tlinux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,\n\tJaegeuk Kim <jaegeuk@kernel.org>, linux-ext4@vger.kernel.org","References":"<20170920224605.22030-1-ebiggers3@gmail.com>","From":"Chao Yu <chao@kernel.org>","Message-ID":"<d7d91976-65b9-63d9-f34e-b322a9d0c472@kernel.org>","Date":"Thu, 21 Sep 2017 22:19:49 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170920224605.22030-1-ebiggers3@gmail.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-ext4-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-ext4.vger.kernel.org>","X-Mailing-List":"linux-ext4@vger.kernel.org"}},{"id":1773030,"web_url":"http://patchwork.ozlabs.org/comment/1773030/","msgid":"<20170921174705.GA29643@gmail.com>","list_archive_url":null,"date":"2017-09-21T17:47:05","subject":"Re: [PATCH 00/25] fscrypt: add some higher-level helper functions","submitter":{"id":65202,"url":"http://patchwork.ozlabs.org/api/people/65202/","name":"Eric Biggers","email":"ebiggers3@gmail.com"},"content":"Hi Dave,\n\nOn Thu, Sep 21, 2017 at 04:45:02PM +1000, Dave Chinner wrote:\n> fscrypto: clean up include file mess\n> \n> From: Dave Chinner <dchinner@redhat.com>\n> \n> Filesystems have to include different header files based on whether\n> they are compiled with encryption support or not. That's nasty and\n> messy.\n> \n> Instead, rationalise the headers so we have a single include\n> fscrypt.h and let it decide what internal implementation to include\n> based on the __FS_HAS_ENCRYPTION define. Filesystems set\n> __FS_HAS_ENCRYPTION before including linux/fscrypt.h if they are\n> built with encryption support.\n> \n> Add guards to prevent fscrypt_supp.h and fscrypt_notsupp.h from\n> being directly included by filesystems.\n\nThis looks good; we probably should have done it that way originally.  This will\nallow us to have the inline functions like fscrypt_prepare_rename() defined in\nfscrypt.h, and then have supp/notsupp versions of __fscrypt_prepare_rename()\ninstead --- so common checks like for IS_ENCRYPTED() will be in one place only.\n\nOne nit:\n\n> +#ifdef CONFIG_EXT4_FS_ENCRYPTION\n> +#define __FS_HAS_ENCRYPTION 1\n> +#endif\n> +#include <linux/fscrypt.h>\n\nHow about doing\n\n\t#define __FS_HAS_ENCRYPTION IS_ENABLED(CONFIG_EXT4_FS_ENCRYPTION)\n\n(and likewise for f2fs and ubifs), then checking '#if __FS_HAS_ENCRYPTION'\nrather than '#ifdef __FS_HAS_ENCRYPTION'?\n\nEric","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>)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"ZKIIbYf2\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xykZk6DhNz9s7h\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 22 Sep 2017 03:47:10 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751686AbdIURrK (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 13:47:10 -0400","from mail-pg0-f52.google.com ([74.125.83.52]:55387 \"EHLO\n\tmail-pg0-f52.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751647AbdIURrI (ORCPT\n\t<rfc822; linux-ext4@vger.kernel.org>); Thu, 21 Sep 2017 13:47:08 -0400","by mail-pg0-f52.google.com with SMTP id b11so3892049pgn.12;\n\tThu, 21 Sep 2017 10:47:08 -0700 (PDT)","from gmail.com ([2620:15c:17:3:5cbf:ff88:6574:7f3])\n\tby smtp.gmail.com with ESMTPSA id\n\ta1sm7630025pgu.47.2017.09.21.10.47.07\n\t(version=TLS1_2 cipher=AES128-SHA bits=128/128);\n\tThu, 21 Sep 2017 10:47:07 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=0eMZlhsxyzKAKBdwPXSYfxSnwww1NBS58egT3WuWCDE=;\n\tb=ZKIIbYf2gZuIoTSol1XpQg4v572X1TuVEjo3OBf771GiFe0D54Z7/84wwlHEliD9sL\n\tIkqi5WpitKy74SmsAqykLMJCCbjDSdbjoGAwEPsP2qnXDMgNsu8kfRtx2/6IrcyolpGj\n\tDUwcPTinsluQ/GdyDl8qAvdblcpa4w6ONkd5fe2A56mAHbZ+E/BAZFcMl+qiu1apy9pO\n\t/fnKdeWykqcRYFOJocLy3Y9zTlvtiutRu7d9Fcon8YW+EdLL2CWRFAtEzQZqVecz5UMI\n\tmUcafBeCml8Zueq10+VDAWtTcFnJuGniJn0OQWD6FD++WfPYe0qler2j2DbV+DFzE54+\n\t6XjA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=0eMZlhsxyzKAKBdwPXSYfxSnwww1NBS58egT3WuWCDE=;\n\tb=V+gX5nSPD6k7Nf9/yWNfvIy06pKczwhGm+WtVTZaz21c8tALLbnHPN8JKPaFs798+1\n\tqVrHo6ZHRikQcTanG14CUdf3UoR8uWJxcPrX1eJeNA8q2oC2b7wgzGn2u+w15TRcp/Ll\n\t+2v8L59GoSGu7WlOh59naIsfbrh1u6lJZJJEVG7Z/tiBtaHE18EOK9jW0PPYQlF855vN\n\tzf3dwRPSt8H5Soqmh9ozMrgVrgKs0pH8lVu/8LqEcTW8Ra232bb5ykFyzps45U7eIsEx\n\tb3wh3R1xIB033c6vUHcaODJPRhrUR7wcX0/cu6xztllfbn5JpDoeeKkNCCwL3be6/SH8\n\t+H2Q==","X-Gm-Message-State":"AHPjjUgz/fQsX9mSMbUJHMG569vzoTc6qjylRpTlE2SVdFqBEs5Jtzfd\n\tFATiz44vRIGMH/3RlzlttuU=","X-Google-Smtp-Source":"AOwi7QBhY2c4doD/tlhEPlAdHbdkEKnLTgbWsjEoufpASK9kSN0nAPs0sxcqSjk7WoweITUE0fppgA==","X-Received":"by 10.98.139.15 with SMTP id j15mr6482118pfe.33.1506016027949;\n\tThu, 21 Sep 2017 10:47:07 -0700 (PDT)","Date":"Thu, 21 Sep 2017 10:47:05 -0700","From":"Eric Biggers <ebiggers3@gmail.com>","To":"Dave Chinner <david@fromorbit.com>","Cc":"linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,\n\tlinux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,\n\tlinux-mtd@lists.infradead.org, \"Theodore Y . Ts'o\" <tytso@mit.edu>,\n\tJaegeuk Kim <jaegeuk@kernel.org>, Michael Halcrow <mhalcrow@google.com>,\n\tEric Biggers <ebiggers@google.com>","Subject":"Re: [PATCH 00/25] fscrypt: add some higher-level helper functions","Message-ID":"<20170921174705.GA29643@gmail.com>","References":"<20170920224605.22030-1-ebiggers3@gmail.com>\n\t<20170921064502.GR10621@dastard>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170921064502.GR10621@dastard>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-ext4-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-ext4.vger.kernel.org>","X-Mailing-List":"linux-ext4@vger.kernel.org"}},{"id":1773097,"web_url":"http://patchwork.ozlabs.org/comment/1773097/","msgid":"<20170921204814.GA7716@dastard>","list_archive_url":null,"date":"2017-09-21T20:48:14","subject":"Re: [PATCH 00/25] fscrypt: add some higher-level helper functions","submitter":{"id":421,"url":"http://patchwork.ozlabs.org/api/people/421/","name":"Dave Chinner","email":"david@fromorbit.com"},"content":"On Thu, Sep 21, 2017 at 10:47:05AM -0700, Eric Biggers wrote:\n> Hi Dave,\n> \n> On Thu, Sep 21, 2017 at 04:45:02PM +1000, Dave Chinner wrote:\n> > fscrypto: clean up include file mess\n> > \n> > From: Dave Chinner <dchinner@redhat.com>\n> > \n> > Filesystems have to include different header files based on whether\n> > they are compiled with encryption support or not. That's nasty and\n> > messy.\n> > \n> > Instead, rationalise the headers so we have a single include\n> > fscrypt.h and let it decide what internal implementation to include\n> > based on the __FS_HAS_ENCRYPTION define. Filesystems set\n> > __FS_HAS_ENCRYPTION before including linux/fscrypt.h if they are\n> > built with encryption support.\n> > \n> > Add guards to prevent fscrypt_supp.h and fscrypt_notsupp.h from\n> > being directly included by filesystems.\n> \n> This looks good; we probably should have done it that way originally.  This will\n> allow us to have the inline functions like fscrypt_prepare_rename() defined in\n> fscrypt.h, and then have supp/notsupp versions of __fscrypt_prepare_rename()\n> instead --- so common checks like for IS_ENCRYPTED() will be in one place only.\n\n*nod*\n\n> One nit:\n> \n> > +#ifdef CONFIG_EXT4_FS_ENCRYPTION\n> > +#define __FS_HAS_ENCRYPTION 1\n> > +#endif\n> > +#include <linux/fscrypt.h>\n> \n> How about doing\n> \n> \t#define __FS_HAS_ENCRYPTION IS_ENABLED(CONFIG_EXT4_FS_ENCRYPTION)\n> \n> (and likewise for f2fs and ubifs), then checking '#if __FS_HAS_ENCRYPTION'\n> rather than '#ifdef __FS_HAS_ENCRYPTION'?\n\nYeah, that's cleaner. I'll modify it and resend as a standalone\npatch.\n\nCheers,\n\nDave.","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 3xypbp4bv0z9s2G\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 22 Sep 2017 06:48:22 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751801AbdIUUsU (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 21 Sep 2017 16:48:20 -0400","from ipmail01.adl2.internode.on.net ([150.101.137.133]:33604 \"EHLO\n\tipmail01.adl2.internode.on.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751697AbdIUUsT (ORCPT\n\t<rfc822;linux-ext4@vger.kernel.org>);\n\tThu, 21 Sep 2017 16:48:19 -0400","from ppp59-167-129-252.static.internode.on.net (HELO dastard)\n\t([59.167.129.252]) by ipmail01.adl2.internode.on.net with ESMTP;\n\t22 Sep 2017 06:18:15 +0930","from dave by dastard with local (Exim 4.80)\n\t(envelope-from <david@fromorbit.com>)\n\tid 1dv8OM-0002in-NJ; Fri, 22 Sep 2017 06:48:14 +1000"],"X-IronPort-Anti-Spam-Filtered":"true","X-IronPort-Anti-Spam-Result":"A2DZAQCLJMRZ//yBpztbGQEBAQEBAQEBAQEBBwEBAQEBhSwnjwqPRQEBAQEBAQaBKo0biyGFPwICAQEChFcUAQIBAQEBAQEBayiFGAEBAQECATocIwULCAMOBwMJJQ8FJQMhE4omBQeqEYsDAQEBAQYCASUhgwqDC4VUiD2CMQWhE5RLkwuWdzYhgQ0yIQgcFYd3LjaLYAEBAQ","Date":"Fri, 22 Sep 2017 06:48:14 +1000","From":"Dave Chinner <david@fromorbit.com>","To":"Eric Biggers <ebiggers3@gmail.com>","Cc":"linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,\n\tlinux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,\n\tlinux-mtd@lists.infradead.org, \"Theodore Y . Ts'o\" <tytso@mit.edu>,\n\tJaegeuk Kim <jaegeuk@kernel.org>, Michael Halcrow <mhalcrow@google.com>,\n\tEric Biggers <ebiggers@google.com>","Subject":"Re: [PATCH 00/25] fscrypt: add some higher-level helper functions","Message-ID":"<20170921204814.GA7716@dastard>","References":"<20170920224605.22030-1-ebiggers3@gmail.com>\n\t<20170921064502.GR10621@dastard>\n\t<20170921174705.GA29643@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170921174705.GA29643@gmail.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-ext4-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-ext4.vger.kernel.org>","X-Mailing-List":"linux-ext4@vger.kernel.org"}}]