From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S938825AbcHJSrv (ORCPT <rfc822;w@1wt.eu>);
	Wed, 10 Aug 2016 14:47:51 -0400
Received: from mail-yb0-f181.google.com ([209.85.213.181]:35478 "EHLO
	mail-yb0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S938657AbcHJSrr (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 10 Aug 2016 14:47:47 -0400
X-Greylist: delayed 2243 seconds by postgrey-1.27 at vger.kernel.org; Wed, 10 Aug 2016 14:47:47 EDT
MIME-Version: 1.0
In-Reply-To: <20160810173719.GA25801@pc.thejh.net>
References: <1470758743-17685-1-git-send-email-robert.foss@collabora.com>
 <20160809192414.GA19573@pc.thejh.net> <8ac1b493-e051-ea0e-3a71-c4476054bdb2@collabora.com>
 <CAPz6YkUKN9xOO=m2sLGNGkH9uSa4cvyDWAPPS6RFwheOS=opcA@mail.gmail.com> <20160810173719.GA25801@pc.thejh.net>
From: Sonny Rao <sonnyrao@chromium.org>
Date: Wed, 10 Aug 2016 10:45:51 -0700
X-Google-Sender-Auth: --k_0thO1Bm4pjbrmD4rdTBeW5c
Message-ID: <CAPz6YkWqitM+_8detGcyzU3n2PwnrMciRjeN1Bj4SER6s-24PA@mail.gmail.com>
Subject: Re: [PACTH v1] mm, proc: Implement /proc/<pid>/totmaps
To: Jann Horn <jann@thejh.net>
Cc: Robert Foss <robert.foss@collabora.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>, Al Viro <viro@zeniv.linux.org.uk>,
        Cyrill Gorcunov <gorcunov@openvz.org>,
        John Stultz <john.stultz@linaro.org>,
        Robin Humble <plaguedbypenguins@gmail.com>,
        Mateusz Guzik <mguzik@redhat.com>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        Janis Danisevskis <jdanis@google.com>, calvinowens@fb.com,
        Michal Hocko <mhocko@suse.com>,
        Konstantin Khlebnikov <koct9i@gmail.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        ldufour@linux.vnet.ibm.com, Johannes Weiner <hannes@cmpxchg.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ben Zhang <benzh@chromium.org>, Bryan Freed <bfreed@chromium.org>,
        Filipe Brandenburger <filbranden@chromium.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Aug 10, 2016 at 10:37 AM, Jann Horn <jann@thejh.net> wrote:
> On Wed, Aug 10, 2016 at 10:23:53AM -0700, Sonny Rao wrote:
>> On Tue, Aug 9, 2016 at 2:01 PM, Robert Foss <robert.foss@collabora.com> wrote:
>> >
>> >
>> > On 2016-08-09 03:24 PM, Jann Horn wrote:
>> >>
>> >> On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.foss@collabora.com wrote:
>> >>>
>> >>> From: Sonny Rao <sonnyrao@chromium.org>
>> >>>
>> >>> This is based on earlier work by Thiago Goncales. It implements a new
>> >>> per process proc file which summarizes the contents of the smaps file
>> >>> but doesn't display any addresses.  It gives more detailed information
>> >>> than statm like the PSS (proprotional set size).  It differs from the
>> >>> original implementation in that it doesn't use the full blown set of
>> >>> seq operations, uses a different termination condition, and doesn't
>> >>> displayed "Locked" as that was broken on the original implemenation.
>> >>>
>> >>> This new proc file provides information faster than parsing the
>> >>> potentially
>> >>> huge smaps file.
>> >>>
>> >>> Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
>> >>>
>> >>> Tested-by: Robert Foss <robert.foss@collabora.com>
>> >>> Signed-off-by: Robert Foss <robert.foss@collabora.com>
>> >>
>> >>
>> >>
>> >>> +static int totmaps_proc_show(struct seq_file *m, void *data)
>> >>> +{
>> >>> +       struct proc_maps_private *priv = m->private;
>> >>> +       struct mm_struct *mm;
>> >>> +       struct vm_area_struct *vma;
>> >>> +       struct mem_size_stats *mss_sum = priv->mss;
>> >>> +
>> >>> +       /* reference to priv->task already taken */
>> >>> +       /* but need to get the mm here because */
>> >>> +       /* task could be in the process of exiting */
>> >>
>> >>
>> >> Can you please elaborate on this? My understanding here is that you
>> >> intend for the caller to be able to repeatedly read the same totmaps
>> >> file with pread() and still see updated information after the target
>> >> process has called execve() and be able to detect process death
>> >> (instead of simply seeing stale values). Is that accurate?
>> >>
>> >> I would prefer it if you could grab a reference to the mm_struct
>> >> directly at open time.
>> >
>> >
>> > Sonny, do you know more about the above comment?
>>
>> I think right now the file gets re-opened every time, but the mode
>> where the file is opened once and repeatedly read is interesting
>> because it avoids having to open the file again and again.
>>
>> I guess you could end up with a wierd situation where you don't read
>> the entire contents of the file in open call to read() and you might
>> get inconsistent data across the different statistics?
>
> If the file is read in two chunks, totmaps_proc_show is only called
> once. The patch specifies seq_read as read handler. Have a look at its
> definition. As long as you don't read from the same seq file in
> parallel or seek around in it, simple sequential reads will not
> re-invoke the show() method for data that has already been formatted.
> For partially consumed data, the kernel buffers the rest until someone
> reads it or seeks to another offset.

Ok that's good.  If the consumer were using pread() though, would that
look like a seek?