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: <E1NfAl6-0000o4-8Z@pomaz-ex.szeredi.hu>
Date:	Wed, 10 Feb 2010 12:29:28 +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 Wed, 10 Feb 2010, Tejun Heo wrote:
> > 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.
> 
> The coherency requirement is not really between the address and offset
> but virtual addresses different maps which may end up sharing the same
> physical page.  On an architecture with virtually indexed but
> physically tagged caches, virtual addresses which map to the same page
> must end up hitting the same cache group; otherwise, the processor
> wouldn't be able to determine whether the two addresses point to the
> same page (as only the tags inside the same cache group are matched
> against the physical address).
> 
> 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).

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.

> FUSE dmmap has exactly the same problem as it basically is a shared
> memory implementation with slightly different interface.  Unless we
> can know which maps are gonna be shared beforehand, and we can't know
> this either for between the client and server or between clients, the
> only way to make those shared mappings fall into the same cache slot
> is aligning them to address space offsets.

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.

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/