On 30.04.2019 12:08, Cyrill Gorcunov wrote:
> On Tue, Apr 30, 2019 at 11:55:45AM +0300, Kirill Tkhai wrote:
>>> - up_write(>mmap_sem);
>>> + spin_unlock(>arg_lock);
>>> + up_read(>mmap_sem);
>>> return error;
>>
>> Hm, shouldn't spin_lock()/spin_unlock() pair go as a fixup to existing
On Tue, Apr 30, 2019 at 11:55:45AM +0300, Kirill Tkhai wrote:
> > - up_write(>mmap_sem);
> > + spin_unlock(>arg_lock);
> > + up_read(>mmap_sem);
> > return error;
>
> Hm, shouldn't spin_lock()/spin_unlock() pair go as a fixup to existing code
> in a separate patch?
>
> Without them,
On 30.04.2019 11:18, Michal Koutný wrote:
> Since commit 88aa7cc688d4 ("mm: introduce arg_lock to protect
> arg_start|end and env_start|end in mm_struct") we use arg_lock for
> boundaries modifications. Synchronize prctl_set_mm with this lock and
> keep mmap_sem for reading only (analogous to what
Since commit 88aa7cc688d4 ("mm: introduce arg_lock to protect
arg_start|end and env_start|end in mm_struct") we use arg_lock for
boundaries modifications. Synchronize prctl_set_mm with this lock and
keep mmap_sem for reading only (analogous to what we already do in
prctl_set_mm_map).
v2: call
4 matches
Mail list logo