lkml.org 
[lkml]   [2018]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct
    On Tue 10-04-18 14:02:42, Cyrill Gorcunov wrote:
    > On Tue, Apr 10, 2018 at 12:42:15PM +0200, Michal Hocko wrote:
    > > On Tue 10-04-18 12:40:47, Cyrill Gorcunov wrote:
    > > > On Tue, Apr 10, 2018 at 11:09:17AM +0200, Michal Hocko wrote:
    > > > > On Tue 10-04-18 05:52:54, Yang Shi wrote:
    > > > > [...]
    > > > > > So, introduce a new spinlock in mm_struct to protect the concurrent
    > > > > > access to arg_start|end, env_start|end and others except start_brk and
    > > > > > brk, which are still protected by mmap_sem to avoid concurrent access
    > > > > > from do_brk().
    > > > >
    > > > > Is there any fundamental problem with brk using the same lock?
    > > >
    > > > Seems so. Look into mm/mmap.c:brk syscall which reads and writes
    > > > brk value under mmap_sem ('cause of do_brk called inside).
    > >
    > > Why cannot we simply use the lock when the value is updated?
    >
    > Because do_brk does vma manipulations, for this reason it's
    > running under down_write_killable(&mm->mmap_sem). Or you
    > mean something else?

    Yes, all we need the new lock for is to get a consistent view on brk
    values. I am simply asking whether there is something fundamentally
    wrong by doing the update inside the new lock while keeping the original
    mmap_sem locking in the brk path. That would allow us to drop the
    mmap_sem lock in the proc path when looking at brk values.

    --
    Michal Hocko
    SUSE Labs

    \
     
     \ /
      Last update: 2018-04-10 13:11    [W:2.473 / U:1.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site