linux-kernel - Re: [PATCH 4/4] FUSE: implement direct mmap

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:	Wed, 24 Jun 2009 12:33:01 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	tj@...nel.org
CC:	linux-kernel@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
	miklos@...redi.hu, akpm@...ux-foundation.org, npiggin@...e.de,
	tj@...nel.org
Subject: Re: [PATCH 4/4] FUSE: implement direct mmap

On Thu, 18 Jun 2009, Tejun Heo wrote:
> This patch implements direct mmap.  It allows FUSE server to honor
> each mmap request with anonymous mapping.  FUSE server can make
> multiple mmap requests share a single anonymous mapping or separate
> mappings as it sees fit.

One thing that worries me is that this isn't generic enough.  It may
be good for OSS emulation, but if someone would want to use it for
normal file based mmap, I don't think it would be usable: there's no
synchronization between normal I/O paths.

Now that's not a big problem as long as there's a possility to extend
the current interface in that direction.  E.g. add the possibility for
userspace to handle faults and unmap pages from the address space on
demand.

The other problem is that sharing address spaces between filesystems
in this way is inherently hackish.  CODA manages to get away with it,
but CODA doesn't want to reimplement mmap/munmap in exotic ways.

Is there s a possibility to do this without needing to share the
pages?  E.g. implement explicit calls (notifications) on the fuse
interface to read and write the mapped pages.  That would get rid of
all the ugly problems caused by having to pass and translate file
descriptors on the fuse interface.

> 
> mmap request is handled in two steps.  MMAP first queries the server
> whether it wants to share the mapping with an existing one or create a
> new one, and if so, with which flags.  MMAP_COMMIT notifies the server
> the result of mmap and if successful the fd the server can use to
> access the mmap region.

And you might have noticed I'm not a big fan of these three way handshake
messages ;)

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/