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:	Thu, 11 Feb 2010 22:30:05 +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 10:01 PM, Miklos Szeredi wrote:
>> That's the requirement coming from allowing the server to determine
>> how these mmaps are served, not from the fact that the management is
>> done via server side mmaps or the server maps those regions into its
>> process address space.  No matter how you do it, if you want to mix
>> and match client mmap requests, the SHMLBA alignment will be visible.
> 
> Can you give an example?

Hmmm... I don't have any specific example.  osspd is the only real
thing which uses it and it serves each mmap request with a separate
region.  Oh... the fmmap example program serves the same region to
mmap requests coming from the same UID, so it does both sharing and
putting maps apart.

>> I suppose you're talking about not allowing offsets to be adjusted at
>> all but I don't think that's a restriction we would want to have at
>> the kernel API level because offset might encode different things for
>> device mmaps.
> 
> Possibly.  But there's some confusion about offsets again.  This
> offset is not the same as the one currently returned in fuse_mmap_out.

This offset is the offset client requests.

> And neither is the SHMLBA alignment requirement so clear:
> 
> You say, that ossp ignores the client mmap offset.  So basically it
> resets the offset to zero, whatever it was, no?  That sounds fine, but
> then you are adjusting the offset by something not necessarily a
> multiple of SHMLBA.

Yeap and that would be a bug.  It will probably have to do % SHMLBA on
the offset.  I don't think all OSS drivers would be caring about these
stuff anyway.  Most of them work on only x86 where SHMLBA == PAGE_SIZE.

> So there are different offsets:
> 
>  a) vma->vm_pgoff (which may mean anything, but usually means b)

Yeap, vma->vm_pgoff can be any value and doesn't really matter.  The
only visible difference would be the /proc listing, right?  Setting
this to the requested offset is trivial.

>  b) the offset at which the pages of the mapping are located
>  c) the offset at which the server side mmap is located

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.

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.

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/