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:	Wed, 10 Feb 2010 20:56:55 +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/10/2010 08:29 PM, Miklos Szeredi wrote:
>> This is achieved by enforcing address to offset alignment.  IOW, all
>> maps are forced to be SHMLBA aligned to offset so that all maps are
>> SHMLBA aligned to each other.
> 
> Okay, lets be a little clearer.  There are client side maps and server
> side maps.  Client side maps are naturally aligned (same offset ->
> same page).

Same offset -> same page doesn't hold.  Clients mappings sharing the
same offset can end up with different physical pages.  ie. Process A
opening /dev/dsp and mmapping at 0 and process B doing the same thing
clearly need to be served with different pages and that's one of the
reasons why the server is given the ability to adjust the offset.

> So that leaves server side maps needing to be aligned to client side
> maps.  Since we use the offset into the mmap as the ID, we might as
> well just cheat and calculate a maching offset for the server side map
> and use that.  I'm not worried about changing vma->vm_pgoff there, if
> that's the only way to get proper alignment, since those are not
> "proper" mmaps anyway.
...
> Currently you are aligning client/client maps by changing the
> requested offset.  That's like saying: you wanted the file mapped from
> offset X, but we mapped it from offset Y because that's better
> aligned.  It doesn't make much sense, if the filesystem is doing
> something nasty like that, then to hell with cache alignment.

I think we're misunderstanding each other pretty good here.  I really
can't understand the above paragraph.  The offset adjustment is to
allow the server to choose which clients share which mappings.  It's
not to align anything.  The alignment is done by the generic VM layer
against the offset.  The SHMLBA requirement for the FUSE server is
there so that the FUSE server doesn't break the alignment while
changing the offset.

Can you please elaborate how you think the thing can work without
referencing the proposed implementation?  Let's find out where the
misundertanding is.

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/