Re: [PATCH 3/3] prctl_set_mm: downgrade mmap_sem to read lock

2019-04-30 Thread Kirill Tkhai
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

Re: [PATCH 3/3] prctl_set_mm: downgrade mmap_sem to read lock

2019-04-30 Thread Cyrill Gorcunov
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,

Re: [PATCH 3/3] prctl_set_mm: downgrade mmap_sem to read lock

2019-04-30 Thread Kirill Tkhai
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

[PATCH 3/3] prctl_set_mm: downgrade mmap_sem to read lock

2019-04-30 Thread Michal Koutný
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