From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934321AbcHJSWt (ORCPT ); Wed, 10 Aug 2016 14:22:49 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:43402 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934116AbcHJSWr (ORCPT ); Wed, 10 Aug 2016 14:22:47 -0400 Subject: Re: [PACTH v1] mm, proc: Implement /proc//totmaps To: Mateusz Guzik References: <1470758743-17685-1-git-send-email-robert.foss@collabora.com> <20160809162946.gznxgsgfzndinkay@mguzik> <8475f2bc-7375-08d6-9fa5-435cfbf763e8@collabora.com> <54a4277a-dbc8-0815-6fc8-d3c11d2a930c@collabora.com> <20160810154253.zcf2lmydewxifeat@mguzik> Cc: akpm@linux-foundation.org, keescook@chromium.org, viro@zeniv.linux.org.uk, gorcunov@openvz.org, john.stultz@linaro.org, plaguedbypenguins@gmail.com, sonnyrao@chromium.org, adobriyan@gmail.com, jdanis@google.com, calvinowens@fb.com, jann@thejh.net, mhocko@suse.com, koct9i@gmail.com, vbabka@suse.cz, n-horiguchi@ah.jp.nec.com, kirill.shutemov@linux.intel.com, ldufour@linux.vnet.ibm.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, Ben Zhang , Bryan Freed , Filipe Brandenburger From: Robert Foss Message-ID: <940e10e8-248a-ea94-32cc-8f75ed39a92c@collabora.com> Date: Wed, 10 Aug 2016 11:50:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160810154253.zcf2lmydewxifeat@mguzik> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-08-10 11:42 AM, Mateusz Guzik wrote: > On Wed, Aug 10, 2016 at 11:39:12AM -0400, Robert Foss wrote: >> >> >> On 2016-08-09 04:17 PM, Robert Foss wrote: >>>>> +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 */ >>>>> + mm = get_task_mm(priv->task); >>>>> + if (!mm || IS_ERR(mm)) >>>>> + return -EINVAL; >>>>> + >>>> >>>> That's not how it's done in smaps. >>> >>> Alright, I'll have to look into the difference between this approach and >>> the smaps one. >> >> >> I had a look at show_smaps(), and it's not entirely clear to me what the >> advantage of doing it show_smaps() way. >> >> mm = get_task_mm(priv->task) is needed to iterate through all of the >> mappings. Is there a preferable way of doing that? > > In the other part of the mail I stated smaps goes to proc_maps_open > which has: > priv->mm = proc_mem_open(inode, PTRACE_MODE_READ); > > This gives you stable access to mm and all needed permission checks. > > Then, in the read routine you can just: > if (!atomic_inc_not_zero(&mm->mm_users)) > goto thats_it; > > See smaps routines or e.g. environ_read. > Ah! I see what you mean now. Thanks for the clarification! Rob.