From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753228AbcD1RJW (ORCPT ); Thu, 28 Apr 2016 13:09:22 -0400 Received: from merlin.infradead.org ([205.233.59.134]:47223 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752286AbcD1RJV (ORCPT ); Thu, 28 Apr 2016 13:09:21 -0400 Date: Thu, 28 Apr 2016 19:09:02 +0200 From: Peter Zijlstra To: Alexander Shishkin Cc: Thomas Gleixner , x86@kernel.org, Borislav Petkov , Ingo Molnar , linux-kernel@vger.kernel.org, vince@deater.net, eranian@google.com, Arnaldo Carvalho de Melo , Mathieu Poirier Subject: Re: [PATCH v2 5/7] perf: Introduce address range filtering Message-ID: <20160428170902.GS3408@twins.programming.kicks-ass.net> References: <1461771888-10409-1-git-send-email-alexander.shishkin@linux.intel.com> <1461771888-10409-6-git-send-email-alexander.shishkin@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461771888-10409-6-git-send-email-alexander.shishkin@linux.intel.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 27, 2016 at 06:44:46PM +0300, Alexander Shishkin wrote: > +/* > + * In order to contain the amount of racy and tricky in the address filter > + * configuration management, it is a two part process: > + * > + * (p1) when userspace mappings change as a result of (1) or (2) or (3) below, > + * we update the addresses of corresponding vmas in > + * event::addr_filters_offs array and bump the event::addr_filters_gen; > + * (p2) when an event is scheduled in (pmu::add), it calls > + * perf_event_addr_filters_sync() which calls pmu::addr_filters_sync() > + * if the generation has changed since the previous call. > + * > + * If (p1) happens while the event is active, we restart it to force (p2). Tiny nit; restart only does ::stop(),::start(), which doesn't go through ::add(). > + * > + * (1) perf_addr_filters_apply(): adjusting filters' offsets based on > + * pre-existing mappings, called once when new filters arrive via SET_FILTER > + * ioctl; > + * (2) perf_addr_filters_adjust(): adjusting filters' offsets based on newly > + * registered mapping, called for every new mmap(), with mm::mmap_sem down > + * for reading; > + * (3) perf_event_addr_filters_exec(): clearing filters' offsets in the process > + * of exec. > + */ > +static unsigned long perf_addr_filter_apply(struct perf_addr_filter *filter, > + struct mm_struct *mm) > +{ > + struct vm_area_struct *vma; > + > + for (vma = mm->mmap; vma->vm_next; vma = vma->vm_next) { Doesn't this miss the very last vma? That is, I was expecting: for (vma = mm->mmap; vma; vma = vma->vm_next) { > + struct file *file = vma->vm_file; > + unsigned long off = vma->vm_pgoff << PAGE_SHIFT; > + unsigned long vma_size = vma->vm_end - vma->vm_start; > + > + if (!file) > + continue; > + > + if (!perf_addr_filter_match(filter, file, off, vma_size)) > + continue; > + > + return vma->vm_start; > + } > + > + return 0; > +}