We no longer clear kn->priv in cgroup_rmdir(), so we don't need
to get an extra refcnt.
Signed-off-by: Zefan Li
---
kernel/cgroup.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 0ce9d9e..26b8cb9 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@
Currently we use a global work to schedule release agent on removable
cgroups. We can change to reuse css->destroy_work to do this, which
saves a few lines of code.
Signed-off-by: Zefan Li
---
include/linux/cgroup.h | 7
kernel/cgroup.c| 108 ++-
We never grab cgroup mutex in fork and exit paths no matter whether
notify_on_release is set or not.
Signed-off-by: Zefan Li
---
kernel/cgroup.c | 8
1 file changed, 8 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 26b8cb9..1abb554 100644
--- a/kernel/cgroup.c
+++ b/
Signed-off-by: Zefan Li
---
include/linux/cgroup.h | 1 -
kernel/cgroup.c| 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index b5223c5..f7898e0 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -27,7 +27,6 @@
stru
On 2014/9/17 13:29, Li Zefan wrote:
> On 2014/9/17 7:56, Cong Wang wrote:
>> Hi, Tejun
>>
>>
>> We saw some kernel null pointer dereference in
>> cgroup_pidlist_destroy_work_fn(), more precisely at
>> __mutex_lock_slowpath(), on 3.14. I can show you the full
On 2014/9/17 7:56, Cong Wang wrote:
> Hi, Tejun
>
>
> We saw some kernel null pointer dereference in
> cgroup_pidlist_destroy_work_fn(), more precisely at
> __mutex_lock_slowpath(), on 3.14. I can show you the full stack trace
> on request.
>
Yes, please.
> Looking at the code, it seems flush_
I think this is the same bug as the one you reported recently, which
has been fixed in mainline.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a4189487da1b4f8260c6006b9dc47c3c4107a5ae
On 2014/9/13 0:19, Toralf Förster wrote:
> Today I observed within a 32 bit KVM machi
On 2014/9/5 21:58, Guenter Roeck wrote:
> On 09/05/2014 12:55 AM, Li Zefan wrote:
>>>>> Li,
>>>>>
>>>>> it would be great if you can send me information about your -stable queue,
>>>>> ie how you maintain it and where it is located.
>>> Li,
>>>
>>> it would be great if you can send me information about your -stable queue,
>>> ie how you maintain it and where it is located. This will enable me to
>>> continue testing the stable queue for the 3.4 kernel.
>>>
>>
>> Thanks for testing LTS kernels!
>>
>> This is my 3.4.y git tree:
Hi Guenter,
Sorry for my late reply.
On 2014/8/27 12:59, Guenter Roeck wrote:
> On Tue, Aug 26, 2014 at 04:08:58PM -0700, Greg KH wrote:
>> Li has agreed to continue to support the 3.4 stable kernel tree until
>> September 2016. Update the releases.html page on kernel.org to reflect
>> this.
>>
When cgroup_kn_lock_live() is called through some kernfs operation and
another thread is calling cgroup_rmdir(), we'll trigger the warning in
cgroup_get().
[ cut here ]
WARNING: CPU: 1 PID: 1228 at kernel/cgroup.c:1034 cgroup_get+0x89/0xa0()
...
Call Trace:
[] dump_stack+0
Run these two scripts concurrently:
for ((; ;))
{
mkdir /cgroup/sub
rmdir /cgroup/sub
}
for ((; ;))
{
echo $$ > /cgroup/sub/cgroup.procs
echo $$ > /cgroup/cgroup.procs
}
A kernel bug will be triggered:
BUG: unable to handle kernel NULL poi
于 2014/9/2 23:33, Tejun Heo 写道:
> Hello, Li.
>
> On Tue, Sep 02, 2014 at 06:56:58PM +0800, Li Zefan wrote:
>> for ((; ;))
>> {
>> echo $$ > /cgroup/sub/cgroup.procs
>> ech $$ > /cgce 6f2e0c38c2108a74 ]---
> ^^^
/0x1e0
[] SyS_write+0x4d/0xa0
[] sysenter_do_call+0x12/0x12
---[ end trace 6f2e0c38c2108a74 ]---
Fix this by calling css_tryget() instead of cgroup_get().
Reported-by: Toralf Förster
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff
e to the cgroup and no one can gain a new
reference to access it.
Reported-by: Toralf Förster
Signed-off-by: Li Zefan
---
Toralf, Thanks for reporting the bug. I'm not able to repy to your email,
because I was kicked out of the cgroup mailing list so didn't receive
emails fro
On 2014/8/25 23:00, Dongsheng Yang wrote:
> On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo wrote:
>> On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote:
>>> My point here is that attaching and detaching are a pair of operations.
>>
>> There is no detaching from a cgroup. A task is always
On 2014/8/12 5:05, David Rientjes wrote:
> On Mon, 11 Aug 2014, Vladimir Davydov wrote:
>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -1963,7 +1963,7 @@ zonelist_scan:
>>>
>>> /*
>>> * Scan zonelist, looking for a zone wi
The WARN_ON() is used to check if we break the legal hierarchy, on
which the effective mems should be equal to configured mems.
Reported-by: Mike Qiu
Tested-by: Mike Qiu
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel
On 2014/7/29 3:20, Tejun Heo wrote:
> On Thu, Jul 24, 2014 at 08:27:40AM +0800, Li Zefan wrote:
>> On 2014/7/23 23:12, Tejun Heo wrote:
>>> On Wed, Jul 23, 2014 at 10:50:29AM +0800, Mike Qiu wrote:
>>>> commit 734d45130cb ("cpuset: update cs->effective
On 2014/7/23 23:12, Tejun Heo wrote:
> On Wed, Jul 23, 2014 at 10:50:29AM +0800, Mike Qiu wrote:
>> commit 734d45130cb ("cpuset: update cs->effective_{cpus, mems} when config
>> changes") introduce the below warning in my server.
>>
>> [ 35.652137] [ cut here ]
>> [ 35.6
2
> kernel/sched/cpuacct.c |2
> mm/hugetlb_cgroup.c |5
> mm/memcontrol.c |6 -
> net/core/netclassid_cgroup.c|2
> net/core/netprio_cgroup.c |2
> ne
> @@ -3085,8 +3091,37 @@ static int cgroup_add_cftypes(struct cgroup_subsys
> *ss, struct cftype *cfts)
> return ret;
> }
>
> +/**
> + * cgroup_add_dfl_cftypes - add an array of cftypes for default hierarchy
> + * @ss: target cgroup subsystem
> + * @cfts: zero-length name terminated array
We mix the handling for both default hierarchy and legacy hierarchy in
the same function, and it's quite messy, so split into two functions.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 121 ++--
1 file changed, 66 insertions(+), 55 dele
rchy
won't be affected.
v2:
- make refactoring of cpuset_hotplug_update_tasks() as seperate patch,
suggested by Tejun.
- make hotplug_update_tasks_insane() use @new_cpus and @new_mems as
hotplug_update_tasks_sane() does.
Signed-off-by: Li Zefan
---
ke
cpuset.cpus and cpuset.mems are the configured masks, and we need
to export effective masks to userspace, so users know the real
cpus_allowed and mems_allowed that apply to the tasks in a cpuset.
v2:
- export those masks unconditionally, suggested by Tejun.
Signed-off-by: Li Zefan
---
kernel
te error: Invalid argument
Note the checks don't need to be gated by cgroup_on_dfl, because we've
initialized top_cpuset.{cpus,mems}_allowed accordingly in cpuset_bind().
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
ks are always the same with user-configured
masks.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 83 ++---
1 file changed, 14 insertions(+), 69 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index e4c31e6..820870a 100644
--- a/k
be limited by its parent's masks.
This ia a behavior change, but won't take effect unless mount with
sane_behavior.
v2:
- Add comments to explain the differences between configured masks and
effective masks.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 35 +++
x to use @cp instead of @cs in these two functions.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 88 +++--
1 file changed, 54 insertions(+), 34 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 94f651d..da766c3 100644
--- a/kernel
at /cpuset/cpuset.cpus
0-15
On legacy hierarchy:
# mount -t cgroup xxx /cpuset
# cat /cpuset/cpuset.cpus
0,2-15
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/kernel/
te the effective masks at config change
- take on ancestor's mask when the effective mask is empty
The last item is done here.
This won't introduce behavior change.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 22 ++
1 file changed, 22 insertions(+)
diff --git
ks in the cpuset.
This won't introduce behavior change.
v2:
- Add a comment for the call of rebuild_sched_domains(), suggested
by Tejun.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/kernel/cpuset
me with configured
masks, and a child cpuset inherits its parent's effective masks.
This won't introduce behavior change.
v2:
- s/real_{mems,cpus}_allowed/effective_{mems,cpus}, suggested by Tejun.
- don't init effective masks in cpuset_css_online() if !cgroup_on_dfl.
Signed
te the effective masks at config change
- take on ancestor's mask when the effective mask is empty
The first item is done here.
This won't introduce behavior change.
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/cpuset.
exported cpuset.effective_{cpus,mems} unconditionally
Li Zefan (12):
cpuset: add cs->effective_cpus and cs->effective_mems
cpuset: update cpuset->effective_{cpus,mems} at hotplug
cpuset: update cs->effective_{cpus,mems} when config changes
cpuset: inherit ancestor's masks if effective_
> kernel/cpuset.c | 33 +---
> mm/memcontrol.c|7 +-
> 5 files changed, 117 insertions(+), 153 deletions(-)
>
Acked-by: Li Zefan
I'm rebasing my cpuset patchset against this.
--
To unsubscribe from this list: send the line "unsubscribe li
On 2014/7/8 9:10, xiaofeng.yan wrote:
> On 2014/7/7 16:41, Peter Zijlstra wrote:
>> On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
>>> It could be wrong for the precision of runtime and deadline
>>> when the precision is within microsecond level. For example:
>>> Task runtime deadlin
On 2014/7/4 15:11, xuwei wrote:
>
> Introduce a new mach-hisi that will support Hisilicon SoCs based on ARMv7
> and I am taking maintainership for it.
>
> Signed-off-by: Wei Xu
> ---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> inde
| 201
> ++--
> mm/memcontrol.c | 24 +++
> 6 files changed, 243 insertions(+), 46 deletions(-)
>
Acked-by: Li Zefan
--
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 read the FAQ at http://www.tux.org/lkml/
On 2014/7/1 3:47, Tejun Heo wrote:
> Hey, Li.
>
> Can you please test this patch and ack it?
>
...
> Signed-off-by: Tejun Heo
> Reported-by: Li Zefan
Tested-by: Li Zefan
Thanks!
> ---
> kernel/cpuset.c | 12
> 1 file changed, 12 insertions(+)
cgroup_root may have no superblock assosiated with it.
- adjust/add comments.
Cc: # 3.15
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d3662ac..11e40cf 1006
kernfs_pin_sb() tries to get a refcnt of the superblock.
This will be used by cgroupfs.
v2:
- make kernfs_pin_sb() return the superblock.
- drop kernfs_drop_sb().
[ This is a prerequisite for a bugfix. ]
Cc: # 3.15
Acked-by: Greg Kroah-Hartman
Signed-off-by: Li Zefan
---
fs/kernfs/mount.c
.
Cc: # 3.15
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c65f24..d3662ac 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1648,10 +1648,12 @@ static struct dentry *cgroup_mount(s
Hi Tejun,
In this lockdep warning kernfs and workqueue are involved, so I'm not sure
what's
happening here.
This was triggered when tasks were being moved to parent cpuset due to hotplug.
The kernel is 3.16-rc1, with no modification.
localhost:/ # mount -t cgroup -o cpuset xxx /cpuset
localhost
On 2014/6/28 19:58, Tejun Heo wrote:
> Hello, Li.
>
> On Fri, Jun 27, 2014 at 05:13:12PM +0800, Li Zefan wrote:
>> +for_each_subsys(ss, i) {
>> +if (!(opts.subsys_mask & (1 << i)) ||
>> +ss->root == &cgr
Made a mistake again.. :(
==
From: Li Zefan
Subject: [PATCH 1/3] cgroup: fix mount failure in a corner case
# cat test.sh
#! /bin/bash
mount -t cgroup -o cpu xxx /cgroup
umount /cgroup
mount -t cgroup -o cpu,cpuacct xxx /cgroup
umount /cgroup
# ./test.sh
mount
Oh sorry the cut&paste was incomplete. Here's the complete one:
====
From: Li Zefan
Date: Thu, 12 Jun 2014 09:11:00 +0800
Subject: [PATCH v2 1/3] cgroup: fix mount failure in a corner case
# cat test.sh
#! /bin/bash
mount -t cgroup -o cpu xxx /cgroup
umoun
kernfs_pin_sb() tries to get a refcnt of the superblock.
This will be used by cgroupfs.
v2:
- make kernfs_pin_sb() return pointer to the superblock.
- drop kernfs_drop_sb().
Signed-off-by: Li Zefan
---
fs/kernfs/mount.c | 27 +++
include/linux/kernfs.h | 1 +
2
cgroup_root may have no superblock assosiated with it.
- adjust/add comments.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ae2b382..111b7c3 100644
--- a/kernel
ot of the first mount was under destruction
asynchronously.
Fix this by delaying and then retrying mount for this case.
v2:
- use percpu_ref_tryget_live() rather that introducing
percpu_ref_alive(). (Tejun)
- adjust comment.
Signed-off-by: Li Zefan
---
kernel/cgroup.c
On 2014/6/25 23:00, Tejun Heo wrote:
> Hey,
>
> On Wed, Jun 25, 2014 at 09:56:31AM +0800, Li Zefan wrote:
>>> Hmmm? Why does that matter? The only region in cgroup_mount() which
>>> needs to be put inside such mutex would be root lookup, no?
>>
>> unfortun
the forker's task_struct is duplicated (which includes ->mems_allowed)
> and it races with an update to cpuset_being_rebound in update_tasks_nodemask()
> then the task's mems_allowed doesn't get updated. And the child task's
> mems_allowed can be wrong if the cpuset
On 2014/6/25 11:30, Chen Hanxiao wrote:
> s/iff/if
>
This is not a typo. iff == if and only if.
> Signed-off-by: Chen Hanxiao
> ---
> Documentation/cgroups/cgroups.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/cgroups/cgroups.txt
> b/Documentation
On 2014/6/25 5:01, Tejun Heo wrote:
> Hello, Li.
>
> On Tue, Jun 24, 2014 at 09:22:00AM +0800, Li Zefan wrote:
>>> Ah, right. Gees, I'm really hating the fact that we have ->mount but
>>> not ->umount. However, can't we make it a bit simpler by just
&g
On 2014/6/21 5:01, Tejun Heo wrote:
> Hello, Li.
>
> Sorry about the long delay.
>
> On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote:
>> Yes, this is a long-standing issue. Besides the race you described, the child
>> task's mems_allowed can be wrong
On 2014/6/21 3:35, Tejun Heo wrote:
> Hello, Li.
>
> Sorry about the long delay.
>
> On Thu, Jun 12, 2014 at 02:33:05PM +0800, Li Zefan wrote:
>> We've converted cgroup to kernfs so cgroup won't be intertwined with
>> vfs objects and locking, but there are d
On 2014/6/21 3:10, Tejun Heo wrote:
> On Thu, Jun 12, 2014 at 02:32:13PM +0800, Li Zefan wrote:
>> @@ -1677,6 +1679,22 @@ static struct dentry *cgroup_mount(struct
>> file_system_type *fs_type,
>> goto out_unlock;
>> }
>>
>> +/*
d B is mounting
the same cgroup root and finds the root in the root list and performs
percpu_ref_try_get().
To fix this, we increase the refcnt of the superblock instead of increasing
the percpu refcnt of cgroup root.
Signed-off-by: Li Zefan
---
A better fix is welcome!
---
kerne
e the cgroupfs_root of the first mount was under destruction
asynchronously.
Fix this by delaying and then retrying mount in this case.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c65f24..bd
kernfs_pin_sb() tries to get a refcnt of the superblock, while
kernfs_drop_sb() drops this refcnt.
This will be used by cgroupfs.
Signed-off-by: Li Zefan
---
fs/kernfs/mount.c | 45 +
include/linux/kernfs.h | 3 +++
2 files changed, 48
This is used to check if the percpu_ref has been killed.
Signed-off-by: Li Zefan
---
include/linux/percpu-refcount.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index dba35c4..1d5f2b3 100644
--- a/include
pu 1 1 1
...
It turned out css_has_online_children() is broken.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 05b8ca4..1c65f24 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgr
On 2014/6/9 17:13, David Rientjes wrote:
> On Mon, 9 Jun 2014, Gu Zheng wrote:
>
>>> I think your patch addresses the problem that you're reporting but misses
>>> the larger problem with cpuset.mems rebinding on fork(). When the
>>> forker's task_struct is duplicated (which includes ->mems_allo
group
...
memory.failcnt memory.move_charge_at_immigrate
memory.force_empty memory.numa_stat
memory.limit_in_bytesmemory.oom_control
...
# cat /cgroup/memory.usage_in_bytes
0
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 12
1 file chang
On 2014/6/5 9:20, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 04, 2014 at 04:59:59PM +0800, Li Zefan wrote:
>> The example I gave is the same result if sane_behavior is not specified,
>> so this is a behavioural change for the old interface?
>
> Hmmm? Either the u
On 2014/6/3 21:01, Tejun Heo wrote:
> On Tue, Jun 03, 2014 at 12:05:22PM +0800, Li Zefan wrote:
>> Before this patch (in a fresh system):
>>
>># cat /proc/$$/cgroup
>># mount -t cgroup -o __DEVEL__sane_behavior xxx /cgroup
>># umount /cgroup
>&g
_NO_REF in cgroup_get/put(). (Tejun)
- Better call cgroup_put() for the default root in kill_sb(). (Tejun)
- Add a comment.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index a5f75ac..3f46165 100644
--
On 2014/6/3 20:57, Tejun Heo wrote:
> Hello, Li.
>
> On Tue, Jun 03, 2014 at 12:04:38PM +0800, Li Zefan wrote:
>> static void cgroup_get(struct cgroup *cgrp)
>> {
>> WARN_ON_ONCE(cgroup_is_dead(cgrp));
>> -css_get(&cgrp->self);
>
This fixes the failure path, so we won't set the visible flag though
the mount is failed.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index dabc486..0b6b44e 100644
--- a/kernel/cgr
):
# cat ...
# mount ...
# umount ...
# cat /proc/$$/cgroup
#
You won't see the default root after it's umounted.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index f73fe48..dabc486 10
The default root is allocated and initialized at boot, so we
shouldn't destroy the default root when it's umounted, otherwise
it will lead to disaster.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/kerne
Cc: Greg
Cc: Jianyu Zhan
On 2014/6/3 8:56, Andy Lutomirski wrote:
> Sorry I didn't notice this earlier. Linux 3.15 breaks my production
But 3.15 hasn't been released. :)
> system :( The cause appears to be:
>
> commit 2bd59d48ebfb3df41ee56938946ca0dd30887312
> Author: Tejun Heo
> Date: Tue
On 2014/5/29 4:09, Aaro Koskinen wrote:
> Hi,
>
> On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
>> On 2014/5/21 13:36, Yong Zhang wrote:
>>> asid_cache must be unsigned long otherwise on 64bit system
>>> it will become 0 if the value in get_new_mmu_con
On 2014/5/20 4:33, Tejun Heo wrote:
> On Tue, May 13, 2014 at 03:49:58PM -0400, Tejun Heo wrote:
>> There are currently three cgroup related entries in MAINTAINERS. Make
>> the following updates.
>>
>> * Make the names - both cgroup and cpuset - singular. We're mixing
>> singular and plural all
On 2014/5/27 2:53, Marcelo Tosatti wrote:
>
> Zone specific allocations, such as GFP_DMA32, should not be restricted
> to cpusets allowed node list: the zones which such allocations demand
> might be contained in particular nodes outside the cpuset node list.
>
> The alternative would be to not p
On 2014/5/27 13:23, Yong Zhang wrote:
> On Tue, May 27, 2014 at 01:07:20PM +0800, Li Zefan wrote:
>> On 2014/5/27 12:50, Yong Zhang wrote:
>>> BTW, I realy don't care who credits the patch and Ralf said that
>>> he will applied the one which moves the place of ude
On 2014/5/27 12:50, Yong Zhang wrote:
> BTW, I realy don't care who credits the patch and Ralf said that
> he will applied the one which moves the place of udelay_val.
>
> Anyway, if your company pays you more money if you contribute to
> the community, just take it and talk about it with Ralf ;-)
On 2014/5/27 12:34, Yong Zhang wrote:
> On Tue, May 27, 2014 at 12:16:30PM +0800, Li Zefan wrote:
>> I'm not quite happy about what happaned here. There's a story behind
>> this patch.
>>
>> One of our Huawei product encountered a bug, and they're us
I'm not quite happy about what happaned here. There's a story behind
this patch.
One of our Huawei product encountered a bug, and they're using WindRiver4,
so the kernel is 2.6.34.
Because they bought your licnece, they asked for your help, but
you were reluctant on this issue, and the problem re
| 257
> ---
> kernel/cgroup_freezer.c |2
> kernel/cpuset.c |2
> kernel/sched/core.c |2
> kernel/sched/cpuacct.c |2
> mm/hugetlb_cgroup.c |2
> mm/memcontrol.c
On2014/5/14 21:07, Tejun Heo wrote:
> Hello, Li.
>
> On Wed, May 14, 2014 at 12:21:25PM +0800, Li Zefan wrote:
>>> There are now use cases where controllers need to iterate through
>>> csses regardless of their online state as long as they have positive
>>
>&
Hi Tejun,
On 2014/5/10 5:31, Tejun Heo wrote:
> Hello,
>
> Currently, while csses (cgroup_subsys_states) have ->parent linkage
> too, only cgroups form full tree through their ->children and
> ->sibling fields and css iterations naturally is implemented by
> iterating cgroups and then dereferenci
pe->write()
> + [3] (REFRESHED) [PATCHSET cgroup/for-3.16] cgroup: remove cgroup_tree_mutex
>
> and available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> review-use-css-ref
>
> diffstat follows. Thanks.
>
> in
On 2014/5/10 5:13, Tejun Heo wrote:
> cgroup_mount() uses dumb delay-and-retry logic to wait for cgroup_root
> which is being destroyed. The retry currently loops inside
> cgroup_mount() proper. This patch makes it return with
> restart_syscall() instead so that retry travels out to userland
> bo
cgroup/for-3.16] cgroup: implement cftype->write()
>
> and is available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> review-kill-tree_mutex
>
> diffstat follows. Thanks.
>
> kernel/cgroup.c | 385
> +++
++
> kernel/cpuset.c|6 +--
> kernel/events/core.c |3 +
> mm/hugetlb_cgroup.c|2 -
> mm/memcontrol.c| 46 +
> 8 files changed, 84 insertions(+), 79 deletions(-)
>
Acked-by: Li Zefan
--
.c | 20 --
> kernel/cpuset.c | 16
> mm/hugetlb_cgroup.c | 33 +
> mm/memcontrol.c | 80 +++
> net/ipv4/tcp_memcontrol.c | 31 +---
> security/device_cgroup.c |
Hi Tejun,
On 2014/5/10 3:32, Tejun Heo wrote:
> After waiting for a child to finish offline,
> cgroup_subtree_control_write() jumps up to retry from after the input
> parsing and active protection breaking. This retry makes the
> scheduled locking update more difficult.
Could you explain this se
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 35daf89..b81e7c0 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2542,11 +2542,13 @@ static int cgroup_subtree_control_write(struct
> cgroup_subsys_state *dummy_css,
> int ssid, ret;
>
> /*
> - * Parse input -
Commit-ID: 6a7cd273dc4bc3246f37ebe874754a54ccb29141
Gitweb: http://git.kernel.org/tip/6a7cd273dc4bc3246f37ebe874754a54ccb29141
Author: Li Zefan
AuthorDate: Thu, 17 Apr 2014 10:05:02 +0800
Committer: Ingo Molnar
CommitDate: Wed, 7 May 2014 11:51:32 +0200
sched/deadline: Fix memory leak
On 2014/5/6 1:49, Fabian Frederick wrote:
> Cc: Li Zefan
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Acked-by: Li Zefan
> ---
> kernel/cpuset.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/cpuset.c b/kernel/
On 2014/5/6 1:46, Fabian Frederick wrote:
> This patch also converts seq_printf to seq_puts
>
> Cc: Li Zefan
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Acked-by: Li Zefan
> ---
> kernel/cpuset.c | 11 ++-
> 1 file changed, 6 insertions(+), 5
-
> kernel/cgroup.c| 164
> ++++++++-
> mm/memcontrol.c| 10 --
> 3 files changed, 126 insertions(+), 69 deletions(-)
>
Acked-by: Li Zefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
(Just came back from a short vacation)
On 2014/5/1 23:46, Tejun Heo wrote:
> On Mon, Apr 28, 2014 at 11:33:16AM +0800, Li Zefan wrote:
>> On 2014/4/25 5:02, Tejun Heo wrote:
>>> Until now, cgroup->id has been used to identify all the associated
>>> csses and css
On 2014/4/25 5:02, Tejun Heo wrote:
> Until now, cgroup->id has been used to identify all the associated
> csses and css_from_id() takes cgroup ID and returns the matching css
> by looking up the cgroup and then dereferencing the css associated
> with it; however, now that the lifetimes of cgroup a
On 2014/4/22 15:12, Jianyu Zhan wrote:
> On Tue, Apr 22, 2014 at 2:06 PM, Ingo Molnar wrote:
>> How can that field ever be nonzero?
>>
>> I.e. under what exact circumstances does this patch make sense?
>
> Hi, Ingo,
>
> More explanation.
>
> Sure, for this global variable struct, if not initail
On 2014/4/22 15:01, Jianyu Zhan wrote:
> Hi, hillf,
>
> On Tue, Apr 22, 2014 at 2:47 PM, Hillf Danton wrote:
>> But other fields still missed, if any. Fair?
>
> yep, it is not fair.
>
> Sure for this global variable struct, if not initailized, its all
> fields will be initialized
> to 0 or null
On 2014/4/22 13:31, Jianyu Zhan wrote:
> For a cgroup subsystem who should init early, then it should carefully
> take care of the implementation of css_alloc, because it will be called
> before mm_init() setup the world.
>
> Luckily we don't, and we better explicitly assign the early_init field
>
On 2014/4/22 13:44, Jianyu Zhan wrote:
> To suppress this warning:
>
> warning: ‘err’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> int err;
> ^
I don't see this warning, and I don't see how this is possible.
static int create_css(struct cgroup *cgrp, struct cg
On 2014/4/22 13:27, Jianyu Zhan wrote:
> For a cgroup subsystem who should init early, then it should carefully
> take care of the implementation of css_alloc, because it will be called
> before mm_init() setup the world.
>
> Luckily we don't, and we better explicitly assign the early_init field
>
1 - 100 of 937 matches
Mail list logo
