[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c80d1d0-0237-606f-91ce-a004c3694aa5@nod.at>
Date: Fri, 21 Oct 2016 15:17:03 +0200
From: Richard Weinberger <richard@....at>
To: Christoph Hellwig <hch@...radead.org>
Cc: linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, dedekind1@...il.com,
adrian.hunter@...el.com, tytso@....edu, jaegeuk@...nel.org,
david@...ma-star.at, wd@...x.de, sbabic@...x.de,
dengler@...utronix.de
Subject: Re: [PATCH 01/26] fscrypto: Add buffer operations
Christoph,
On 21.10.2016 15:05, Christoph Hellwig wrote:
> On Fri, Oct 21, 2016 at 02:48:16PM +0200, Richard Weinberger wrote:
>> Not all filesystems operate on pages, therefore offer
>> operations to en/decrypt buffers.
>> Of course these buffers have to be allocated in a way such that
>> the kernel crypto framework can work with them.
>
> Which means they need to be backed by the page allocator eventually.
> I think we'd better off providing the pages from ubifs from the API
> point of view. What are the issues with doing that?
>
UBIFS works on kmalloc()'ed buffers where it constructs the NAND/NOR pages
which will be written to the MTD. JFFS2 does the same.
So you suggest obtaining the struct page from the kmalloc()'ed buffer and
feeding it into fscrypto? This should work too.
I found the buffer operations approach more suitable.
Another reason why I did the buffer functions is because fscrypt_encrypt_page()
always allocates a bounce page as temporary memory. For ext4 this is needed,
for UBIFS not.
UBIFS has already a construction buffer, especially since it also does compression.
Thanks,
//richard
Powered by blists - more mailing lists