Hi, Zefan
Thanks for your reply. You are right, vfs refcount should guarantee us
there is no more file read before we destroy that cgroup. I thought
there is somewhere else could release that cgroup refcount.
Maybe I didn't make it clear, this bug is hardly reproducible, we only
saw it once
Hi, Zefan
Thanks for your reply. You are right, vfs refcount should guarantee us
there is no more file read before we destroy that cgroup. I thought
there is somewhere else could release that cgroup refcount.
Maybe I didn't make it clear, this bug is hardly reproducible, we only
saw it once
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 stack trace
>> on request.
>>
>
> Yes,
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 stack trace
on request.
Yes, please.
Looking
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
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.
Looking at the code, it seems flush_workqueue() doesn't care about new
incoming works, it only processes
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.
Looking at the code, it seems flush_workqueue() doesn't care about new
incoming works, it only processes
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
8 matches
Mail list logo