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 14:53:27 +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:
> >  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.
> 
> And now I'm completely lost.  So, we'll assign new offset (no matter
> how it is called) but it doesn't have to be aligned?  It seems like
> we've been having this disconnection from the beginning.  Can you
> please describe how this can avoid aliasing issues between clients
> sharing the same page?  So, in 2), whatever it is called, the server
> specifies a value, how is that value used?

That dev_offset value is used as an offset into the server side mmap
address space.  And yes, vma->vm_pgoff and dev_offset should be SHMLBA
multiples apart.

But don't call that _adjustment_.  That's totally confusing, these are
*two* *different* *offsets*.  There's an alignment requirement but
that's all.  If they are the same that is pure coincidence.

And dev_offset (which points into the dmmap address space) is only
required if the filesystem/CUSE driver needs server side mmap.

> > 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).
> 
> Device mmap use cases might not work very well if the server can't
> mmap directly.

I understand that, and that's where the interesting part comes in:
make the mmap API in a way that it works with and without server side
mmap.

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/