Re: Kernel crash in cgroup_pidlist_destroy_work_fn()

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

Re: Kernel crash in cgroup_pidlist_destroy_work_fn()

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,

Re: Kernel crash in cgroup_pidlist_destroy_work_fn()

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_

Kernel crash in cgroup_pidlist_destroy_work_fn()

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