On Wed, Jan 26, 2022 at 04:42:47PM +0300, Kirill A. Shutemov wrote: > On Wed, Jan 26, 2022 at 04:04:48AM +0000, Matthew Wilcox wrote: > > On Tue, Jan 25, 2022 at 06:59:50PM +0000, Matthew Wilcox wrote: > > > On Tue, Jan 25, 2022 at 09:57:05PM +0300, Kirill A. Shutemov wrote: > > > So how about something like this ... > > > > int mcreate(const char *name, int flags, mode_t mode); > > > > creates a new mm_struct with a refcount of 2. returns an fd (one > > of the two refcounts) and creates a name for it (inside msharefs, > > holds the other refcount). > > > > You can then mmap() that fd to attach it to a chunk of your address > > space. Once attached, you can start to populate it by calling > > mmap() and specifying an address inside the attached mm as the first > > argument to mmap(). > > That is not what mmap() would normally do to an existing mapping. So it > requires special treatment. > > In general mmap() of a mm_struct scares me. I can't wrap my head around > implications. > > Like how does it work on fork()? > > How accounting works? What happens on OOM? > > What prevents creating loops, like mapping a mm_struct inside itself? > > What mremap()/munmap() do to such mapping? Will it affect mapping of > mm_struct or will it target mapping inside the mm_sturct? > > Maybe it just didn't clicked for me, I donno. My understanding was that the new mm_struct would be rather stripped and will be used more as an abstraction for the shared page table, maybe I'm totally wrong :) > > Maybe mcreate() is just a library call, and it's really a thin wrapper > > around open() that happens to know where msharefs is mounted. > > -- > Kirill A. Shutemov -- Sincerely yours, Mike.
