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]

Message-ID: <4B7558C1.2060405@kernel.org>
Date:	Fri, 12 Feb 2010 22:33:53 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Miklos Szeredi <miklos@...redi.hu>
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

Hello,

On 02/12/2010 06:55 PM, Miklos Szeredi wrote:
> 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

vma->vm_pgoff is peripheral unless you mean not adjusting offset at
all.

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

Okay.

>  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?

>> 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.

Alright, we'll be missing the upcoming merge window anyway, so no
biggie.

> I don't think I want a swap backed solution.  There is already a
> backing for these maps and that is the userspace filesystem.

Yeap, sure.  This was what I was talking about in the other reply.
Named files would probably be much easier to work with for the server
implementations.

> 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.

> 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.

Alright, I'll ping you in a while.

Thanks.

-- 
tejun
--
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/