From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55320 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033734AbeE2DCq (ORCPT ); Mon, 28 May 2018 23:02:46 -0400 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4T2wnNu039389 for ; Mon, 28 May 2018 23:02:44 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j8n0wh4y2-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 28 May 2018 23:02:43 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 May 2018 04:02:41 +0100 From: Chandan Rajendra To: "Theodore Y. Ts'o" Cc: linux-fscrypt@vger.kernel.org, ebiggers3@gmail.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH V3 07/12] mpage_readpage[s]: Introduce post process callback parameters Date: Tue, 29 May 2018 08:34:21 +0530 In-Reply-To: <20180528193437.GC3572@thunk.org> References: <20180522160110.1161-1-chandan@linux.vnet.ibm.com> <4837046.FSMeUsGny4@dhcp-9-109-247-5> <20180528193437.GC3572@thunk.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Message-Id: <1832647.byIzkSnT1k@localhost.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tuesday, May 29, 2018 1:04:37 AM IST Theodore Y. Ts'o wrote: > On Mon, May 28, 2018 at 11:05:52AM +0530, Chandan Rajendra wrote: > > > Can you describe more of what you are doing here; specifically, you > > > deleted all of fs/ext4/readpage.c --- was this because you moved > > > functionality back into fs/mpage.c? Did you make sure all of the > > > local changes in fs/ext4/readpage was moved back to fs/mpage.c? > > > > > > If the goal is to refactor code to remove the need for > > > fs/ext4/readpage.c, you should probably make that be the first patch > > > as a prerequisite patch. And we then need to make sure we don't > > > accidentally break anyone else who might be using fs/mpage.c. Saying > > > a bit more about why you think the refactor is a good thing would also > > > be useful. > > > > I will split this patch into two as suggested by you. Also, I will update > > the commit messages. > > Note that I was planning on making changes to fs/ext4/readpage.c as > part of integrating fsverity[1][2] support into ext4. Basically, I > need to do something like [3] to fs/ext4/readpage.c. > > [1] https://www.spinics.net/lists/linux-fsdevel/msg121182.html > [2] https://www.youtube.com/watch?v=GlEWcVuRbNA > [3] https://git.kernel.org/pub/scm/linux/kernel/git/mhalcrow/linux.git/commit/?h=fs-verity-dev&id=827faba05972517f49fa2f2aaf272150f5766af2 > > Which is why I'm really interested in your reasoning for why you > propose to drop fs/ext4/readpage.c. :-) > The first patchset to support encryption in subpage-blocksize scenario copied the block_read_full_page() from fs/buffer.c to ext4/readpage.c and had made changes required to support encryption in that function. However, the conclusion was to not create copies of existing code but rather add support for decryption inside generic mpage_readpage[s] functions. Hence this patchset implements the required decryption logic in the generic mpage_readpage[s] functions. Since this makes the code in ext4/readpage.c redundant, I had decided to delete the ext4/readpage.c. -- chandan