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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1NfaD3-0003MQ-Du@pomaz-ex.szeredi.hu>
Date:	Thu, 11 Feb 2010 15:40:01 +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 Thu, 11 Feb 2010, Tejun Heo wrote:
> >> There are three offsets.
> >>
> >> a) the offset a client requested
> >>
> >> b) the offset into dmmap AS, a client mmap region is mapped to.  This
> >>    could be different from a) by multiple of SHMLBA / PAGE_SIZE.
> > 
> > No, it could be different from a) by an arbitrary value.
> 
> 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.

> >> c) the offset into dmmap AS, a server mmap region is mapped to, where
> >>    collection of these mmaps define the dmmap AS.
> >>
> >> 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 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.

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 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 ;)

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/