[Bug runtime/22155] kernel panic due to NULL vma_cache_p->f_path.dentry

["penguin-kernel at i-love dot sakura dot ne dot jp" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22155

--- Comment #4 from Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> ---
(In reply to David Smith from comment #3)
> (In reply to Tetsuo Handa from comment #2)
> > > But, when that function gets called, the task is stopped.
> > > So, hopefully the task->mm won't be changing while the task is stopped.
> > 
> > Java is a multi-threaded process.
> > Are all threads stopped when that function gets called?
> 
> No, all threads aren't stopped. But, each userspace thread is represented by
> a task structure in the kernel.

Suppose process P1 has two threads T1 and T2, it is possible that this function
is called when T1 is stopped but T2 is running, isn't it?

You think T1->mm will not go away because T1 is stopped, that part is fine.

My question is, what prevents T2 from updating (or removing) vma->vm_file
after this function released mmap_sem? I think there is a possibility that
vma->vm_file is released (or vma->vm_file.dentry becomes NULL) before
&vma->vm_file
is dereferenced at d_path().

If the reason "struct vma_cache_t" saves

        struct dentry *dentry;
        unsigned long addr;
        unsigned long length;
        unsigned long offset;
        unsigned long vm_flags;

before releasing mmap_sem is that vma might change after releasing mmap_sem,
why is it safe to save the address of vma->vm_file like

        vma_cache_p->f_path = &(vma->vm_file->f_path);

? I think it is not safe unless we copy "struct path" like

        struct path f_path;

        vma_cache_p->f_path = vma->vm_file->f_path;
        path_get(&vma_cache_p->f_path);

and use like

        mmpath = d_path(&vma_cache_p->f_path, mmpath_buf,
                        PATH_MAX);
        path_put(&vma_cache_p->f_path);

.

-- 
You are receiving this mail because:
You are the assignee for the bug.