linux-kernel - Re: [fuse-devel] [PATCH] FUSE/CUSE: implement direct mmap support

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]

Date:	Fri, 12 Feb 2010 10:55:10 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Tejun Heo <tj@...nel.org>
CC:	miklos@...redi.hu, mszeredi@...e.cz, linux-kernel@...r.kernel.org,
	fuse-devel@...ts.sourceforge.net, polynomial-c@...too.org,
	akpm@...ux-foundation.org
Subject: Re: [fuse-devel] [PATCH] FUSE/CUSE: implement direct mmap support

On Fri, 12 Feb 2010, Tejun Heo wrote:
> The offset problem can't be fixed.  If you allow offsets to be
> adjusted in any way, SHMLBA requirement is gonna be there and for CUSE
> I think having the ability to adjust offset would be useful even if
> multiple files are used.  It can of course be hidden behind a
> highlevel library API tho.

Yes, offset issues can be fixed:

 1) don't change vma->vm_pgoff

 2) in fuse_mmap_out, call it dev_offset, dev_mmap_offset or whatever

 3) on the low level API don't make it an offset pointer that is
 adjusted.  It's not an offset to be either left alone or changed
 (that would be the case if we wanted to allow adjustment to
 vma->vm_pgoff itself).  It's about calclulating a completely new
 offset for the server side mmap.

> > The alternative is for me to start implementing a coherent distributed
> > filesystem, so I can see what the actual requirements for a direct
> > mmap would be.  That would be fun, but it would
> > 
> >   a) delay direct mmap for CUSE by an unknown amount of time
> >   b) delay everything else that I have in the pipeline ;)
> 
> Well, for CUSE, it has been delayed for a long time already so I don't
> think there would be much harm in waiting a bit more.  Any estimates
> on how long it would take?

Well if there were no higher priority things then I think I could do
that in a month.

I don't think I want a swap backed solution.  There is already a
backing for these maps and that is the userspace filesystem.  In fact
most of what is required is already there in the form of the page
cache.  What I think would be interesting to be able to load/save
contents of page cache from the server side, and not necessarily using
server side mmaps (server side mmap is also a possibility, but not an
easy one if it has to cooperate with the page cache).

Basically all we need to ensure, is that the mmap API doesn't conflict
with the above usage.  The problem is that the details for the above
usage will only come out with a real implementation.

Thanks,
Miklos
--
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/