lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070921150540.fa285609.akpm@linux-foundation.org>
Date:	Fri, 21 Sep 2007 15:05:40 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Michael Halcrow <mhalcrow@...ibm.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	ecryptfs-devel@...ts.sourceforge.net
Subject: Re: [Ecryptfs-devel] [PATCH 3/11] eCryptfs: read_write.c routines

On Fri, 21 Sep 2007 16:51:25 -0500
Michael Halcrow <mhalcrow@...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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ