All of lore.kernel.org
 help / color / mirror / Atom feed
From: Till Smejkal <till.smejkal@googlemail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Till Smejkal <till.smejkal@googlemail.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Steven Miao <realmz6@gmail.com>,
	Richard Kuo <rkuo@codeaurora.org>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	James Hogan <james.hogan@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalia
Subject: Re: [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions
Date: Mon, 13 Mar 2017 15:45:36 -0700	[thread overview]
Message-ID: <20170313224536.saqdijtdayxwmlpz@arch-dev> (raw)
In-Reply-To: <20170313222758.GB4033@bombadil.infradead.org>

Hi Matthew,

On Mon, 13 Mar 2017, Matthew Wilcox wrote:
> On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote:
> > +/**
> > + * Create a new VAS segment.
> > + *
> > + * @param[in] name:		The name of the new VAS segment.
> > + * @param[in] start:		The address where the VAS segment begins.
> > + * @param[in] end:		The address where the VAS segment ends.
> > + * @param[in] mode:		The access rights for the VAS segment.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO otherwise.
> > + **/
> 
> Please follow the kernel-doc conventions, as described in
> Documentation/doc-guide/kernel-doc.rst.  Also, function documentation
> goes with the implementation, not the declaration.

Thank you for this pointer. I wasn't aware of this convention. I will change the
patches accordingly.

> > +/**
> > + * Get ID of the VAS segment belonging to a given name.
> > + *
> > + * @param[in] name:		The name of the VAS segment for which the ID
> > + *				should be returned.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO
> > + *				otherwise.
> > + **/
> > +extern int vas_seg_find(const char *name);
> 
> So ... segments have names, and IDs ... and access permissions ...
> Why isn't this a special purpose filesystem?

We also thought about this. However, we decided against implementing them as a
special purpose filesystem, mainly because we could not think of a good way to
represent a VAS/VAS segment in this file system (should they be represented rather as
file or directory) and we weren't sure what a hierarchy in the filesystem would mean
for the underlying address spaces. Hence we decided against it and rather used a
combination of IDR and sysfs. However, I don't have any strong feelings and would
also reimplement them as a special purpose filesystem if people rather like them to
be one.

Till

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

WARNING: multiple messages have this Message-ID (diff)
From: Till Smejkal <till.smejkal@googlemail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Till Smejkal <till.smejkal@googlemail.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Steven Miao <realmz6@gmail.com>,
	Richard Kuo <rkuo@codeaurora.org>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	James Hogan <james.hogan@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Andy Lutomirski <luto@amacapital.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Pawel Osciak <pawel@osciak.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	Felipe Balbi <balbi@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Benjamin LaHaise <bcrl@kvack.org>,
	Nadia Yvette Chambers <nyc@holomorphy.com>,
	Jeff Layton <jlayton@poochiereds.net>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Hugh Dickins <hughd@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	adi-buildroot-devel@lists.sourceforge.net,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-media@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-usb@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-aio@kvack.org, linux-mm@kvack.org,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	alsa-devel@alsa-project.org
Subject: Re: [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions
Date: Mon, 13 Mar 2017 15:45:36 -0700	[thread overview]
Message-ID: <20170313224536.saqdijtdayxwmlpz@arch-dev> (raw)
In-Reply-To: <20170313222758.GB4033@bombadil.infradead.org>

Hi Matthew,

On Mon, 13 Mar 2017, Matthew Wilcox wrote:
> On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote:
> > +/**
> > + * Create a new VAS segment.
> > + *
> > + * @param[in] name:		The name of the new VAS segment.
> > + * @param[in] start:		The address where the VAS segment begins.
> > + * @param[in] end:		The address where the VAS segment ends.
> > + * @param[in] mode:		The access rights for the VAS segment.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO otherwise.
> > + **/
> 
> Please follow the kernel-doc conventions, as described in
> Documentation/doc-guide/kernel-doc.rst.  Also, function documentation
> goes with the implementation, not the declaration.

Thank you for this pointer. I wasn't aware of this convention. I will change the
patches accordingly.

> > +/**
> > + * Get ID of the VAS segment belonging to a given name.
> > + *
> > + * @param[in] name:		The name of the VAS segment for which the ID
> > + *				should be returned.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO
> > + *				otherwise.
> > + **/
> > +extern int vas_seg_find(const char *name);
> 
> So ... segments have names, and IDs ... and access permissions ...
> Why isn't this a special purpose filesystem?

We also thought about this. However, we decided against implementing them as a
special purpose filesystem, mainly because we could not think of a good way to
represent a VAS/VAS segment in this file system (should they be represented rather as
file or directory) and we weren't sure what a hierarchy in the filesystem would mean
for the underlying address spaces. Hence we decided against it and rather used a
combination of IDR and sysfs. However, I don't have any strong feelings and would
also reimplement them as a special purpose filesystem if people rather like them to
be one.

Till

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Till Smejkal <till.smejkal@googlemail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Till Smejkal <till.smejkal@googlemail.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Steven Miao <realmz6@gmail.com>,
	Richard Kuo <rkuo@codeaurora.org>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	James Hogan <james.hogan@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>, Rich Felker <dalia>
Subject: Re: [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions
Date: Mon, 13 Mar 2017 15:45:36 -0700	[thread overview]
Message-ID: <20170313224536.saqdijtdayxwmlpz@arch-dev> (raw)
In-Reply-To: <20170313222758.GB4033@bombadil.infradead.org>

Hi Matthew,

On Mon, 13 Mar 2017, Matthew Wilcox wrote:
> On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote:
> > +/**
> > + * Create a new VAS segment.
> > + *
> > + * @param[in] name:		The name of the new VAS segment.
> > + * @param[in] start:		The address where the VAS segment begins.
> > + * @param[in] end:		The address where the VAS segment ends.
> > + * @param[in] mode:		The access rights for the VAS segment.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO otherwise.
> > + **/
> 
> Please follow the kernel-doc conventions, as described in
> Documentation/doc-guide/kernel-doc.rst.  Also, function documentation
> goes with the implementation, not the declaration.

Thank you for this pointer. I wasn't aware of this convention. I will change the
patches accordingly.

> > +/**
> > + * Get ID of the VAS segment belonging to a given name.
> > + *
> > + * @param[in] name:		The name of the VAS segment for which the ID
> > + *				should be returned.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO
> > + *				otherwise.
> > + **/
> > +extern int vas_seg_find(const char *name);
> 
> So ... segments have names, and IDs ... and access permissions ...
> Why isn't this a special purpose filesystem?

We also thought about this. However, we decided against implementing them as a
special purpose filesystem, mainly because we could not think of a good way to
represent a VAS/VAS segment in this file system (should they be represented rather as
file or directory) and we weren't sure what a hierarchy in the filesystem would mean
for the underlying address spaces. Hence we decided against it and rather used a
combination of IDR and sysfs. However, I don't have any strong feelings and would
also reimplement them as a special purpose filesystem if people rather like them to
be one.

Till

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

WARNING: multiple messages have this Message-ID (diff)
From: Till Smejkal <till.smejkal@googlemail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Till Smejkal <till.smejkal@googlemail.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Steven Miao <realmz6@gmail.com>,
	Richard Kuo <rkuo@codeaurora.org>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	James Hogan <james.hogan@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Andy Lutomirski <luto@amacapital.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Pawel Osciak <pawel@osciak.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	Felipe Balbi <balbi@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Benjamin LaHaise <bcrl@kvack.org>,
	Nadia Yvette Chambers <nyc@holomorphy.com>,
	Jeff Layton <jlayton@poochiereds.net>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Hugh Dickins <hughd@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	adi-buildroot-devel@lists.sourceforge.net,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-media@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-usb@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-aio@kvack.org, linux-mm@kvack.org,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	alsa-devel@alsa-project.org
Subject: Re: [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions
Date: Mon, 13 Mar 2017 15:45:36 -0700	[thread overview]
Message-ID: <20170313224536.saqdijtdayxwmlpz@arch-dev> (raw)
In-Reply-To: <20170313222758.GB4033@bombadil.infradead.org>

Hi Matthew,

On Mon, 13 Mar 2017, Matthew Wilcox wrote:
> On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote:
> > +/**
> > + * Create a new VAS segment.
> > + *
> > + * @param[in] name:		The name of the new VAS segment.
> > + * @param[in] start:		The address where the VAS segment begins.
> > + * @param[in] end:		The address where the VAS segment ends.
> > + * @param[in] mode:		The access rights for the VAS segment.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO otherwise.
> > + **/
> 
> Please follow the kernel-doc conventions, as described in
> Documentation/doc-guide/kernel-doc.rst.  Also, function documentation
> goes with the implementation, not the declaration.

Thank you for this pointer. I wasn't aware of this convention. I will change the
patches accordingly.

> > +/**
> > + * Get ID of the VAS segment belonging to a given name.
> > + *
> > + * @param[in] name:		The name of the VAS segment for which the ID
> > + *				should be returned.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO
> > + *				otherwise.
> > + **/
> > +extern int vas_seg_find(const char *name);
> 
> So ... segments have names, and IDs ... and access permissions ...
> Why isn't this a special purpose filesystem?

We also thought about this. However, we decided against implementing them as a
special purpose filesystem, mainly because we could not think of a good way to
represent a VAS/VAS segment in this file system (should they be represented rather as
file or directory) and we weren't sure what a hierarchy in the filesystem would mean
for the underlying address spaces. Hence we decided against it and rather used a
combination of IDR and sysfs. However, I don't have any strong feelings and would
also reimplement them as a special purpose filesystem if people rather like them to
be one.

Till

WARNING: multiple messages have this Message-ID (diff)
From: till.smejkal@googlemail.com (Till Smejkal)
To: linux-snps-arc@lists.infradead.org
Subject: [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions
Date: Mon, 13 Mar 2017 15:45:36 -0700	[thread overview]
Message-ID: <20170313224536.saqdijtdayxwmlpz@arch-dev> (raw)
In-Reply-To: <20170313222758.GB4033@bombadil.infradead.org>

Hi Matthew,

On Mon, 13 Mar 2017, Matthew Wilcox wrote:
> On Mon, Mar 13, 2017@03:14:13PM -0700, Till Smejkal wrote:
> > +/**
> > + * Create a new VAS segment.
> > + *
> > + * @param[in] name:		The name of the new VAS segment.
> > + * @param[in] start:		The address where the VAS segment begins.
> > + * @param[in] end:		The address where the VAS segment ends.
> > + * @param[in] mode:		The access rights for the VAS segment.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO otherwise.
> > + **/
> 
> Please follow the kernel-doc conventions, as described in
> Documentation/doc-guide/kernel-doc.rst.  Also, function documentation
> goes with the implementation, not the declaration.

Thank you for this pointer. I wasn't aware of this convention. I will change the
patches accordingly.

> > +/**
> > + * Get ID of the VAS segment belonging to a given name.
> > + *
> > + * @param[in] name:		The name of the VAS segment for which the ID
> > + *				should be returned.
> > + *
> > + * @returns:			The VAS segment ID on success, -ERRNO
> > + *				otherwise.
> > + **/
> > +extern int vas_seg_find(const char *name);
> 
> So ... segments have names, and IDs ... and access permissions ...
> Why isn't this a special purpose filesystem?

We also thought about this. However, we decided against implementing them as a
special purpose filesystem, mainly because we could not think of a good way to
represent a VAS/VAS segment in this file system (should they be represented rather as
file or directory) and we weren't sure what a hierarchy in the filesystem would mean
for the underlying address spaces. Hence we decided against it and rather used a
combination of IDR and sysfs. However, I don't have any strong feelings and would
also reimplement them as a special purpose filesystem if people rather like them to
be one.

Till

  reply	other threads:[~2017-03-13 22:45 UTC|newest]

Thread overview: 260+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13 22:14 [RFC PATCH 00/13] Introduce first class virtual address spaces Till Smejkal
2017-03-13 22:14 ` Till Smejkal
2017-03-13 22:14 ` Till Smejkal
2017-03-13 22:14 ` Till Smejkal
2017-03-13 22:14 ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 01/13] mm: Add mm_struct argument to 'mmap_region' Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 02/13] mm: Add mm_struct argument to 'do_mmap' and 'do_mmap_pgoff' Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 03/13] mm: Rename 'unmap_region' and add mm_struct argument Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 04/13] mm: Add mm_struct argument to 'get_unmapped_area' and 'vm_unmapped_area' Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 05/13] mm: Add mm_struct argument to 'mm_populate' and '__mm_populate' Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 06/13] mm/mmap: Export 'vma_link' and 'find_vma_links' to mm subsystem Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 07/13] kernel/fork: Split and export 'mm_alloc' and 'mm_init' Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-14 10:18   ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 10:18     ` David Laight
2017-03-14 16:18     ` Till Smejkal
2017-03-14 16:18       ` Till Smejkal
2017-03-14 16:18       ` Till Smejkal
2017-03-14 16:18       ` Till Smejkal
2017-03-14 16:18       ` Till Smejkal
2017-03-14 16:18       ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 08/13] kernel/fork: Define explicitly which mm_struct to duplicate during fork Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 09/13] mm/memory: Add function to one-to-one duplicate page ranges Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 10/13] mm: Introduce first class virtual address spaces Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 23:52   ` Greg Kroah-Hartman
2017-03-13 23:52     ` Greg Kroah-Hartman
2017-03-13 23:52     ` Greg Kroah-Hartman
2017-03-13 23:52     ` Greg Kroah-Hartman
2017-03-13 23:52     ` Greg Kroah-Hartman
2017-03-14  0:24     ` Till Smejkal
2017-03-14  0:24       ` Till Smejkal
2017-03-14  0:24       ` Till Smejkal
2017-03-14  0:24       ` Till Smejkal
2017-03-14  0:24       ` Till Smejkal
2017-03-14  1:35   ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  1:35     ` Vineet Gupta
2017-03-14  2:34     ` Till Smejkal
2017-03-14  2:34       ` Till Smejkal
2017-03-14  2:34       ` Till Smejkal
2017-03-14  2:34       ` Till Smejkal
2017-03-14  2:34       ` Till Smejkal
2017-03-14  2:34       ` Till Smejkal
2017-03-14  2:34       ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 11/13] mm/vas: Introduce VAS segments - shareable address space regions Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:27   ` Matthew Wilcox
2017-03-13 22:27     ` Matthew Wilcox
2017-03-13 22:27     ` Matthew Wilcox
2017-03-13 22:27     ` Matthew Wilcox
2017-03-13 22:27     ` Matthew Wilcox
2017-03-13 22:27     ` Matthew Wilcox
2017-03-13 22:27     ` Matthew Wilcox
2017-03-13 22:45     ` Till Smejkal [this message]
2017-03-13 22:45       ` Till Smejkal
2017-03-13 22:45       ` Till Smejkal
2017-03-13 22:45       ` Till Smejkal
2017-03-13 22:45       ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 12/13] mm/vas: Add lazy-attach support for first class virtual address spaces Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14 ` [RFC PATCH 13/13] fs/proc: Add procfs " Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-13 22:14   ` Till Smejkal
2017-03-14  0:18 ` [RFC PATCH 00/13] Introduce " Richard Henderson
2017-03-14  0:18   ` Richard Henderson
2017-03-14  0:18   ` Richard Henderson
2017-03-14  0:18   ` Richard Henderson
2017-03-14  0:18   ` Richard Henderson
2017-03-14  0:39   ` Till Smejkal
2017-03-14  0:39     ` Till Smejkal
2017-03-14  0:39     ` Till Smejkal
2017-03-14  0:39     ` Till Smejkal
2017-03-14  0:39     ` Till Smejkal
2017-03-14  1:02     ` Richard Henderson
2017-03-14  1:02       ` Richard Henderson
2017-03-14  1:02       ` Richard Henderson
2017-03-14  1:31       ` Till Smejkal
2017-03-14  1:31         ` Till Smejkal
2017-03-14  1:31         ` Till Smejkal
2017-03-14  1:31         ` Till Smejkal
2017-03-14  1:31         ` Till Smejkal
2017-03-14  0:58 ` Andy Lutomirski
2017-03-14  0:58   ` Andy Lutomirski
2017-03-14  0:58   ` Andy Lutomirski
2017-03-14  0:58   ` Andy Lutomirski
2017-03-14  0:58   ` Andy Lutomirski
2017-03-14  0:58   ` Andy Lutomirski
2017-03-14  2:07   ` Till Smejkal
2017-03-14  2:07     ` Till Smejkal
2017-03-14  2:07     ` Till Smejkal
2017-03-14  2:07     ` Till Smejkal
2017-03-14  2:07     ` Till Smejkal
2017-03-14  2:07     ` Till Smejkal
2017-03-14  2:07     ` Till Smejkal
2017-03-14  2:07     ` Till Smejkal
2017-03-14  5:37     ` Andy Lutomirski
2017-03-14  5:37       ` Andy Lutomirski
2017-03-14  5:37       ` Andy Lutomirski
2017-03-14  5:37       ` Andy Lutomirski
2017-03-14  5:37       ` Andy Lutomirski
2017-03-14 16:12       ` Till Smejkal
2017-03-14 16:12         ` Till Smejkal
2017-03-14 16:12         ` Till Smejkal
2017-03-14 16:12         ` Till Smejkal
2017-03-14 16:12         ` Till Smejkal
2017-03-14 16:12         ` Till Smejkal
2017-03-14 16:12         ` Till Smejkal
2017-03-14 16:12         ` Till Smejkal
2017-03-14 19:53         ` Chris Metcalf
2017-03-14 19:53           ` Chris Metcalf
2017-03-14 19:53           ` Chris Metcalf
2017-03-14 19:53           ` Chris Metcalf
2017-03-14 19:53           ` Chris Metcalf
2017-03-14 19:53           ` Chris Metcalf
2017-03-14 21:14           ` Till Smejkal
2017-03-14 21:14             ` Till Smejkal
2017-03-14 21:14             ` Till Smejkal
2017-03-14 21:14             ` Till Smejkal
2017-03-14 21:14             ` Till Smejkal
2017-03-14 21:14             ` Till Smejkal
2017-03-15 16:51         ` Andy Lutomirski
2017-03-15 16:51           ` Andy Lutomirski
2017-03-15 16:51           ` Andy Lutomirski
2017-03-15 16:51           ` Andy Lutomirski
2017-03-15 16:51           ` Andy Lutomirski
2017-03-15 16:57           ` Matthew Wilcox
2017-03-15 16:57             ` Matthew Wilcox
2017-03-15 16:57             ` Matthew Wilcox
2017-03-15 16:57             ` Matthew Wilcox
2017-03-15 16:57             ` Matthew Wilcox
2017-03-15 16:57             ` Matthew Wilcox
2017-03-15 16:57             ` Matthew Wilcox
2017-03-15 16:57             ` Matthew Wilcox
2017-03-15 19:44           ` Till Smejkal
2017-03-15 19:44             ` Till Smejkal
2017-03-15 19:44             ` Till Smejkal
2017-03-15 19:44             ` Till Smejkal
2017-03-15 19:44             ` Till Smejkal
2017-03-15 19:44             ` Till Smejkal
2017-03-15 19:44             ` Till Smejkal
2017-03-15 19:44             ` Till Smejkal
2017-03-15 19:47             ` Rich Felker
2017-03-15 19:47             ` Rich Felker
2017-03-15 19:47               ` Rich Felker
2017-03-15 19:47               ` Rich Felker
2017-03-15 19:47               ` Rich Felker
2017-03-15 21:30               ` Till Smejkal
2017-03-15 21:30                 ` Till Smejkal
2017-03-15 21:30                 ` Till Smejkal
2017-03-15 21:30                 ` Till Smejkal
2017-03-15 21:30                 ` Till Smejkal
2017-03-15 21:30                 ` Till Smejkal
2017-03-15 20:06             ` Andy Lutomirski
2017-03-15 20:06             ` Andy Lutomirski
2017-03-15 20:06               ` Andy Lutomirski
2017-03-15 20:06               ` Andy Lutomirski
2017-03-15 20:06               ` Andy Lutomirski
2017-03-15 22:02               ` Till Smejkal
2017-03-15 22:02                 ` Till Smejkal
2017-03-15 22:02                 ` Till Smejkal
2017-03-15 22:02                 ` Till Smejkal
2017-03-15 22:02                 ` Till Smejkal
2017-03-15 22:02                 ` Till Smejkal
2017-03-15 22:09                 ` Luck, Tony
2017-03-15 22:09                   ` Luck, Tony
2017-03-15 22:09                   ` Luck, Tony
2017-03-15 22:09                   ` Luck, Tony
2017-03-15 23:18                   ` Till Smejkal
2017-03-15 23:18                     ` Till Smejkal
2017-03-15 23:18                     ` Till Smejkal
2017-03-15 23:18                     ` Till Smejkal
2017-03-15 23:18                     ` Till Smejkal
2017-03-15 23:18                     ` Till Smejkal
2017-03-16  8:21                 ` Thomas Gleixner
2017-03-16  8:21                   ` Thomas Gleixner
2017-03-16  8:21                   ` Thomas Gleixner
2017-03-16  8:21                   ` Thomas Gleixner
2017-03-16  8:21                   ` Thomas Gleixner
2017-03-16  8:21                   ` Thomas Gleixner
2017-03-16 17:29                   ` Till Smejkal
2017-03-16 17:29                     ` Till Smejkal
2017-03-16 17:29                     ` Till Smejkal
2017-03-16 17:29                     ` Till Smejkal
2017-03-16 17:29                     ` Till Smejkal
2017-03-16 17:29                     ` Till Smejkal
2017-03-16 17:42                     ` Thomas Gleixner
2017-03-16 17:42                       ` Thomas Gleixner
2017-03-16 17:42                       ` Thomas Gleixner
2017-03-16 17:42                       ` Thomas Gleixner
2017-03-16 17:42                       ` Thomas Gleixner
2017-03-16 17:42                       ` Thomas Gleixner
2017-03-16 17:50                       ` Till Smejkal
2017-03-16 17:50                         ` Till Smejkal
2017-03-16 17:50                         ` Till Smejkal
2017-03-16 17:50                         ` Till Smejkal
2017-03-16 17:50                         ` Till Smejkal
2017-03-16 17:50                         ` Till Smejkal
2017-03-15 16:51         ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170313224536.saqdijtdayxwmlpz@arch-dev \
    --to=till.smejkal@googlemail.com \
    --cc=benh@kernel.crashing.org \
    --cc=catalin.marinas@arm.com \
    --cc=deller@gmx.de \
    --cc=fenghua.yu@intel.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=james.hogan@imgtec.com \
    --cc=jejb@parisc-linux.org \
    --cc=linux@armlinux.org.uk \
    --cc=mattst88@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=ralf@linux-mips.org \
    --cc=realmz6@gmail.com \
    --cc=rkuo@codeaurora.org \
    --cc=rth@twiddle.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=tony.luck@intel.com \
    --cc=vgupta@synopsys.com \
    --cc=will.deacon@arm.com \
    --cc=willy@infradead.org \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.