[PATCH 0/4] memcg: fix memcg resource limit overflow issues

[PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Qiang Huang]

This issue is first discussed in:
http://marc.info/?l=linux-mm&m=136574878704295&w=2

Then a second version sent to:
http://marc.info/?l=linux-mm&m=136776855928310&w=2

We contacted Sha a month ago, she seems have no time to deal with it 
recently, but we quite need this patch. So I modified and resent it.

Qiang Huang (4):
  memcg: correct RESOURCE_MAX to ULLONG_MAX
  memcg: rename RESOURCE_MAX to RES_COUNTER_MAX
  memcg: avoid overflow caused by PAGE_ALIGN
  memcg: reduce function dereference

 include/linux/res_counter.h |  2 +-
 kernel/res_counter.c        | 25 ++++++++++++++++---------
 mm/memcontrol.c             |  4 ++--
 net/ipv4/tcp_memcontrol.c   | 10 +++++-----
 4 files changed, 24 insertions(+), 17 deletions(-)

-- 
1.8.3

[PATCH 1/4] memcg: correct RESOURCE_MAX to ULLONG_MAX

[Qiang Huang]

Current RESOURCE_MAX is ULONG_MAX, but the value we used to set resource
limit is unsigned long long, so we can set bigger value than that which
is strange. The XXX_MAX should be reasonable max value, bigger than that
should be overflow.

Notice that this change will affect user output of default *.limit_in_bytes:
before change:
$ cat /cgroup/memory/memory.limit_in_bytes
9223372036854775807

after change:
$ cat /cgroup/memory/memory.limit_in_bytes
18446744073709551615

But it doesn't alter the API in term of input - we can still use
"echo -1 > *.limit_in_bytes" to reset the numbers to "unlimited".

Signed-off-by: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 include/linux/res_counter.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h
index 96a509b..586bc7c 100644
--- a/include/linux/res_counter.h
+++ b/include/linux/res_counter.h
@@ -54,7 +54,7 @@ struct res_counter {
 	struct res_counter *parent;
 };
 
-#define RESOURCE_MAX (unsigned long long)LLONG_MAX
+#define RESOURCE_MAX ULLONG_MAX
 
 /**
  * Helpers to interact with userspace
-- 
1.8.3

Re: [PATCH 1/4] memcg: correct RESOURCE_MAX to ULLONG_MAX

[Michal Hocko]

On Wed 31-07-13 15:31:22, Qiang Huang wrote:
> Current RESOURCE_MAX is ULONG_MAX, but the value we used to set resource
> limit is unsigned long long, so we can set bigger value than that which
> is strange. The XXX_MAX should be reasonable max value, bigger than that
> should be overflow.
> 
> Notice that this change will affect user output of default *.limit_in_bytes:
> before change:
> $ cat /cgroup/memory/memory.limit_in_bytes
> 9223372036854775807
> 
> after change:
> $ cat /cgroup/memory/memory.limit_in_bytes
> 18446744073709551615
> 
> But it doesn't alter the API in term of input - we can still use
> "echo -1 > *.limit_in_bytes" to reset the numbers to "unlimited".
> 
> Signed-off-by: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

I thought this would be better marked as cgroup wide change but memcg
seems to be the only user currently

Acked-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>

> ---
>  include/linux/res_counter.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h
> index 96a509b..586bc7c 100644
> --- a/include/linux/res_counter.h
> +++ b/include/linux/res_counter.h
> @@ -54,7 +54,7 @@ struct res_counter {
>  	struct res_counter *parent;
>  };
>  
> -#define RESOURCE_MAX (unsigned long long)LLONG_MAX
> +#define RESOURCE_MAX ULLONG_MAX
>  
>  /**
>   * Helpers to interact with userspace
> -- 
> 1.8.3
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Michal Hocko
SUSE Labs

[PATCH 2/4] memcg: rename RESOURCE_MAX to RES_COUNTER_MAX

[Qiang Huang]

RESOURCE_MAX is far too general name, change it to RES_COUNTER_MAX.

Signed-off-by: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 include/linux/res_counter.h |  2 +-
 kernel/res_counter.c        |  8 ++++----
 mm/memcontrol.c             |  4 ++--
 net/ipv4/tcp_memcontrol.c   | 10 +++++-----
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h
index 586bc7c..201a697 100644
--- a/include/linux/res_counter.h
+++ b/include/linux/res_counter.h
@@ -54,7 +54,7 @@ struct res_counter {
 	struct res_counter *parent;
 };
 
-#define RESOURCE_MAX ULLONG_MAX
+#define RES_COUNTER_MAX ULLONG_MAX
 
 /**
  * Helpers to interact with userspace
diff --git a/kernel/res_counter.c b/kernel/res_counter.c
index ff55247..3f0417f 100644
--- a/kernel/res_counter.c
+++ b/kernel/res_counter.c
@@ -17,8 +17,8 @@
 void res_counter_init(struct res_counter *counter, struct res_counter *parent)
 {
 	spin_lock_init(&counter->lock);
-	counter->limit = RESOURCE_MAX;
-	counter->soft_limit = RESOURCE_MAX;
+	counter->limit = RES_COUNTER_MAX;
+	counter->soft_limit = RES_COUNTER_MAX;
 	counter->parent = parent;
 }
 
@@ -182,12 +182,12 @@ int res_counter_memparse_write_strategy(const char *buf,
 {
 	char *end;
 
-	/* return RESOURCE_MAX(unlimited) if "-1" is specified */
+	/* return RES_COUNTER_MAX(unlimited) if "-1" is specified */
 	if (*buf == '-') {
 		*res = simple_strtoull(buf + 1, &end, 10);
 		if (*res != 1 || *end != '\0')
 			return -EINVAL;
-		*res = RESOURCE_MAX;
+		*res = RES_COUNTER_MAX;
 		return 0;
 	}
 
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 1947218..f621cf5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5117,7 +5117,7 @@ static int memcg_update_kmem_limit(struct cgroup *cont, u64 val)
 	 */
 	mutex_lock(&memcg_create_mutex);
 	mutex_lock(&set_limit_mutex);
-	if (!memcg->kmem_account_flags && val != RESOURCE_MAX) {
+	if (!memcg->kmem_account_flags && val != RES_COUNTER_MAX) {
 		if (cgroup_task_count(cont) || memcg_has_children(memcg)) {
 			ret = -EBUSY;
 			goto out;
@@ -5127,7 +5127,7 @@ static int memcg_update_kmem_limit(struct cgroup *cont, u64 val)
 
 		ret = memcg_update_cache_sizes(memcg);
 		if (ret) {
-			res_counter_set_limit(&memcg->kmem, RESOURCE_MAX);
+			res_counter_set_limit(&memcg->kmem, RES_COUNTER_MAX);
 			goto out;
 		}
 		static_key_slow_inc(&memcg_kmem_enabled_key);
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index da14436..90550f4 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -87,8 +87,8 @@ static int tcp_update_limit(struct mem_cgroup *memcg, u64 val)
 	if (!cg_proto)
 		return -EINVAL;
 
-	if (val > RESOURCE_MAX)
-		val = RESOURCE_MAX;
+	if (val > RES_COUNTER_MAX)
+		val = RES_COUNTER_MAX;
 
 	tcp = tcp_from_cgproto(cg_proto);
 
@@ -101,9 +101,9 @@ static int tcp_update_limit(struct mem_cgroup *memcg, u64 val)
 		tcp->tcp_prot_mem[i] = min_t(long, val >> PAGE_SHIFT,
 					     net->ipv4.sysctl_tcp_mem[i]);
 
-	if (val == RESOURCE_MAX)
+	if (val == RES_COUNTER_MAX)
 		clear_bit(MEMCG_SOCK_ACTIVE, &cg_proto->flags);
-	else if (val != RESOURCE_MAX) {
+	else if (val != RES_COUNTER_MAX) {
 		/*
 		 * The active bit needs to be written after the static_key
 		 * update. This is what guarantees that the socket activation
@@ -187,7 +187,7 @@ static u64 tcp_cgroup_read(struct cgroup *cont, struct cftype *cft)
 
 	switch (cft->private) {
 	case RES_LIMIT:
-		val = tcp_read_stat(memcg, RES_LIMIT, RESOURCE_MAX);
+		val = tcp_read_stat(memcg, RES_LIMIT, RES_COUNTER_MAX);
 		break;
 	case RES_USAGE:
 		val = tcp_read_usage(memcg);
-- 
1.8.3

Re: [PATCH 2/4] memcg: rename RESOURCE_MAX to RES_COUNTER_MAX

[Michal Hocko]

On Wed 31-07-13 15:31:23, Qiang Huang wrote:
> RESOURCE_MAX is far too general name, change it to RES_COUNTER_MAX.
> 
> Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
> Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>

Acked-by: Michal Hocko <mhocko@suse.cz>

> ---
>  include/linux/res_counter.h |  2 +-
>  kernel/res_counter.c        |  8 ++++----
>  mm/memcontrol.c             |  4 ++--
>  net/ipv4/tcp_memcontrol.c   | 10 +++++-----
>  4 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h
> index 586bc7c..201a697 100644
> --- a/include/linux/res_counter.h
> +++ b/include/linux/res_counter.h
> @@ -54,7 +54,7 @@ struct res_counter {
>  	struct res_counter *parent;
>  };
>  
> -#define RESOURCE_MAX ULLONG_MAX
> +#define RES_COUNTER_MAX ULLONG_MAX
>  
>  /**
>   * Helpers to interact with userspace
> diff --git a/kernel/res_counter.c b/kernel/res_counter.c
> index ff55247..3f0417f 100644
> --- a/kernel/res_counter.c
> +++ b/kernel/res_counter.c
> @@ -17,8 +17,8 @@
>  void res_counter_init(struct res_counter *counter, struct res_counter *parent)
>  {
>  	spin_lock_init(&counter->lock);
> -	counter->limit = RESOURCE_MAX;
> -	counter->soft_limit = RESOURCE_MAX;
> +	counter->limit = RES_COUNTER_MAX;
> +	counter->soft_limit = RES_COUNTER_MAX;
>  	counter->parent = parent;
>  }
>  
> @@ -182,12 +182,12 @@ int res_counter_memparse_write_strategy(const char *buf,
>  {
>  	char *end;
>  
> -	/* return RESOURCE_MAX(unlimited) if "-1" is specified */
> +	/* return RES_COUNTER_MAX(unlimited) if "-1" is specified */
>  	if (*buf == '-') {
>  		*res = simple_strtoull(buf + 1, &end, 10);
>  		if (*res != 1 || *end != '\0')
>  			return -EINVAL;
> -		*res = RESOURCE_MAX;
> +		*res = RES_COUNTER_MAX;
>  		return 0;
>  	}
>  
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 1947218..f621cf5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5117,7 +5117,7 @@ static int memcg_update_kmem_limit(struct cgroup *cont, u64 val)
>  	 */
>  	mutex_lock(&memcg_create_mutex);
>  	mutex_lock(&set_limit_mutex);
> -	if (!memcg->kmem_account_flags && val != RESOURCE_MAX) {
> +	if (!memcg->kmem_account_flags && val != RES_COUNTER_MAX) {
>  		if (cgroup_task_count(cont) || memcg_has_children(memcg)) {
>  			ret = -EBUSY;
>  			goto out;
> @@ -5127,7 +5127,7 @@ static int memcg_update_kmem_limit(struct cgroup *cont, u64 val)
>  
>  		ret = memcg_update_cache_sizes(memcg);
>  		if (ret) {
> -			res_counter_set_limit(&memcg->kmem, RESOURCE_MAX);
> +			res_counter_set_limit(&memcg->kmem, RES_COUNTER_MAX);
>  			goto out;
>  		}
>  		static_key_slow_inc(&memcg_kmem_enabled_key);
> diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
> index da14436..90550f4 100644
> --- a/net/ipv4/tcp_memcontrol.c
> +++ b/net/ipv4/tcp_memcontrol.c
> @@ -87,8 +87,8 @@ static int tcp_update_limit(struct mem_cgroup *memcg, u64 val)
>  	if (!cg_proto)
>  		return -EINVAL;
>  
> -	if (val > RESOURCE_MAX)
> -		val = RESOURCE_MAX;
> +	if (val > RES_COUNTER_MAX)
> +		val = RES_COUNTER_MAX;
>  
>  	tcp = tcp_from_cgproto(cg_proto);
>  
> @@ -101,9 +101,9 @@ static int tcp_update_limit(struct mem_cgroup *memcg, u64 val)
>  		tcp->tcp_prot_mem[i] = min_t(long, val >> PAGE_SHIFT,
>  					     net->ipv4.sysctl_tcp_mem[i]);
>  
> -	if (val == RESOURCE_MAX)
> +	if (val == RES_COUNTER_MAX)
>  		clear_bit(MEMCG_SOCK_ACTIVE, &cg_proto->flags);
> -	else if (val != RESOURCE_MAX) {
> +	else if (val != RES_COUNTER_MAX) {
>  		/*
>  		 * The active bit needs to be written after the static_key
>  		 * update. This is what guarantees that the socket activation
> @@ -187,7 +187,7 @@ static u64 tcp_cgroup_read(struct cgroup *cont, struct cftype *cft)
>  
>  	switch (cft->private) {
>  	case RES_LIMIT:
> -		val = tcp_read_stat(memcg, RES_LIMIT, RESOURCE_MAX);
> +		val = tcp_read_stat(memcg, RES_LIMIT, RES_COUNTER_MAX);
>  		break;
>  	case RES_USAGE:
>  		val = tcp_read_usage(memcg);
> -- 
> 1.8.3
> 
> 

-- 
Michal Hocko
SUSE Labs

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

[PATCH 3/4] memcg: avoid overflow caused by PAGE_ALIGN

[Qiang Huang]

Since PAGE_ALIGN is aligning up(the next page boundary), so after PAGE_ALIGN,
the value might be overflow, such as write the MAX value to *.limit_in_bytes.

$ cat /cgroup/memory/memory.limit_in_bytes
18446744073709551615

# echo 18446744073709551615 > /cgroup/memory/memory.limit_in_bytes
bash: echo: write error: Invalid argument

Some user programs might depend on such behaviours(like libcg, we read the
value in snapshot, then use the value to reset cgroup later), and that
will cause confusion. So we need to fix it.

Signed-off-by: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 kernel/res_counter.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/res_counter.c b/kernel/res_counter.c
index 3f0417f..085d3ae 100644
--- a/kernel/res_counter.c
+++ b/kernel/res_counter.c
@@ -195,6 +195,10 @@ int res_counter_memparse_write_strategy(const char *buf,
 	if (*end != '\0')
 		return -EINVAL;
 
-	*res = PAGE_ALIGN(*res);
+	if (PAGE_ALIGN(*res) >= *res)
+		*res = PAGE_ALIGN(*res);
+	else
+		*res = RES_COUNTER_MAX;
+
 	return 0;
 }
-- 
1.8.3

Re: [PATCH 3/4] memcg: avoid overflow caused by PAGE_ALIGN

[Michal Hocko]

On Wed 31-07-13 15:31:24, Qiang Huang wrote:
> Since PAGE_ALIGN is aligning up(the next page boundary), so after PAGE_ALIGN,
> the value might be overflow, such as write the MAX value to *.limit_in_bytes.
> 
> $ cat /cgroup/memory/memory.limit_in_bytes
> 18446744073709551615
> 
> # echo 18446744073709551615 > /cgroup/memory/memory.limit_in_bytes
> bash: echo: write error: Invalid argument
> 
> Some user programs might depend on such behaviours(like libcg, we read the
> value in snapshot, then use the value to reset cgroup later), and that
> will cause confusion. So we need to fix it.
> 
> Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
> Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>

Reviewed-by: Michal Hocko <mhocko@suse.cz>

> ---
>  kernel/res_counter.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/res_counter.c b/kernel/res_counter.c
> index 3f0417f..085d3ae 100644
> --- a/kernel/res_counter.c
> +++ b/kernel/res_counter.c
> @@ -195,6 +195,10 @@ int res_counter_memparse_write_strategy(const char *buf,
>  	if (*end != '\0')
>  		return -EINVAL;
>  
> -	*res = PAGE_ALIGN(*res);
> +	if (PAGE_ALIGN(*res) >= *res)
> +		*res = PAGE_ALIGN(*res);
> +	else
> +		*res = RES_COUNTER_MAX;
> +
>  	return 0;
>  }
> -- 
> 1.8.3
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Michal Hocko
SUSE Labs

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

[PATCH 4/4] memcg: reduce function dereference

[Qiang Huang]

This function dereferences res far too often, so optimize it.

Signed-off-by: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 kernel/res_counter.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/kernel/res_counter.c b/kernel/res_counter.c
index 085d3ae..4aa8a30 100644
--- a/kernel/res_counter.c
+++ b/kernel/res_counter.c
@@ -178,27 +178,30 @@ u64 res_counter_read_u64(struct res_counter *counter, int member)
 #endif
 
 int res_counter_memparse_write_strategy(const char *buf,
-					unsigned long long *res)
+					unsigned long long *resp)
 {
 	char *end;
+	unsigned long long res;
 
 	/* return RES_COUNTER_MAX(unlimited) if "-1" is specified */
 	if (*buf == '-') {
-		*res = simple_strtoull(buf + 1, &end, 10);
-		if (*res != 1 || *end != '\0')
+		res = simple_strtoull(buf + 1, &end, 10);
+		if (res != 1 || *end != '\0')
 			return -EINVAL;
-		*res = RES_COUNTER_MAX;
+		*resp = RES_COUNTER_MAX;
 		return 0;
 	}
 
-	*res = memparse(buf, &end);
+	res = memparse(buf, &end);
 	if (*end != '\0')
 		return -EINVAL;
 
-	if (PAGE_ALIGN(*res) >= *res)
-		*res = PAGE_ALIGN(*res);
+	if (PAGE_ALIGN(res) >= res)
+		res = PAGE_ALIGN(res);
 	else
-		*res = RES_COUNTER_MAX;
+		res = RES_COUNTER_MAX;
+
+	*resp = res;
 
 	return 0;
 }
-- 
1.8.3

Re: [PATCH 4/4] memcg: reduce function dereference

[Michal Hocko]

On Wed 31-07-13 15:31:25, Qiang Huang wrote:
> This function dereferences res far too often, so optimize it.
> 
> Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
> Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>

Reviewed-by: Michal Hocko <mhocko@suse.cz>

> ---
>  kernel/res_counter.c | 19 +++++++++++--------
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/res_counter.c b/kernel/res_counter.c
> index 085d3ae..4aa8a30 100644
> --- a/kernel/res_counter.c
> +++ b/kernel/res_counter.c
> @@ -178,27 +178,30 @@ u64 res_counter_read_u64(struct res_counter *counter, int member)
>  #endif
>  
>  int res_counter_memparse_write_strategy(const char *buf,
> -					unsigned long long *res)
> +					unsigned long long *resp)
>  {
>  	char *end;
> +	unsigned long long res;
>  
>  	/* return RES_COUNTER_MAX(unlimited) if "-1" is specified */
>  	if (*buf == '-') {
> -		*res = simple_strtoull(buf + 1, &end, 10);
> -		if (*res != 1 || *end != '\0')
> +		res = simple_strtoull(buf + 1, &end, 10);
> +		if (res != 1 || *end != '\0')
>  			return -EINVAL;
> -		*res = RES_COUNTER_MAX;
> +		*resp = RES_COUNTER_MAX;
>  		return 0;
>  	}
>  
> -	*res = memparse(buf, &end);
> +	res = memparse(buf, &end);
>  	if (*end != '\0')
>  		return -EINVAL;
>  
> -	if (PAGE_ALIGN(*res) >= *res)
> -		*res = PAGE_ALIGN(*res);
> +	if (PAGE_ALIGN(res) >= res)
> +		res = PAGE_ALIGN(res);
>  	else
> -		*res = RES_COUNTER_MAX;
> +		res = RES_COUNTER_MAX;
> +
> +	*resp = res;
>  
>  	return 0;
>  }
> -- 
> 1.8.3
> 
> 

-- 
Michal Hocko
SUSE Labs

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

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Sha Zhengju]

Hi list,

On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
> This issue is first discussed in:
> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>
> Then a second version sent to:
> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>
> We contacted Sha a month ago, she seems have no time to deal with it
> recently, but we quite need this patch. So I modified and resent it.


No, I didn't receive any of YOUR message, only a engineer named Libo
Chen from Huawei connected me recently. I don't approve you to resent
them on behalf of me, and just before you send this you even don't
send me a mail. Besides, after a rough look, I do not see any
innovative ideas from yourself but just rework patches from my last
version.
So I'm strong against this patchset.

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Qiang Huang]

On 2013/7/31 16:23, Sha Zhengju wrote:
> Hi list,
> 
> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>> This issue is first discussed in:
>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>
>> Then a second version sent to:
>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>
>> We contacted Sha a month ago, she seems have no time to deal with it
>> recently, but we quite need this patch. So I modified and resent it.
> 
> 
> No, I didn't receive any of YOUR message, only a engineer named Libo
> Chen from Huawei connected me recently. I don't approve you to resent
> them on behalf of me, and just before you send this you even don't
> send me a mail. Besides, after a rough look, I do not see any
> innovative ideas from yourself but just rework patches from my last
> version.
> So I'm strong against this patchset.

Sorry if this troubles you.
Libo Chen is my colleague, we work together, he sent an email to you on
25 June, to ask about this issue, you said you'll resent it soon, but it
didn't happen until now :(, and he asked again the other day and you didn't
reply. As we really need to fix this problem(and need it in upstream), so
I modified it and sent out.

I think split patches, rewrite changelogs and tests, they all kind of work
right? Of course, if you mind, I can change it, I just need this fix merged
to upstream ASAP.

So you want me rewrite this patchset and SOB only you or you want resent this
by yourself? I'm ok with both :)

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Li Zefan]

On 2013/7/31 16:51, Qiang Huang wrote:
> On 2013/7/31 16:23, Sha Zhengju wrote:
>> Hi list,
>>
>> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>>> This issue is first discussed in:
>>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>>
>>> Then a second version sent to:
>>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>>
>>> We contacted Sha a month ago, she seems have no time to deal with it
>>> recently, but we quite need this patch. So I modified and resent it.
>>
>>
>> No, I didn't receive any of YOUR message, only a engineer named Libo
>> Chen from Huawei connected me recently. I don't approve you to resent
>> them on behalf of me, and just before you send this you even don't
>> send me a mail. Besides, after a rough look, I do not see any
>> innovative ideas from yourself but just rework patches from my last
>> version.
>> So I'm strong against this patchset.
> 
> Sorry if this troubles you.
> Libo Chen is my colleague, we work together, he sent an email to you on
> 25 June, to ask about this issue, you said you'll resent it soon, but it
> didn't happen until now :(, and he asked again the other day and you didn't
> reply. As we really need to fix this problem(and need it in upstream), so
> I modified it and sent out.
> 
> I think split patches, rewrite changelogs and tests, they all kind of work
> right? Of course, if you mind, I can change it, I just need this fix merged
> to upstream ASAP.
> 
> So you want me rewrite this patchset and SOB only you or you want resent this
> by yourself? I'm ok with both :)
> 

No, you can't send out patches without your SOB...but you can add a line
in the beginning of the email:

From: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Qiang Huang]

On 2013/7/31 16:54, Li Zefan wrote:
> On 2013/7/31 16:51, Qiang Huang wrote:
>> On 2013/7/31 16:23, Sha Zhengju wrote:
>>> Hi list,
>>>
>>> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>>>> This issue is first discussed in:
>>>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>>>
>>>> Then a second version sent to:
>>>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>>>
>>>> We contacted Sha a month ago, she seems have no time to deal with it
>>>> recently, but we quite need this patch. So I modified and resent it.
>>>
>>>
>>> No, I didn't receive any of YOUR message, only a engineer named Libo
>>> Chen from Huawei connected me recently. I don't approve you to resent
>>> them on behalf of me, and just before you send this you even don't
>>> send me a mail. Besides, after a rough look, I do not see any
>>> innovative ideas from yourself but just rework patches from my last
>>> version.
>>> So I'm strong against this patchset.
>>
>> Sorry if this troubles you.
>> Libo Chen is my colleague, we work together, he sent an email to you on
>> 25 June, to ask about this issue, you said you'll resent it soon, but it
>> didn't happen until now :(, and he asked again the other day and you didn't
>> reply. As we really need to fix this problem(and need it in upstream), so
>> I modified it and sent out.
>>
>> I think split patches, rewrite changelogs and tests, they all kind of work
>> right? Of course, if you mind, I can change it, I just need this fix merged
>> to upstream ASAP.
>>
>> So you want me rewrite this patchset and SOB only you or you want resent this
>> by yourself? I'm ok with both :)
>>
> 
> No, you can't send out patches without your SOB...but you can add a line
> in the beginning of the email:
> 
> From: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>
> 

Got it, so Sha, is that OK for you?

> 
> .
> 

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Jeff Liu]

On 07/31/2013 04:54 PM, Li Zefan wrote:

> On 2013/7/31 16:51, Qiang Huang wrote:
>> On 2013/7/31 16:23, Sha Zhengju wrote:
>>> Hi list,
>>>
>>> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang@huawei.com> wrote:
>>>> This issue is first discussed in:
>>>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>>>
>>>> Then a second version sent to:
>>>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>>>
>>>> We contacted Sha a month ago, she seems have no time to deal with it
>>>> recently, but we quite need this patch. So I modified and resent it.
>>>
>>>
>>> No, I didn't receive any of YOUR message, only a engineer named Libo
>>> Chen from Huawei connected me recently. I don't approve you to resent
>>> them on behalf of me, and just before you send this you even don't
>>> send me a mail. Besides, after a rough look, I do not see any
>>> innovative ideas from yourself but just rework patches from my last
>>> version.
>>> So I'm strong against this patchset.
>>
>> Sorry if this troubles you.
>> Libo Chen is my colleague, we work together, he sent an email to you on
>> 25 June, to ask about this issue, you said you'll resent it soon, but it
>> didn't happen until now :(, and he asked again the other day and you didn't
>> reply. As we really need to fix this problem(and need it in upstream), so
>> I modified it and sent out.
>>
>> I think split patches, rewrite changelogs and tests, they all kind of work
>> right? Of course, if you mind, I can change it, I just need this fix merged
>> to upstream ASAP.
>>
>> So you want me rewrite this patchset and SOB only you or you want resent this
>> by yourself? I'm ok with both :)
>>
> 
> No, you can't send out patches without your SOB...but you can add a line
> in the beginning of the email:
> 
> From: Sha Zhengju <handai.szj@taobao.com>

This is the usual way to credit the original author.  But in this case, Qiang
should get a confirmation from Sha at first.

IMO, that would make a mess of a project if anybody can take over an on-going
task without an approval from the author just because he is looking forward to
see something will happen on mainline shortly.

Thanks,
-Jeff

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

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Li Zefan]

On 2013/7/31 17:34, Jeff Liu wrote:
> On 07/31/2013 04:54 PM, Li Zefan wrote:
> 
>> On 2013/7/31 16:51, Qiang Huang wrote:
>>> On 2013/7/31 16:23, Sha Zhengju wrote:
>>>> Hi list,
>>>>
>>>> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang@huawei.com> wrote:
>>>>> This issue is first discussed in:
>>>>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>>>>
>>>>> Then a second version sent to:
>>>>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>>>>
>>>>> We contacted Sha a month ago, she seems have no time to deal with it
>>>>> recently, but we quite need this patch. So I modified and resent it.
>>>>
>>>>
>>>> No, I didn't receive any of YOUR message, only a engineer named Libo
>>>> Chen from Huawei connected me recently. I don't approve you to resent
>>>> them on behalf of me, and just before you send this you even don't
>>>> send me a mail. Besides, after a rough look, I do not see any
>>>> innovative ideas from yourself but just rework patches from my last
>>>> version.
>>>> So I'm strong against this patchset.
>>>
>>> Sorry if this troubles you.
>>> Libo Chen is my colleague, we work together, he sent an email to you on
>>> 25 June, to ask about this issue, you said you'll resent it soon, but it
>>> didn't happen until now :(, and he asked again the other day and you didn't
>>> reply. As we really need to fix this problem(and need it in upstream), so
>>> I modified it and sent out.
>>>
>>> I think split patches, rewrite changelogs and tests, they all kind of work
>>> right? Of course, if you mind, I can change it, I just need this fix merged
>>> to upstream ASAP.
>>>
>>> So you want me rewrite this patchset and SOB only you or you want resent this
>>> by yourself? I'm ok with both :)
>>>
>>
>> No, you can't send out patches without your SOB...but you can add a line
>> in the beginning of the email:
>>
>> From: Sha Zhengju <handai.szj@taobao.com>
> 
> This is the usual way to credit the original author.  But in this case, Qiang
> should get a confirmation from Sha at first.
> 
> IMO, that would make a mess of a project if anybody can take over an on-going
> task without an approval from the author just because he is looking forward to
> see something will happen on mainline shortly.
> 

This happens from time to time, but mostly it's because of mistakes or lack of
communication or unfamiliarity about the rules rather than deliberatly stealing
someone else's credits.

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

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Sha Zhengju]

On Wed, Jul 31, 2013 at 4:54 PM, Li Zefan <lizefan@huawei.com> wrote:
> On 2013/7/31 16:51, Qiang Huang wrote:
>> On 2013/7/31 16:23, Sha Zhengju wrote:
>>> Hi list,
>>>
>>> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang@huawei.com> wrote:
>>>> This issue is first discussed in:
>>>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>>>
>>>> Then a second version sent to:
>>>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>>>
>>>> We contacted Sha a month ago, she seems have no time to deal with it
>>>> recently, but we quite need this patch. So I modified and resent it.
>>>
>>>
>>> No, I didn't receive any of YOUR message, only a engineer named Libo
>>> Chen from Huawei connected me recently. I don't approve you to resent
>>> them on behalf of me, and just before you send this you even don't
>>> send me a mail. Besides, after a rough look, I do not see any
>>> innovative ideas from yourself but just rework patches from my last
>>> version.
>>> So I'm strong against this patchset.
>>
>> Sorry if this troubles you.
>> Libo Chen is my colleague, we work together, he sent an email to you on
>> 25 June, to ask about this issue, you said you'll resent it soon, but it
>> didn't happen until now :(, and he asked again the other day and you didn't
>> reply. As we really need to fix this problem(and need it in upstream), so
>> I modified it and sent out.
>>
>> I think split patches, rewrite changelogs and tests, they all kind of work
>> right? Of course, if you mind, I can change it, I just need this fix merged
>> to upstream ASAP.
>>
>> So you want me rewrite this patchset and SOB only you or you want resent this
>> by yourself? I'm ok with both :)
>>
>
> No, you can't send out patches without your SOB...but you can add a line
> in the beginning of the email:
>
> From: Sha Zhengju <handai.szj@taobao.com>
>

Cooperation is welcomed and I just hated this kind of behavior. I
don't want to block the community, since they're urgent to the patches
and Michal has already reviewed them just now,  I won't be so caustic
on it. I'm OK of letting the codes in under the rules of community.

-- 
Thanks,
Sha

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

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Michal Hocko]

On Wed 31-07-13 17:39:43, Sha Zhengju wrote:
> I don't want to block the community, since they're urgent to the
> patches and Michal has already reviewed them just now, I won't be
> so caustic on it. I'm OK of letting the codes in under the rules of
> community.

Your s-o-b has been preserved which was sufficient for me, but
preserving the original From would be polity and sorry I have missed
that, I would have screamed as well. It should be added in the next
repost.

Qiang Huang s-o-b is appropriate as well as he has rebased and reposted
the series, though.

Anyway, I do not see any reason to postpone this series as it is a good
improvement.

-- 
Michal Hocko
SUSE Labs

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

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Sha Zhengju]

On Wed, Jul 31, 2013 at 5:50 PM, Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> wrote:
> On Wed 31-07-13 17:39:43, Sha Zhengju wrote:
>> I don't want to block the community, since they're urgent to the
>> patches and Michal has already reviewed them just now, I won't be
>> so caustic on it. I'm OK of letting the codes in under the rules of
>> community.
>
> Your s-o-b has been preserved which was sufficient for me, but
> preserving the original From would be polity and sorry I have missed
> that, I would have screamed as well. It should be added in the next
> repost.

Thanks for the support.

> Qiang Huang s-o-b is appropriate as well as he has rebased and reposted
> the series, though.
>
> Anyway, I do not see any reason to postpone this series as it is a good
> improvement.
>

Yeah, I thought the problem it tries to solve is rarely encountered
when I sent it last time. But now I also glad to see it merged soon.



Thanks,
Sha

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Qiang Huang]

On 2013/7/31 17:39, Sha Zhengju wrote:
> On Wed, Jul 31, 2013 at 4:54 PM, Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>> On 2013/7/31 16:51, Qiang Huang wrote:
>>> On 2013/7/31 16:23, Sha Zhengju wrote:
>>>> Hi list,
>>>>
>>>> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>>>>> This issue is first discussed in:
>>>>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>>>>
>>>>> Then a second version sent to:
>>>>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>>>>
>>>>> We contacted Sha a month ago, she seems have no time to deal with it
>>>>> recently, but we quite need this patch. So I modified and resent it.
>>>>
>>>>
>>>> No, I didn't receive any of YOUR message, only a engineer named Libo
>>>> Chen from Huawei connected me recently. I don't approve you to resent
>>>> them on behalf of me, and just before you send this you even don't
>>>> send me a mail. Besides, after a rough look, I do not see any
>>>> innovative ideas from yourself but just rework patches from my last
>>>> version.
>>>> So I'm strong against this patchset.
>>>
>>> Sorry if this troubles you.
>>> Libo Chen is my colleague, we work together, he sent an email to you on
>>> 25 June, to ask about this issue, you said you'll resent it soon, but it
>>> didn't happen until now :(, and he asked again the other day and you didn't
>>> reply. As we really need to fix this problem(and need it in upstream), so
>>> I modified it and sent out.
>>>
>>> I think split patches, rewrite changelogs and tests, they all kind of work
>>> right? Of course, if you mind, I can change it, I just need this fix merged
>>> to upstream ASAP.
>>>
>>> So you want me rewrite this patchset and SOB only you or you want resent this
>>> by yourself? I'm ok with both :)
>>>
>>
>> No, you can't send out patches without your SOB...but you can add a line
>> in the beginning of the email:
>>
>> From: Sha Zhengju <handai.szj-3b8fjiQLQpfQT0dZR+AlfA@public.gmane.org>
>>
> 
> Cooperation is welcomed and I just hated this kind of behavior. I
> don't want to block the community, since they're urgent to the patches
> and Michal has already reviewed them just now,  I won't be so caustic
> on it. I'm OK of letting the codes in under the rules of community.
> 

OK, thank you Sha, I just confirmed again, Libo did get your reply, we
made a mistake, sorry for that.

It is my fault didn't get your permission before the rework, I didn't notice
this is that big deal, I'll be more careful next time :). Thanks again.

Re: [PATCH 0/4] memcg: fix memcg resource limit overflow issues

[Sha Zhengju]

On Wed, Jul 31, 2013 at 4:51 PM, Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
> On 2013/7/31 16:23, Sha Zhengju wrote:
>> Hi list,
>>
>> On Wed, Jul 31, 2013 at 3:31 PM, Qiang Huang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>>> This issue is first discussed in:
>>> http://marc.info/?l=linux-mm&m=136574878704295&w=2
>>>
>>> Then a second version sent to:
>>> http://marc.info/?l=linux-mm&m=136776855928310&w=2
>>>
>>> We contacted Sha a month ago, she seems have no time to deal with it
>>> recently, but we quite need this patch. So I modified and resent it.
>>
>>
>> No, I didn't receive any of YOUR message, only a engineer named Libo
>> Chen from Huawei connected me recently. I don't approve you to resent
>> them on behalf of me, and just before you send this you even don't
>> send me a mail. Besides, after a rough look, I do not see any
>> innovative ideas from yourself but just rework patches from my last
>> version.
>> So I'm strong against this patchset.
>
> Sorry if this troubles you.
> Libo Chen is my colleague, we work together, he sent an email to you on
> 25 June, to ask about this issue, you said you'll resent it soon, but it
> didn't happen until now :(, and he asked again the other day and you didn't
> reply.

No, I replied him. I told him I'm working on another patchset, and I
planned to sent this after that one, and then there's no responds from
him. I've no idea it's so urgent to you.


> I modified it and sent out.
>
> I think split patches, rewrite changelogs and tests, they all kind of work
> right?

Yes, it is. But you're doing on other people's work!


> to upstream ASAP.
>
> So you want me rewrite this patchset and SOB only you or you want resent this
> by yourself? I'm ok with both :)
>
>
>