get_gate_vma(priv->task->mm) looks ugly and wrong, task->mm can be
NULL or it can changed by exec right after mm_access().
And in theory this race is not harmless, the task can exec and then
later exit and free the new mm_struct. In this case get_task_mm(oldmm)
can't help, get_gate_vma(task->mm) can read the freed/unmapped memory.
I think that priv->task should simply die and hold_task_mempolicy()
logic can be simplified. tail_vma logic asks for cleanups too.
Signed-off-by: Oleg Nesterov <o...@redhat.com>
---
fs/proc/task_mmu.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index cfa63ee..8a5271e 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -170,7 +170,7 @@ static void *m_start(struct seq_file *m, loff_t *pos)
return mm;
down_read(&mm->mmap_sem);
- tail_vma = get_gate_vma(priv->task->mm);
+ tail_vma = get_gate_vma(mm);
priv->tail_vma = tail_vma;
hold_task_mempolicy(priv);
/* Start with last addr hint */
@@ -351,12 +351,11 @@ static int show_map(struct seq_file *m, void *v, int
is_pid)
{
struct vm_area_struct *vma = v;
struct proc_maps_private *priv = m->private;
- struct task_struct *task = priv->task;
show_map_vma(m, vma, is_pid);
if (m->count < m->size) /* vma is copied successfully */
- m->version = (vma != get_gate_vma(task->mm))
+ m->version = (vma != priv->tail_vma)
? vma->vm_start : 0;
return 0;
}
@@ -584,7 +583,6 @@ static void show_smap_vma_flags(struct seq_file *m, struct
vm_area_struct *vma)
static int show_smap(struct seq_file *m, void *v, int is_pid)
{
struct proc_maps_private *priv = m->private;
- struct task_struct *task = priv->task;
struct vm_area_struct *vma = v;
struct mem_size_stats mss;
struct mm_walk smaps_walk = {
@@ -639,7 +637,7 @@ static int show_smap(struct seq_file *m, void *v, int
is_pid)
show_smap_vma_flags(m, vma);
if (m->count < m->size) /* vma is copied successfully */
- m->version = (vma != get_gate_vma(task->mm))
+ m->version = (vma != priv->tail_vma)
? vma->vm_start : 0;
return 0;
}
--
1.5.5.1
--
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/
