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: <4B749BDF.8000807@kernel.org>
Date:	Fri, 12 Feb 2010 09:07:59 +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/11/2010 11:40 PM, Miklos Szeredi wrote:
>> Then, sharing those pages would cause aliasing issues.
> 
> You said a few mails up:
> 
>   "There are device mmap() implementations which simply ignore @offset
>    because offsetting doesn't make any sense at all"
> 
> Which means a) doesn't necessarily matter, so it's not something that
> determines aliasing issues.

Mmap regions of devices aren't always used as shared memories.  IO
regions often don't have cache backing at all.  Also, certain arch is
often assumed.

And yes it is something which determines aliasing issues.  There is no
way around it.

>>>> The offsets used in b) and c) are the same offsets.
>>>
>>> Why are they the same?
>>
>> I meant they point into the same space.  If they're the same value,
>> they point to the same page.
> 
> I'm beginning to undestand what you mean by "dmmap AS".

The thing described by rbtree of struct dmmap_regions.

> The thing is, I'm still not sure if or how this kind of mmap makes
> sense outside of the CUSE context.  Which makes designing the API
> difficult.

For this to be useful for normal FS, it has to be backed by multiple
swap backed files and I can almost guarantee you would need to be
passing fds around.

> So, for now maybe it's best to go with your implementation, fix issues
> with the offsets and make it CUSE only for the moment.

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.

> The alternative is for me to start implementing a coherent distributed
> filesystem, so I can see what the actual requirements for a direct
> mmap would be.  That would be fun, but it would
> 
>   a) delay direct mmap for CUSE by an unknown amount of time
>   b) delay everything else that I have in the pipeline ;)

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?

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/