From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5978C433E1 for ; Fri, 21 Aug 2020 07:24:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9E6F420732 for ; Fri, 21 Aug 2020 07:24:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E6F420732 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 32A388D0030; Fri, 21 Aug 2020 03:24:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DB328D0006; Fri, 21 Aug 2020 03:24:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CA1C8D0030; Fri, 21 Aug 2020 03:24:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0193.hostedemail.com [216.40.44.193]) by kanga.kvack.org (Postfix) with ESMTP id 0667C8D0006 for ; Fri, 21 Aug 2020 03:24:05 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B2668181AEF10 for ; Fri, 21 Aug 2020 07:24:04 +0000 (UTC) X-FDA: 77173736808.07.legs43_401199427037 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 29D9D1803F9B5 for ; Fri, 21 Aug 2020 07:24:04 +0000 (UTC) X-HE-Tag: legs43_401199427037 X-Filterd-Recvd-Size: 5902 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 07:24:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CA405AB55; Fri, 21 Aug 2020 07:24:29 +0000 (UTC) Date: Fri, 21 Aug 2020 09:24:00 +0200 From: Michal Hocko To: Sumit Semwal Cc: Colin Cross , Andrew Morton , Linux-MM , lkml , Alexey Dobriyan , Jonathan Corbet , Mauro Carvalho Chehab , Kees Cook , Alexey Gladkov , Matthew Wilcox , Jason Gunthorpe , "Kirill A . Shutemov" , Michel Lespinasse , Michal =?iso-8859-1?Q?Koutn=FD?= , Song Liu , Huang Ying , Vlastimil Babka , Yang Shi , chenqiwu , Mathieu Desnoyers , John Hubbard , Mike Christie , Bart Van Assche , Amit Pundir , Thomas Gleixner , Christian Brauner , Daniel Jordan , Adrian Reber , Nicolas Viennot , Al Viro , Thomas Cedeno , linux-fsdevel@vger.kernel.org, Pekka Enberg , Dave Hansen , Peter Zijlstra , Ingo Molnar , Oleg Nesterov , "Eric W. Biederman" , Jan Glauber , John Stultz , Rob Landley , Cyrill Gorcunov , "Serge E. Hallyn" , David Rientjes , Hugh Dickins , Mel Gorman , Robin Holt , Shaohua Li , Johannes Weiner , Minchan Kim Subject: Re: [PATCH v5 2/2] mm: add a field to store names for private anonymous memory Message-ID: <20200821072334.GB32537@dhcp22.suse.cz> References: <20200819141650.7462-1-sumit.semwal@linaro.org> <20200819141650.7462-3-sumit.semwal@linaro.org> <20200820075846.GA5033@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 29D9D1803F9B5 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri 21-08-20 08:51:57, Sumit Semwal wrote: > Hi Colin, > > On Fri, 21 Aug 2020 at 04:58, Colin Cross wrote: > > > > On Thu, Aug 20, 2020 at 12:58 AM Michal Hocko wrote: > > > > > > On Wed 19-08-20 19:46:50, Sumit Semwal wrote: > > > [...] > > > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > > > > index 5066b0251ed8..136fd3c3ad7b 100644 > > > > --- a/fs/proc/task_mmu.c > > > > +++ b/fs/proc/task_mmu.c > > > > @@ -97,6 +97,21 @@ unsigned long task_statm(struct mm_struct *mm, > > > > return mm->total_vm; > > > > } > > > > > > > > +static void seq_print_vma_name(struct seq_file *m, struct vm_area_struct *vma) > > > > +{ > > > > + struct mm_struct *mm = vma->vm_mm; > > > > + char anon_name[NAME_MAX + 1]; > > > > + int n; > > > > + > > > > + n = access_remote_vm(mm, (unsigned long)vma_anon_name(vma), > > > > + anon_name, NAME_MAX, 0); > > > > + if (n > 0) { > > > > + seq_puts(m, "[anon:"); > > > > + seq_write(m, anon_name, strnlen(anon_name, n)); > > > > + seq_putc(m, ']'); > > > > + } > > > > +} > > > > + > > > > #ifdef CONFIG_NUMA > > > > /* > > > > * Save get_task_policy() for show_numa_map(). > > > > @@ -319,8 +334,15 @@ show_map_vma(struct seq_file *m, struct vm_area_struct *vma) > > > > goto done; > > > > } > > > > > > > > - if (is_stack(vma)) > > > > + if (is_stack(vma)) { > > > > name = "[stack]"; > > > > + goto done; > > > > + } > > > > + > > > > + if (vma_anon_name(vma)) { > > > > + seq_pad(m, ' '); > > > > + seq_print_vma_name(m, vma); > > > > + } > > > > } > > > > > > How can be this safe? access_remote_vm requires mmap_sem (non exlusive). > > > The same is the case for show_map_vma. So what would happen if a task > > > sets its own name? IIRC semaphore code doesn't allow read lock nesting > > > because any exclusive lock request in the mean time would block further > > > readers. Or is this allowed? > > > > Good catch. The version of this patch that has been in use the > > Android kernel since 2015 [1] doesn't have this issue because it > > doesn't use access_remote_vm, it calls get_user_pages_remote directly. > > This would need to call a version of access_remote_vm that assumes the > > mmap_sem is already held. > > Indeed. so does it sound ok to add an access_remote_vma_mmap_lockheld() version? You will still need to take the lock if the pointer belongs to a remote address space. But how are you going to find out? -- Michal Hocko SUSE Labs