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: <E1MJPmn-0001Q6-Fj@pomaz-ex.szeredi.hu>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ