[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160923155351.GA1584@redhat.com>
Date: Fri, 23 Sep 2016 17:53:51 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Robert Ho <robert.hu@...el.com>, pbonzini@...hat.com,
akpm@...ux-foundation.org, dan.j.williams@...el.com,
dave.hansen@...el.com, guangrong.xiao@...ux.intel.com,
gleb@...nel.org, mtosatti@...hat.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, stefanha@...hat.com,
yuhuang@...hat.com, linux-mm@...ck.org,
ross.zwisler@...ux.intel.com
Subject: Re: [PATCH v3 1/2] mm, proc: Fix region lost in /proc/self/smaps
On 09/23, Michal Hocko wrote:
>
> On Fri 23-09-16 15:56:36, Oleg Nesterov wrote:
> >
> > I think we can simplify this patch. And imo make it better. How about
>
> it is certainly less subtle because it doesn't report "sub-vmas".
>
> > if (last_addr) {
> > vma = find_vma(mm, last_addr - 1);
> > if (vma && vma->vm_start <= last_addr)
> > vma = m_next_vma(priv, vma);
> > if (vma)
> > return vma;
> > }
>
> we would still miss a VMA if the last one got shrunk/split
Not sure I understand what you mean... If the last one was split
we probably should not report the new vma. Nevermind, in any case
yes, sure, this can't "fix" other corner cases.
> So definitely an improvement but
> I guess we really want to document that only full reads provide a
> consistent (at some moment in time) output.
or all the threads were stopped. Agreed. And again, this applies to
any file in /proc.
Oleg.
Powered by blists - more mailing lists