linux-kernel - Re: [PATCH 2/2] cuse: implement memory mapping

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] [day] [month] [year] [list]

Message-ID: <20120113184913.GB11112@google.com>
Date:	Fri, 13 Jan 2012 10:49:13 -0800
From:	Tejun Heo <htejun@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
	david.henningsson@...onical.com, smcnam@...il.com,
	gmane@...in.guthr.ie, jamescaldwell1@...il.com,
	s.maddox@...tizia.me.uk, mszeredi@...e.cz
Subject: Re: [PATCH 2/2] cuse: implement memory mapping

Hello, Linus.

On Fri, Jan 13, 2012 at 10:19:50AM -0800, Linus Torvalds wrote:
> On Fri, Jan 13, 2012 at 9:06 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
> > From: Tejun Heo <htejun@...il.com>
> >
> > This implements memory mapping of char devices.
> 
> I don't think this is how you want to do it.
> 
> It seems to maintain a page list of its own, and do the magic page
> fault etc behavior. Which to me smells like a really bad design.
> 
> I would expect that what you actually want to do is to expose it as a
> shared mmap, and depend on all the normal shmem support. Is there any
> reason not to do that?
> 
> I guess you don't generally have big mappings, so an argument like
> "that way you can page out pages etc" may not strike you as a very
> strong argument, but I'd still prefer to at least see that approach
> explored. Hmm?

The patch is years old and the original implementation had different
requirements (it mapped the same pages in the client's and server's
address spaces instead of using notifications).  I don't really
remember the details but I tried to use shmem pretty hard but
couldn't.  I *think* it was about having to accept random mapping
offset.  ISTR shmem implementation wasn't too happy with randomish
high mapping offset and I couldn't shift the mapping offset due to the
direct mapping requirement (again, memory is quite fuzzy).

With notification based implementation, it might be able to just shift
the mapping offset and use shmem.  Miklos, what do you think?

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/