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:	Tue, 09 Feb 2010 15:59:48 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Tejun Heo <tj@...nel.org>
CC:	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 Tue, 09 Feb 2010, Tejun Heo wrote:
> Implement FUSE direct mmap support.  The server can redirect client
> mmap requests to any SHMLBA aligned offset in the custom address space
> attached to the fuse channel.  The address space is managed by the
> server using mmap/munmap(2).  The SHMLBA alignment requirement is
> necessary to avoid cache aliasing issues on archs with virtually
> indexed caches as FUSE direct mmaps are basically shared memory
> between clients and the server.
> 
> The direct mmap address space is backed by pinned kernel pages which
> are allocated on the first fault either from a client or the server.
> If used carelessly, this can easily waste and drain memory.
> Currently, a server must have CAP_SYS_ADMIN to manage dmmap regions by
> mmapping and munmapping the channel fd.

Okay, I'm a bit confused about these offsets.

Client asks to map a file at an offset.  Server receives offset, may
change it (but only by multiple of SHMLBA) then returns it to the
kernel.  The returned offset globally identifies not only the mapped
region but the page within the region.  Sounds neat.

But then fuse_do_mmap() goes and changes vma->vm_pgoff, which will
show up in /proc/PID/maps for example, which is really not nice.

Can't this page ID rather be put in vma->vm_private_data?

Also can we take this page ID abstraction a step further, and say that
the ID has nothing to do with the original offset, the only
requirement is that it'd globally identify all direct mapped pages.

And the coherency requirements would be satisfied by the
fuse_dev_mmap() code.  Haven't looked into what that would take, but
it sounds doable.

That would take the load off userspace having to search for a suitable
offset using some magic architecture dependent constant.

Otherwise I like the interface, it can be extended with fault and
reclaim requests and server side requests to load and save the map
contents as well.

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/