From: Andrew Morton <akpm@linux-foundation.org>
To: Michael Halcrow <mhalcrow@us.ibm.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
ecryptfs-devel@lists.sourceforge.net
Subject: Re: [Ecryptfs-devel] [PATCH 3/11] eCryptfs: read_write.c routines
Date: Fri, 21 Sep 2007 15:05:40 -0700 [thread overview]
Message-ID: <20070921150540.fa285609.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070921215125.GB11833@halcrow.austin.ibm.com>
On Fri, 21 Sep 2007 16:51:25 -0500
Michael Halcrow <mhalcrow@us.ibm.com> wrote:
> On Wed, Sep 19, 2007 at 10:38:50PM -0700, Andrew Morton wrote:
> > > + virt = kmap(page_for_lower);
> > > + rc = ecryptfs_write_lower(ecryptfs_inode, virt, offset, size);
> > > + kunmap(page_for_lower);
> > > + return rc;
> > > +}
> >
> > argh, kmap. http://lkml.org/lkml/2007/9/15/55
>
> Here is a patch that moves to kmap_atomic(), adding an intermediate
> copy. Although I would really like to find a way to avoid having to do
> this extra copy.
We might as well stick with kmap. I was just having a whine - I don't know
what to do about this really, apart from perhaps giving in to reality and
making kmap work better.
btw, I'm not really a great admirer of the whole patchset: it does some
pretty nasty-looking things: allocating dynamic memory, grabbing the
underlying pageframes with virt_to_page(), passing them back into kernel
APIs which are supposed to be called from userspace, etc. It's all rather
ugly and abusive-looking.
But given that you're trying to do things which the kernel just isn't set
up to do, it isn't immediately obvious what can be done to fix it.
Perhaps there are problems whcih I didn't have time to spot, and perhaps
there are things which could be done to improve it. But I don't have time
to sit down and absorb it all to a sufficient level of detail to be able to
suggest anything, and nobody else seems to be interested in reading the
patches so whoop, in it all goes.
next prev parent reply other threads:[~2007-09-21 22:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 21:44 [PATCH 0/11] eCryptfs: Introduce persistent lower files for each eCryptfs inode Michael Halcrow
2007-09-17 21:45 ` [PATCH 1/11] eCryptfs: Remove header_extent_size Michael Halcrow
2007-09-17 21:45 ` [PATCH 2/11] eCryptfs: Remove assignments in if-statements Michael Halcrow
2007-09-17 21:46 ` [PATCH 3/11] eCryptfs: read_write.c routines Michael Halcrow
2007-09-20 5:25 ` Andrew Morton
2007-09-20 5:38 ` Andrew Morton
2007-09-21 21:51 ` [Ecryptfs-devel] " Michael Halcrow
2007-09-21 22:05 ` Andrew Morton [this message]
2007-09-25 15:56 ` Michael Halcrow
2007-09-24 22:12 ` Michael Halcrow
2007-09-17 21:47 ` [PATCH 4/11] eCryptfs: Replace encrypt, decrypt, and inode size write Michael Halcrow
2007-09-20 5:46 ` Andrew Morton
2007-09-20 21:44 ` Michael Halcrow
2007-09-20 23:35 ` Erez Zadok
2007-09-17 21:47 ` [PATCH 5/11] eCryptfs: Set up and destroy persistent lower file Michael Halcrow
2007-09-17 21:48 ` [PATCH 6/11] eCryptfs: Update metadata read/write functions Michael Halcrow
2007-09-20 5:48 ` Andrew Morton
2007-09-24 22:40 ` Michael Halcrow
2007-09-17 21:49 ` [PATCH 7/11] eCryptfs: Make open, truncate, and setattr use persistent file Michael Halcrow
2007-09-17 21:50 ` [PATCH 8/11] eCryptfs: Convert mmap functions to " Michael Halcrow
2007-09-20 5:50 ` Andrew Morton
2007-09-20 22:03 ` Michael Halcrow
2007-09-17 21:50 ` [PATCH 9/11] eCryptfs: Initialize persistent lower file on inode create Michael Halcrow
2007-09-17 21:51 ` [PATCH 10/11] eCryptfs: Remove unused functions and kmem_cache Michael Halcrow
2007-09-17 21:52 ` [PATCH 11/11] eCryptfs: Replace magic numbers Michael Halcrow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070921150540.fa285609.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ecryptfs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).