t fail */
Without this patch, the last operation will fail.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 51f8e1d..535dce6 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -856,14 +
We can just use oldcs->mems_allowed.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index d753837..dbef832 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1407,8 +1407,7 @@ sta
ors, it takes other configs from the
empty cpuset.
- If the ancestors' masks are changed, those tasks will also be updated
to take new masks.
Li Zefan (10):
cpuset: remove redundant check in cpuset_cpus_allowed_fallback()
cpuset: cleanup guarantee_online_{cpus|mems}()
cpuset: rem
task_cs() will never return NULL.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 64b3f79..f0c884a 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2253,8 +2253,7 @@ void
- We never pass a NULL @cs to these functions.
- The top cpuset always has some online cpus/mems.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 29 +++--
1 file changed, 7 insertions(+), 22 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index f0c884a
- We never pass a NULL @cs to these functions.
- The top cpuset always has some online cpus/mems.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 29 +++--
1 file changed, 7 insertions(+), 22 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
We can just use oldcs-mems_allowed.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index d753837..dbef832 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1407,8
The test is done in set_cpus_allowed_ptr(), so it's redundant.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index dbef832..51f8e1d 100644
--- a/kernel
, it takes other configs from the
empty cpuset.
- If the ancestors' masks are changed, those tasks will also be updated
to take new masks.
Li Zefan (10):
cpuset: remove redundant check in cpuset_cpus_allowed_fallback()
cpuset: cleanup guarantee_online_{cpus|mems}()
cpuset: remove
*/
Without this patch, the last operation will fail.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 51f8e1d..535dce6 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
task_cs() will never return NULL.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 64b3f79..f0c884a 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2253,8 +2253,7
calling update_task_nodemask() and
update_task_cpumask(), instead of using workqueue.
- add documentation in include/linux/cgroup.h
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cgroup.h | 4 ++
kernel/cpuset.c| 137 +
2 files
, to = ancestor's nodemask.
so looks like no pages will be migrated.
Fix this by:
- Don't call update_tasks_nodemask() on empty cpusets.
- Pass cs-old_mems_allowed to do_migrate_pages().
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 15 +++
1 file changed, 11 insertions
mems_allowed in cpuset-old_mems_allowed.
This currently won't change any behavior, but it will later allow
us to keep tasks in empty cpusets.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 62 +
1 file changed, 36
/cgroup.h
Signed-off-by: Li Zefan lize...@huawei.com
---
include/linux/cgroup.h | 3 +++
kernel/cpuset.c| 12 +---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 53e81a6..74e8b8e 100644
--- a/include/linux/cgroup.h
cpusets.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 76 -
1 file changed, 65 insertions(+), 11 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index b848505..5252f94 100644
--- a/kernel/cpuset.c
+++ b/kernel
Commit-ID: c0ffaf3655fab1909a920c8f30ba1722932d01bb
Gitweb: http://git.kernel.org/tip/c0ffaf3655fab1909a920c8f30ba1722932d01bb
Author: Li Zefan
AuthorDate: Fri, 17 May 2013 10:31:35 +0800
Committer: Ingo Molnar
CommitDate: Tue, 28 May 2013 11:28:20 +0200
watchdog: Remove
Commit-ID: 08825c90af6e4bb902b3a51abb0ae6530199f682
Gitweb: http://git.kernel.org/tip/08825c90af6e4bb902b3a51abb0ae6530199f682
Author: Li Zefan
AuthorDate: Fri, 17 May 2013 10:31:20 +0800
Committer: Ingo Molnar
CommitDate: Tue, 28 May 2013 11:28:19 +0200
watchdog: Document
Commit-ID: a6572f84c5b135d9b6df279ed3c8de028bd1edd9
Gitweb: http://git.kernel.org/tip/a6572f84c5b135d9b6df279ed3c8de028bd1edd9
Author: Li Zefan
AuthorDate: Fri, 17 May 2013 10:31:04 +0800
Committer: Ingo Molnar
CommitDate: Tue, 28 May 2013 11:28:18 +0200
watchdog: Disallow setting
Commit-ID: a6572f84c5b135d9b6df279ed3c8de028bd1edd9
Gitweb: http://git.kernel.org/tip/a6572f84c5b135d9b6df279ed3c8de028bd1edd9
Author: Li Zefan lize...@huawei.com
AuthorDate: Fri, 17 May 2013 10:31:04 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 28 May 2013 11:28:18
Commit-ID: 08825c90af6e4bb902b3a51abb0ae6530199f682
Gitweb: http://git.kernel.org/tip/08825c90af6e4bb902b3a51abb0ae6530199f682
Author: Li Zefan lize...@huawei.com
AuthorDate: Fri, 17 May 2013 10:31:20 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 28 May 2013 11:28:19
Commit-ID: c0ffaf3655fab1909a920c8f30ba1722932d01bb
Gitweb: http://git.kernel.org/tip/c0ffaf3655fab1909a920c8f30ba1722932d01bb
Author: Li Zefan lize...@huawei.com
AuthorDate: Fri, 17 May 2013 10:31:35 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 28 May 2013 11:28:20
On 2013/5/24 11:35, Gu Zheng wrote:
> Hi Libo,
>I think you can merge patch 1/3 and 2/3, they do the same thing that using
> devm_* API to simplify
> and make the code clean, and the additional goal is it also can fix a bug.
nope. they should be separated.
> Besides, maybe you need to
>
On 2013/5/24 11:35, Gu Zheng wrote:
Hi Libo,
I think you can merge patch 1/3 and 2/3, they do the same thing that using
devm_* API to simplify
and make the code clean, and the additional goal is it also can fix a bug.
nope. they should be separated.
Besides, maybe you need to
change
On 2013/5/22 16:31, CAI Qian wrote:
> Reproduced on a few systems.
> CAI Qian
>
> created 375 sockets
> Generating file descriptors
> Added 45 filenames from /dev
> Added 19858 filenames from /proc
> Added 11816 filenames from /sys
> [1143] Random reseed: 1433907474
> trinity(1143):
On 2013/5/18 2:08, Tejun Heo wrote:
> Hey,
>
> On Fri, May 17, 2013 at 03:04:06PM +0800, Li Zefan wrote:
>> +/*
>> + * Releases a reference taken in kmem_cgroup_css_offline in case
>> + * this last uncharge is racing with the offlining code or it is
>
On 2013/5/22 15:40, Andrew Vagin wrote:
> On Tue, May 14, 2013 at 06:08:59PM +0200, Michal Hocko wrote:
>>
>> Forgot to add
>> Reviewed-by: Michal Hocko
>> +
>> Cc: stable # 3.9
>>
>> Thanks
>
> Who usually picks up such patches?
The famous AKPM.
--
To unsubscribe from this list: send the line
On 2013/5/22 15:40, Andrew Vagin wrote:
On Tue, May 14, 2013 at 06:08:59PM +0200, Michal Hocko wrote:
Forgot to add
Reviewed-by: Michal Hocko mho...@suse.cz
+
Cc: stable # 3.9
Thanks
Who usually picks up such patches?
The famous AKPM.
--
To unsubscribe from this list: send the line
On 2013/5/18 2:08, Tejun Heo wrote:
Hey,
On Fri, May 17, 2013 at 03:04:06PM +0800, Li Zefan wrote:
+/*
+ * Releases a reference taken in kmem_cgroup_css_offline in case
+ * this last uncharge is racing with the offlining code or it is
+ * outliving the memcg existence
On 2013/5/22 16:31, CAI Qian wrote:
Reproduced on a few systems.
CAI Qian
created 375 sockets
Generating file descriptors
Added 45 filenames from /dev
Added 19858 filenames from /proc
Added 11816 filenames from /sys
[1143] Random reseed: 1433907474
trinity(1143): Randomness
On 2013/5/22 12:49, Libo Chen wrote:
>
> ping...
>
> On 2013/5/5 16:38, chenlib...@gmail.com wrote:
>> From: Libo Chen
>>
>> There is no need to free bcom_eng if kzalloc fail
>>
kfree(NULL) is fine. We gain nothing from this patch, and it even adds one
more line to the code, so just drop thi
On 2013/5/22 12:49, Libo Chen wrote:
ping...
On 2013/5/5 16:38, chenlib...@gmail.com wrote:
From: Libo Chen libo.c...@huawei.com
There is no need to free bcom_eng if kzalloc fail
kfree(NULL) is fine. We gain nothing from this patch, and it even adds one
more line to the code, so just
[ 130.287724] ==
[ 130.287732] [ INFO: possible circular locking dependency detected ]
[ 130.287742] 3.10.0-rc1-0.7-default+ #9 Not tainted
[ 130.287749] ---
[ 130.287758]
I've been seeing this since 3.8-rcX. It's very annoying...
[ 634.543378] ==
[ 634.543378] [ INFO: possible circular locking dependency detected ]
[ 634.543380] 3.10.0-rc1-0.7-default+ #8 Not tainted
[ 634.543381]
The subject should be "[PATCH 0/9][v3] ..."
On 2013/5/17 15:02, Li Zefan wrote:
> Hi Andrew,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
("memcg: free mem_cgroup by RCU to fix oops").
Cc: Hugh Dickins
Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Acked-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 51 +--
1 file changed, 5 insertions(+), 46 deletions(-)
diff --git a/mm/memc
Now memcg has the same life cycle as its corresponding cgroup.
Kill the useless refcnt.
Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Acked-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/mm/memcontrol.c b/mm
changed so that rmdir a cgroup will succeed regardless
css refs, but won't be freed until css refs goes down to 0.
Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Acked-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 26 --
1 file changed, 16 insertions(+), 10 deletions
The cgroup core guarantees it's always safe to access the parent.
v2:
- added a comment in mem_cgroup_put() as suggested by Michal
- removed mem_cgroup_get(), otherwise gcc will warn that it's not used
Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Acked-by: KAMEZAWA Hiroyuki
---
mm
if kmem is activated in kmem_cgroup_css_offline()
Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Acked-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 66 +++--
1 file changed, 41 insertions(+), 25 deletions(-)
diff --git a/mm/memcontrol.c b/mm
Use css_get/css_put instead of mem_cgroup_get/put.
Note, if at the same time someone is moving @current to a different
cgroup and removing the old cgroup, css_tryget() may return false,
and sock->sk_cgrp won't be initialized, which is fine.
Signed-off-by: Li Zefan
Acked-by: KAMEZAWA Hiroy
suggests that it should be memcg_propagate_kmem that
should clean up after itself so this patch moves mem_cgroup_put over
there.
Unfortunately this is not that easy (as pointed out by Li Zefan) because
memcg_kmem_mark_dead marks the group dead (KMEM_ACCOUNTED_DEAD) if it
is marked active
Signed-off-by: Li Zefan
Acked-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cb1c9de..5918e90 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6297,8 +6297,6 @@ mem_cgroup_css_online(struct cgroup *cont
css_put.
(This changelog is mostly written by Glauber)
Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Acked-by: KAMEZAWA Hiroyuki
---
mm/memcontrol.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f1320d3..63526f9 100644
, after those changes, we can convert memcg to use cgroup->id, and then
we can kill css_id.
The first 2 patches are bug fixes that can go into 3.10, and the rest are
for 3.10.
Li Zefan (7):
memcg: use css_get() in sock_update_memcg()
memcg: don't use mem_cgroup_get() when creat
, after those changes, we can convert memcg to use cgroup-id, and then
we can kill css_id.
The first 2 patches are bug fixes that can go into 3.10, and the rest are
for 3.10.
Li Zefan (7):
memcg: use css_get() in sock_update_memcg()
memcg: don't use mem_cgroup_get() when creating
-off-by: Michal Hocko mho...@suse.cz
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cb1c9de..5918e90 100644
--- a/mm/memcontrol.c
css_put.
(This changelog is mostly written by Glauber)
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm
Use css_get/css_put instead of mem_cgroup_get/put.
Note, if at the same time someone is moving @current to a different
cgroup and removing the old cgroup, css_tryget() may return false,
and sock-sk_cgrp won't be initialized, which is fine.
Signed-off-by: Li Zefan lize...@huawei.com
Acked
suggests that it should be memcg_propagate_kmem that
should clean up after itself so this patch moves mem_cgroup_put over
there.
Unfortunately this is not that easy (as pointed out by Li Zefan) because
memcg_kmem_mark_dead marks the group dead (KMEM_ACCOUNTED_DEAD) if it
is marked active
if kmem is activated in kmem_cgroup_css_offline()
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 66 +++--
1 file changed, 41
The cgroup core guarantees it's always safe to access the parent.
v2:
- added a comment in mem_cgroup_put() as suggested by Michal
- removed mem_cgroup_get(), otherwise gcc will warn that it's not used
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked
changed so that rmdir a cgroup will succeed regardless
css refs, but won't be freed until css refs goes down to 0.
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 26
Now memcg has the same life cycle as its corresponding cgroup.
Kill the useless refcnt.
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 18 +-
1 file changed, 1
(memcg: free mem_cgroup by RCU to fix oops).
Cc: Hugh Dickins hu...@google.com
Signed-off-by: Li Zefan lize...@huawei.com
Acked-by: Michal Hocko mho...@suse.cz
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 51 +--
1 file
The subject should be [PATCH 0/9][v3] ...
On 2013/5/17 15:02, Li Zefan wrote:
Hi Andrew,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
I've been seeing this since 3.8-rcX. It's very annoying...
[ 634.543378] ==
[ 634.543378] [ INFO: possible circular locking dependency detected ]
[ 634.543380] 3.10.0-rc1-0.7-default+ #8 Not tainted
[ 634.543381]
[ 130.287724] ==
[ 130.287732] [ INFO: possible circular locking dependency detected ]
[ 130.287742] 3.10.0-rc1-0.7-default+ #9 Not tainted
[ 130.287749] ---
[ 130.287758]
hugetlb cgroup has already been implemented.
Signed-off-by: Li Zefan
---
Documentation/cgroups/memory.txt | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index ddf4f93..327acec 100644
The old softlockup detector has been replaced with new lockup
detector long ago.
Signed-off-by: Li Zefan
---
Documentation/sysctl/kernel.txt | 10 --
1 file changed, 10 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index e8fabd6..bcff3f9
In old kernels, it's allowed to set softlockup_thresh to -1 or 0
to disable softlockup detection. However watchdog_thresh only
uses 0 to disable detection, and setting it to -1 just froze my
box and nothing I can do but reboot.
Signed-off-by: Li Zefan
---
kernel/sysctl.c | 3 +--
1 file changed
Signed-off-by: Li Zefan
---
Documentation/sysctl/kernel.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index ccd4258..e8fabd6 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl
Signed-off-by: Li Zefan lize...@huawei.com
---
Documentation/sysctl/kernel.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index ccd4258..e8fabd6 100644
--- a/Documentation/sysctl/kernel.txt
+++ b
The old softlockup detector has been replaced with new lockup
detector long ago.
Signed-off-by: Li Zefan lize...@huawei.com
---
Documentation/sysctl/kernel.txt | 10 --
1 file changed, 10 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index
In old kernels, it's allowed to set softlockup_thresh to -1 or 0
to disable softlockup detection. However watchdog_thresh only
uses 0 to disable detection, and setting it to -1 just froze my
box and nothing I can do but reboot.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/sysctl.c | 3
hugetlb cgroup has already been implemented.
Signed-off-by: Li Zefan lize...@huawei.com
---
Documentation/cgroups/memory.txt | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index ddf4f93..327acec
->d_fsdata.
This bug has been there since cgroup xattr was introduced.
Cc: # 3.8.x
Reported-by: Ivan Bulatovic
Reported-by: Casey Schaufler
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgrou
-d_fsdata.
This bug has been there since cgroup xattr was introduced.
Cc: sta...@vger.kernel.org # 3.8.x
Reported-by: Ivan Bulatovic combus...@archlinux.us
Reported-by: Casey Schaufler ca...@schaufler-ca.com
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 9 +
1 file changed, 5
"hugetlbfs: fix mmap failure in unaligned size request").
Reported-by: Dave Jones
Cc:
Signed-off-by: Li Zefan
---
Previously it would return -ENODEV, but seems -EINVAL is more appropriate.
---
ipc/shm.c | 8 +++-
mm/mmap.c | 8 ++--
2 files changed, 13 insertions(+), 3 delet
] ? shm_get_unmapped_area+0x20/0x20
[ 163.984499] [816caa14] tracesys+0xdd/0xe2
This bug was introduced by commit af73e4d9506d3b797509f3c030e7dcd554f7d9c4
(hugetlbfs: fix mmap failure in unaligned size request).
Reported-by: Dave Jones da...@redhat.com
Cc: sta...@vger.kernel.org
Signed-off-by: Li Zefan liz
On 2013/5/8 10:38, Greg KH wrote:
> On Wed, May 08, 2013 at 10:24:44AM +0800, Chen Gang wrote:
>> Hello Maintainers:
>>
>> Please help check, when you have time.
>>
>> Thanks.
>>
>> On 2013年04月07日 11:28, Chen Gang wrote:
>
>
>
> You sent a cleanup patch in the middle of the merge window, when
>> There's a bug in cgroup_unload_subsys() that idr_destroy() should be called
>> after
>> ss->css_free(). That said, given there's no modular cgroup subsystem using
>> css_id,
>> and the whole css_id thing will be eliminated in 3.11, why bother fixing it.
>>
>
> I just find it by reading code
On 2013/5/7 18:46, Chen Gang wrote:
> Hello Maintainers:
>
> After call get_new_cssid(), I can not find the related free function
> (it seems free_css_id() is for that, but not used).
>
> The memory location is:
> get_new_cssid() --> kzalloc() for 'struct css_id'
> get_new_cssid() -->
On 2013/5/7 18:46, Chen Gang wrote:
Hello Maintainers:
After call get_new_cssid(), I can not find the related free function
(it seems free_css_id() is for that, but not used).
The memory location is:
get_new_cssid() -- kzalloc() for 'struct css_id'
get_new_cssid() -- idr_alloc() for
There's a bug in cgroup_unload_subsys() that idr_destroy() should be called
after
ss-css_free(). That said, given there's no modular cgroup subsystem using
css_id,
and the whole css_id thing will be eliminated in 3.11, why bother fixing it.
I just find it by reading code (I also want to
On 2013/5/8 10:38, Greg KH wrote:
On Wed, May 08, 2013 at 10:24:44AM +0800, Chen Gang wrote:
Hello Maintainers:
Please help check, when you have time.
Thanks.
On 2013年04月07日 11:28, Chen Gang wrote:
snip
You sent a cleanup patch in the middle of the merge window, when we
can't take
SND_MPC52xx_SOC_EFIKA
tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
depends on PPC_EFIKA
This bug was introduced by commit bcdedcc1afd6 ("menuconfig: print more
info for symbol without prompts").
Reported-by: Borislav Petkov
Signed-off-by: Li
On 2013/5/6 23:49, Borislav Petkov wrote:
> When I do
>
> make menuconfig
>
> then press '/' in order to search for a symbol, and I type 'EFI', for
> example, and press enter, I get:
>
> │ Enter CONFIG_ (sub)string to search for (with or without "CONFIG_")│
> │
On 2013/5/6 23:49, Borislav Petkov wrote:
When I do
make menuconfig
then press '/' in order to search for a symbol, and I type 'EFI', for
example, and press enter, I get:
│ Enter CONFIG_ (sub)string to search for (with or without CONFIG_)│
│
SND_MPC52xx_SOC_EFIKA
tristate SoC AC97 Audio support for bbplan Efika and STAC9766
depends on PPC_EFIKA
This bug was introduced by commit bcdedcc1afd6 (menuconfig: print more
info for symbol without prompts).
Reported-by: Borislav Petkov b...@alien8.de
Signed-off-by: Li Zefan lize
from cpuset_hotplug_workfn().
Reported-by: Fengguang Wu
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index ef05901..2422c5b 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -789,13 +789,6 @@ out:
static
a little simpler.
Signed-off-by: Li Zhong
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 943968d..b0f18ba 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2184,17 +2184,8
[] ? cpuset_read_u64+0x100/0x100
[] ? cgroup_iter_next+0x90/0x90
[] ? cpuset_css_offline+0x70/0x70
[] cgroup_file_write+0x133/0x2e0
[] vfs_write+0xcb/0x130
[] sys_write+0x64/0xa0
Reported-by: Li Zhong
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion
] ? cpuset_css_offline+0x70/0x70
[810c1a73] cgroup_file_write+0x133/0x2e0
[8118995b] vfs_write+0xcb/0x130
[8118a174] sys_write+0x64/0xa0
Reported-by: Li Zhong zh...@linux.vnet.ibm.com
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 10 +-
1 file changed
, and makes the code looks a little simpler.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 943968d..b0f18ba 100644
cpuset_hotplug_workfn().
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cpuset.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index ef05901..2422c5b 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
I mistakenly removed the call to eventfd->poll() while I was actually
intending to remove the return value...
Calling evenfd->poll() will hook cgroup_event_wake() to the poll
waitqueue, which will be called to unregister eventfd when rmdir a
cgroup or close eventfd.
Signed-off-by: Li
ore ida_simple_removed() is called. What's
worse is we're accessing cgrp->root while it has been freed.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 6780459..a45aa12 100644
--- a/ker
On 2013/4/25 18:05, Anurup m wrote:
> Hi All,
>
> There is a kernel memory leak observed when the proc file
> /proc/fs/fscache/stats is read.
> The reason is that in fscache_stats_open, single_open is called and
> respective release function is not called during release.
> Hence fix with
On 2013/4/25 18:05, Anurup m wrote:
Hi All,
There is a kernel memory leak observed when the proc file
/proc/fs/fscache/stats is read.
The reason is that in fscache_stats_open, single_open is called and
respective release function is not called during release.
Hence fix with correct
. What's
worse is we're accessing cgrp-root while it has been freed.
Signed-off-by: Li Zefan lize...@huawei.com
---
kernel/cgroup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 6780459..a45aa12 100644
--- a/kernel/cgroup.c
+++ b
I mistakenly removed the call to eventfd-poll() while I was actually
intending to remove the return value...
Calling evenfd-poll() will hook cgroup_event_wake() to the poll
waitqueue, which will be called to unregister eventfd when rmdir a
cgroup or close eventfd.
Signed-off-by: Li Zefan lize
On 2013/4/25 6:42, Guenter Roeck wrote:
> On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
>>
>>
>> On 04/08/2013 04:19 PM, John Stultz wrote:
>>> On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
>>
A simple check for an overflow can resolve this problem. Using KTIME_MAX
On 2013/4/25 6:42, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
On 04/08/2013 04:19 PM, John Stultz wrote:
On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
A simple check for an overflow can resolve this problem. Using KTIME_MAX
instead of the
On 2013/4/20 4:58, Tejun Heo wrote:
> Hello,
>
> On Fri, Apr 19, 2013 at 08:29:24PM +0800, Li Zefan wrote:
>> +static void update_tasks_cpumask_hier(struct cpuset *root_cs,
>> + bool update_root, struct ptr_heap *heap)
>> +
On 2013/4/20 2:36, Tejun Heo wrote:
> Hello, Li.
>
> On Fri, Apr 19, 2013 at 08:27:05PM +0800, Li Zefan wrote:
>> I think this was introduced unintentionally when cpuset hotplug was
>> made asynchronous. Fortunately it does no harm, as updating tasks'
>> cpuma
To achieve this:
- We call update_tasks_cpumask/nodemask() for empty cpusets when
hotplug happens, instead of moving tasks out of them.
- When a cpuset's masks are changed by writing cpuset.cpus/mems,
we also update tasks in child cpusets which are empty.
Signed-off-by: Li Zefan
---
kernel
:
- They can be moved to another cpuset, regardless it's empty or not.
- Though it takes masks from ancestors, it takes other configs from the
empty cpuset.
- If the ancestors' masks are changed, those tasks will also be updated
to take new masks.
Signed-off-by: Li Zefan
---
kernel/cpuset.c
cpusets.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 76 -
1 file changed, 65 insertions(+), 11 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index c4f9ebd..741e652 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -794,6
old mems_allowed in cpuset->old_mems_allowed.
This currently won't change any behavior, but it will later allow
us to keep tasks in empty cpusets.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 62 +
1 file changed, 36 insertions(
901 - 1000 of 1870 matches
Mail list logo