All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Till Smejkal <till.smejkal@googlemail.com>
Cc: 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@daveml>
Subject: Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces
Date: Tue, 14 Mar 2017 07:52:25 +0800	[thread overview]
Message-ID: <20170313235225.GA15359@kroah.com> (raw)
In-Reply-To: <20170313221415.9375-11-till.smejkal@gmail.com>

On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote:

There's no way with that many cc: lists and people that this is really
making it through very many people's filters and actually on a mailing
list.  Please trim them down.

Minor sysfs questions/issues:

> +struct vas {
> +	struct kobject kobj;		/* < the internal kobject that we use *
> +					 *   for reference counting and sysfs *
> +					 *   handling.                        */
> +
> +	int id;				/* < ID                               */
> +	char name[VAS_MAX_NAME_LENGTH];	/* < name                             */

The kobject has a name, why not use that?

> +
> +	struct mutex mtx;		/* < lock for parallel access.        */
> +
> +	struct mm_struct *mm;		/* < a partial memory map containing  *
> +					 *   all mappings of this VAS.        */
> +
> +	struct list_head link;		/* < the link in the global VAS list. */
> +	struct rcu_head rcu;		/* < the RCU helper used for          *
> +					 *   asynchronous VAS deletion.       */
> +
> +	u16 refcount;			/* < how often is the VAS attached.   */

The kobject has a refcount, use that?  Don't have 2 refcounts in the
same structure, that way lies madness.  And bugs, lots of bugs...

And if this really is a refcount (hint, I don't think it is), you should
use the refcount_t type.

> +/**
> + * The sysfs structure we need to handle attributes of a VAS.
> + **/
> +struct vas_sysfs_attr {
> +	struct attribute attr;
> +	ssize_t (*show)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			char *buf);
> +	ssize_t (*store)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			 const char *buf, size_t count);
> +};
> +
> +#define VAS_SYSFS_ATTR(NAME, MODE, SHOW, STORE)				\
> +static struct vas_sysfs_attr vas_sysfs_attr_##NAME =			\
> +	__ATTR(NAME, MODE, SHOW, STORE)

__ATTR_RO and __ATTR_RW should work better for you.  If you really need
this.

Oh, and where is the Documentation/ABI/ updates to try to describe the
sysfs structure and files?  Did I miss that in the series?

> +static ssize_t __show_vas_name(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			       char *buf)
> +{
> +	return scnprintf(buf, PAGE_SIZE, "%s", vas->name);

It's a page size, just use sprintf() and be done with it.  No need to
ever check, you "know" it will be correct.

Also, what about a trailing '\n' for these attributes?

Oh wait, why have a name when the kobject name is already there in the
directory itself?  Do you really need this?

> +/**
> + * The ktype data structure representing a VAS.
> + **/
> +static struct kobj_type vas_ktype = {
> +	.sysfs_ops = &vas_sysfs_ops,
> +	.release = __vas_release,

Why the odd __vas* naming?  What's wrong with vas_release?


> +	.default_attrs = vas_default_attr,
> +};
> +
> +
> +/***
> + * Internally visible functions
> + ***/
> +
> +/**
> + * Working with the global VAS list.
> + **/
> +static inline void vas_remove(struct vas *vas)

<snip>

You have a ton of inline functions, for no good reason.  Make them all
"real" functions please.  Unless you can measure the size/speed
differences?  If so, please say so.


thanks,

greg k-h

--
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Till Smejkal <till.smejkal@googlemail.com>
Cc: 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>,
	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 10/13] mm: Introduce first class virtual address spaces
Date: Tue, 14 Mar 2017 07:52:25 +0800	[thread overview]
Message-ID: <20170313235225.GA15359@kroah.com> (raw)
In-Reply-To: <20170313221415.9375-11-till.smejkal@gmail.com>

On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote:

There's no way with that many cc: lists and people that this is really
making it through very many people's filters and actually on a mailing
list.  Please trim them down.

Minor sysfs questions/issues:

> +struct vas {
> +	struct kobject kobj;		/* < the internal kobject that we use *
> +					 *   for reference counting and sysfs *
> +					 *   handling.                        */
> +
> +	int id;				/* < ID                               */
> +	char name[VAS_MAX_NAME_LENGTH];	/* < name                             */

The kobject has a name, why not use that?

> +
> +	struct mutex mtx;		/* < lock for parallel access.        */
> +
> +	struct mm_struct *mm;		/* < a partial memory map containing  *
> +					 *   all mappings of this VAS.        */
> +
> +	struct list_head link;		/* < the link in the global VAS list. */
> +	struct rcu_head rcu;		/* < the RCU helper used for          *
> +					 *   asynchronous VAS deletion.       */
> +
> +	u16 refcount;			/* < how often is the VAS attached.   */

The kobject has a refcount, use that?  Don't have 2 refcounts in the
same structure, that way lies madness.  And bugs, lots of bugs...

And if this really is a refcount (hint, I don't think it is), you should
use the refcount_t type.

> +/**
> + * The sysfs structure we need to handle attributes of a VAS.
> + **/
> +struct vas_sysfs_attr {
> +	struct attribute attr;
> +	ssize_t (*show)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			char *buf);
> +	ssize_t (*store)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			 const char *buf, size_t count);
> +};
> +
> +#define VAS_SYSFS_ATTR(NAME, MODE, SHOW, STORE)				\
> +static struct vas_sysfs_attr vas_sysfs_attr_##NAME =			\
> +	__ATTR(NAME, MODE, SHOW, STORE)

__ATTR_RO and __ATTR_RW should work better for you.  If you really need
this.

Oh, and where is the Documentation/ABI/ updates to try to describe the
sysfs structure and files?  Did I miss that in the series?

> +static ssize_t __show_vas_name(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			       char *buf)
> +{
> +	return scnprintf(buf, PAGE_SIZE, "%s", vas->name);

It's a page size, just use sprintf() and be done with it.  No need to
ever check, you "know" it will be correct.

Also, what about a trailing '\n' for these attributes?

Oh wait, why have a name when the kobject name is already there in the
directory itself?  Do you really need this?

> +/**
> + * The ktype data structure representing a VAS.
> + **/
> +static struct kobj_type vas_ktype = {
> +	.sysfs_ops = &vas_sysfs_ops,
> +	.release = __vas_release,

Why the odd __vas* naming?  What's wrong with vas_release?


> +	.default_attrs = vas_default_attr,
> +};
> +
> +
> +/***
> + * Internally visible functions
> + ***/
> +
> +/**
> + * Working with the global VAS list.
> + **/
> +static inline void vas_remove(struct vas *vas)

<snip>

You have a ton of inline functions, for no good reason.  Make them all
"real" functions please.  Unless you can measure the size/speed
differences?  If so, please say so.


thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Till Smejkal <till.smejkal@googlemail.com>
Cc: 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@daveml
Subject: Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces
Date: Tue, 14 Mar 2017 07:52:25 +0800	[thread overview]
Message-ID: <20170313235225.GA15359@kroah.com> (raw)
In-Reply-To: <20170313221415.9375-11-till.smejkal@gmail.com>

On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote:

There's no way with that many cc: lists and people that this is really
making it through very many people's filters and actually on a mailing
list.  Please trim them down.

Minor sysfs questions/issues:

> +struct vas {
> +	struct kobject kobj;		/* < the internal kobject that we use *
> +					 *   for reference counting and sysfs *
> +					 *   handling.                        */
> +
> +	int id;				/* < ID                               */
> +	char name[VAS_MAX_NAME_LENGTH];	/* < name                             */

The kobject has a name, why not use that?

> +
> +	struct mutex mtx;		/* < lock for parallel access.        */
> +
> +	struct mm_struct *mm;		/* < a partial memory map containing  *
> +					 *   all mappings of this VAS.        */
> +
> +	struct list_head link;		/* < the link in the global VAS list. */
> +	struct rcu_head rcu;		/* < the RCU helper used for          *
> +					 *   asynchronous VAS deletion.       */
> +
> +	u16 refcount;			/* < how often is the VAS attached.   */

The kobject has a refcount, use that?  Don't have 2 refcounts in the
same structure, that way lies madness.  And bugs, lots of bugs...

And if this really is a refcount (hint, I don't think it is), you should
use the refcount_t type.

> +/**
> + * The sysfs structure we need to handle attributes of a VAS.
> + **/
> +struct vas_sysfs_attr {
> +	struct attribute attr;
> +	ssize_t (*show)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			char *buf);
> +	ssize_t (*store)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			 const char *buf, size_t count);
> +};
> +
> +#define VAS_SYSFS_ATTR(NAME, MODE, SHOW, STORE)				\
> +static struct vas_sysfs_attr vas_sysfs_attr_##NAME =			\
> +	__ATTR(NAME, MODE, SHOW, STORE)

__ATTR_RO and __ATTR_RW should work better for you.  If you really need
this.

Oh, and where is the Documentation/ABI/ updates to try to describe the
sysfs structure and files?  Did I miss that in the series?

> +static ssize_t __show_vas_name(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			       char *buf)
> +{
> +	return scnprintf(buf, PAGE_SIZE, "%s", vas->name);

It's a page size, just use sprintf() and be done with it.  No need to
ever check, you "know" it will be correct.

Also, what about a trailing '\n' for these attributes?

Oh wait, why have a name when the kobject name is already there in the
directory itself?  Do you really need this?

> +/**
> + * The ktype data structure representing a VAS.
> + **/
> +static struct kobj_type vas_ktype = {
> +	.sysfs_ops = &vas_sysfs_ops,
> +	.release = __vas_release,

Why the odd __vas* naming?  What's wrong with vas_release?


> +	.default_attrs = vas_default_attr,
> +};
> +
> +
> +/***
> + * Internally visible functions
> + ***/
> +
> +/**
> + * Working with the global VAS list.
> + **/
> +static inline void vas_remove(struct vas *vas)

<snip>

You have a ton of inline functions, for no good reason.  Make them all
"real" functions please.  Unless you can measure the size/speed
differences?  If so, please say so.


thanks,

greg k-h

--
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: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
To: linux-snps-arc@lists.infradead.org
Subject: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces
Date: Tue, 14 Mar 2017 07:52:25 +0800	[thread overview]
Message-ID: <20170313235225.GA15359@kroah.com> (raw)
In-Reply-To: <20170313221415.9375-11-till.smejkal@gmail.com>

On Mon, Mar 13, 2017@03:14:12PM -0700, Till Smejkal wrote:

There's no way with that many cc: lists and people that this is really
making it through very many people's filters and actually on a mailing
list.  Please trim them down.

Minor sysfs questions/issues:

> +struct vas {
> +	struct kobject kobj;		/* < the internal kobject that we use *
> +					 *   for reference counting and sysfs *
> +					 *   handling.                        */
> +
> +	int id;				/* < ID                               */
> +	char name[VAS_MAX_NAME_LENGTH];	/* < name                             */

The kobject has a name, why not use that?

> +
> +	struct mutex mtx;		/* < lock for parallel access.        */
> +
> +	struct mm_struct *mm;		/* < a partial memory map containing  *
> +					 *   all mappings of this VAS.        */
> +
> +	struct list_head link;		/* < the link in the global VAS list. */
> +	struct rcu_head rcu;		/* < the RCU helper used for          *
> +					 *   asynchronous VAS deletion.       */
> +
> +	u16 refcount;			/* < how often is the VAS attached.   */

The kobject has a refcount, use that?  Don't have 2 refcounts in the
same structure, that way lies madness.  And bugs, lots of bugs...

And if this really is a refcount (hint, I don't think it is), you should
use the refcount_t type.

> +/**
> + * The sysfs structure we need to handle attributes of a VAS.
> + **/
> +struct vas_sysfs_attr {
> +	struct attribute attr;
> +	ssize_t (*show)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			char *buf);
> +	ssize_t (*store)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			 const char *buf, size_t count);
> +};
> +
> +#define VAS_SYSFS_ATTR(NAME, MODE, SHOW, STORE)				\
> +static struct vas_sysfs_attr vas_sysfs_attr_##NAME =			\
> +	__ATTR(NAME, MODE, SHOW, STORE)

__ATTR_RO and __ATTR_RW should work better for you.  If you really need
this.

Oh, and where is the Documentation/ABI/ updates to try to describe the
sysfs structure and files?  Did I miss that in the series?

> +static ssize_t __show_vas_name(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			       char *buf)
> +{
> +	return scnprintf(buf, PAGE_SIZE, "%s", vas->name);

It's a page size, just use sprintf() and be done with it.  No need to
ever check, you "know" it will be correct.

Also, what about a trailing '\n' for these attributes?

Oh wait, why have a name when the kobject name is already there in the
directory itself?  Do you really need this?

> +/**
> + * The ktype data structure representing a VAS.
> + **/
> +static struct kobj_type vas_ktype = {
> +	.sysfs_ops = &vas_sysfs_ops,
> +	.release = __vas_release,

Why the odd __vas* naming?  What's wrong with vas_release?


> +	.default_attrs = vas_default_attr,
> +};
> +
> +
> +/***
> + * Internally visible functions
> + ***/
> +
> +/**
> + * Working with the global VAS list.
> + **/
> +static inline void vas_remove(struct vas *vas)

<snip>

You have a ton of inline functions, for no good reason.  Make them all
"real" functions please.  Unless you can measure the size/speed
differences?  If so, please say so.


thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Till Smejkal <till.smejkal@googlemail.com>
Cc: 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>,
	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 10/13] mm: Introduce first class virtual address spaces
Date: Tue, 14 Mar 2017 07:52:25 +0800	[thread overview]
Message-ID: <20170313235225.GA15359@kroah.com> (raw)
In-Reply-To: <20170313221415.9375-11-till.smejkal@gmail.com>

On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote:

There's no way with that many cc: lists and people that this is really
making it through very many people's filters and actually on a mailing
list.  Please trim them down.

Minor sysfs questions/issues:

> +struct vas {
> +	struct kobject kobj;		/* < the internal kobject that we use *
> +					 *   for reference counting and sysfs *
> +					 *   handling.                        */
> +
> +	int id;				/* < ID                               */
> +	char name[VAS_MAX_NAME_LENGTH];	/* < name                             */

The kobject has a name, why not use that?

> +
> +	struct mutex mtx;		/* < lock for parallel access.        */
> +
> +	struct mm_struct *mm;		/* < a partial memory map containing  *
> +					 *   all mappings of this VAS.        */
> +
> +	struct list_head link;		/* < the link in the global VAS list. */
> +	struct rcu_head rcu;		/* < the RCU helper used for          *
> +					 *   asynchronous VAS deletion.       */
> +
> +	u16 refcount;			/* < how often is the VAS attached.   */

The kobject has a refcount, use that?  Don't have 2 refcounts in the
same structure, that way lies madness.  And bugs, lots of bugs...

And if this really is a refcount (hint, I don't think it is), you should
use the refcount_t type.

> +/**
> + * The sysfs structure we need to handle attributes of a VAS.
> + **/
> +struct vas_sysfs_attr {
> +	struct attribute attr;
> +	ssize_t (*show)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			char *buf);
> +	ssize_t (*store)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			 const char *buf, size_t count);
> +};
> +
> +#define VAS_SYSFS_ATTR(NAME, MODE, SHOW, STORE)				\
> +static struct vas_sysfs_attr vas_sysfs_attr_##NAME =			\
> +	__ATTR(NAME, MODE, SHOW, STORE)

__ATTR_RO and __ATTR_RW should work better for you.  If you really need
this.

Oh, and where is the Documentation/ABI/ updates to try to describe the
sysfs structure and files?  Did I miss that in the series?

> +static ssize_t __show_vas_name(struct vas *vas, struct vas_sysfs_attr *vsattr,
> +			       char *buf)
> +{
> +	return scnprintf(buf, PAGE_SIZE, "%s", vas->name);

It's a page size, just use sprintf() and be done with it.  No need to
ever check, you "know" it will be correct.

Also, what about a trailing '\n' for these attributes?

Oh wait, why have a name when the kobject name is already there in the
directory itself?  Do you really need this?

> +/**
> + * The ktype data structure representing a VAS.
> + **/
> +static struct kobj_type vas_ktype = {
> +	.sysfs_ops = &vas_sysfs_ops,
> +	.release = __vas_release,

Why the odd __vas* naming?  What's wrong with vas_release?


> +	.default_attrs = vas_default_attr,
> +};
> +
> +
> +/***
> + * Internally visible functions
> + ***/
> +
> +/**
> + * Working with the global VAS list.
> + **/
> +static inline void vas_remove(struct vas *vas)

<snip>

You have a ton of inline functions, for no good reason.  Make them all
"real" functions please.  Unless you can measure the size/speed
differences?  If so, please say so.


thanks,

greg k-h

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

  reply	other threads:[~2017-03-13 23:52 UTC|newest]

Thread overview: 237+ 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 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 [this message]
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  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
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  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 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 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: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 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: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-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: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

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=20170313235225.GA15359@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=davem@daveml \
    --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=till.smejkal@googlemail.com \
    --cc=tony.luck@intel.com \
    --cc=vgupta@synopsys.com \
    --cc=will.deacon@arm.com \
    --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.