lkml.org 
[lkml]   [2018]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct
On Tue, Mar 27, 2018 at 02:20:39AM +0800, Yang Shi wrote:
> +++ b/kernel/sys.c
> @@ -1959,7 +1959,7 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
> return error;
> }
>
> - down_write(&mm->mmap_sem);
> + down_read(&mm->mmap_sem);
>
> /*
> * We don't validate if these members are pointing to
> @@ -1980,10 +1980,13 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
> mm->start_brk = prctl_map.start_brk;
> mm->brk = prctl_map.brk;
> mm->start_stack = prctl_map.start_stack;
> +
> + spin_lock(&mm->arg_lock);
> mm->arg_start = prctl_map.arg_start;
> mm->arg_end = prctl_map.arg_end;
> mm->env_start = prctl_map.env_start;
> mm->env_end = prctl_map.env_end;
> + spin_unlock(&mm->arg_lock);
>
> /*
> * Note this update of @saved_auxv is lockless thus

I see the argument for the change to a write lock was because of a BUG
validating arg_start and arg_end, but more generally, we are updating these
values, so a write-lock is probably a good idea, and this is a very rare
operation to do, so we don't care about making this more parallel. I would
not make this change (but if other more knowledgable people in this area
disagree with me, I will withdraw my objection to this part).

\
 
 \ /
  Last update: 2018-03-26 20:37    [W:0.118 / U:2.856 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site