Received: by 10.213.65.68 with SMTP id h4csp2269imn; Thu, 15 Mar 2018 07:53:23 -0700 (PDT) X-Google-Smtp-Source: AG47ELtc5rF029l7ekVLVYwOdEoDIEOvItIR4bLCv8olk4HktatXaAL6uMTHN/OKm8D7erDQhSR1 X-Received: by 10.99.191.8 with SMTP id v8mr2351612pgf.1.1521125603061; Thu, 15 Mar 2018 07:53:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521125603; cv=none; d=google.com; s=arc-20160816; b=h0J9IgSh6rmBbwEhp9D/UGoJV86BNUgksBIXZOCEiH9QHCG1O4t0x9YRxFObdSKz+u Vcg89doPJVseat/AJ8VrDGU5/XvnUubgi1dq0e0ESXHsbVfAqKTViD4UfAtHkKKiO7k6 g5P6G9JBT8aI/NYSUeDBAgsDJylOplvPviCyU44aFefKI85KKJ0rLWXxZWl4rGOnWAnw Cuglpm6KgufJedqwb85C1nldeUWvpOLsiFNtLEciykf5IkOMNqQ5OYwYATlhyYKoL9V5 9jKLmaLsd1ceV8UnB7QDjFxEBkBwBIGSt71CunxrC0kHi6FyaChMurTSLKgmnGg9dRAC G74Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=1H8im1OpeqPk6h5mGk5SkVA3NnKhJFl1d4Ih8YtORWE=; b=wlubEYopuIKYMcLMIdzZQakPkK+P0cH9P6EGoBaeyDBD/25aZcapCesHvpdm6a2eu0 3V/qH5mTQUaJZIUf+t+jOiu+vuMJ6vGRm+w6SO00XadCmOFF2hVuKe3U79U8oq7wd5Fq jN5dAwUz8FvRzvBvkYKRjLmSYlgdY5iapc17Jkf/MrXQJaUFn0jGsMhiO1bK7CyXEWKY jogLNnJcMsOoIub0etYEPF4M92lVlOrbkIyVc1B6wRDYC3BTl5x60nTJlrbGNRoqZyl7 TTBxMIl/60zCpoy1uIvnEAKXltBJfhXfmsfkNKN189tm6grLNklxFlD5GRMvYm1BwuVu 7W2g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bj8-v6si2615859plb.306.2018.03.15.07.53.01; Thu, 15 Mar 2018 07:53:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932488AbeCOOuI (ORCPT + 99 others); Thu, 15 Mar 2018 10:50:08 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43468 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752633AbeCOOuG (ORCPT ); Thu, 15 Mar 2018 10:50:06 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2B9AEEAEB3; Thu, 15 Mar 2018 14:50:05 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.34.27.30]) by smtp.corp.redhat.com (Postfix) with SMTP id 52E0F215CDAF; Thu, 15 Mar 2018 14:50:00 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Thu, 15 Mar 2018 15:50:04 +0100 (CET) Date: Thu, 15 Mar 2018 15:49:59 +0100 From: Oleg Nesterov To: Ravi Bangoria Cc: mhiramat@kernel.org, peterz@infradead.org, srikar@linux.vnet.ibm.com, acme@kernel.org, ananth@linux.vnet.ibm.com, akpm@linux-foundation.org, alexander.shishkin@linux.intel.com, alexis.berlemont@gmail.com, corbet@lwn.net, dan.j.williams@intel.com, gregkh@linuxfoundation.org, huawei.libin@huawei.com, hughd@google.com, jack@suse.cz, jglisse@redhat.com, jolsa@redhat.com, kan.liang@intel.com, kirill.shutemov@linux.intel.com, kjlx@templeofstupid.com, kstewart@linuxfoundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, milian.wolff@kdab.com, mingo@redhat.com, namhyung@kernel.org, naveen.n.rao@linux.vnet.ibm.com, pc@us.ibm.com, pombredanne@nexb.com, rostedt@goodmis.org, tglx@linutronix.de, tmricht@linux.vnet.ibm.com, willy@infradead.org, yao.jin@linux.intel.com, fengguang.wu@intel.com Subject: Re: [PATCH 6/8] trace_uprobe/sdt: Fix multiple update of same reference counter Message-ID: <20180315144959.GB19643@redhat.com> References: <20180313125603.19819-1-ravi.bangoria@linux.vnet.ibm.com> <20180313125603.19819-7-ravi.bangoria@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180313125603.19819-7-ravi.bangoria@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 15 Mar 2018 14:50:05 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 15 Mar 2018 14:50:05 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'oleg@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/13, Ravi Bangoria wrote: > > For tiny binaries/libraries, different mmap regions points to the > same file portion. In such cases, we may increment reference counter > multiple times. Yes, > But while de-registration, reference counter will get > decremented only by once could you explain why this happens? sdt_increment_ref_ctr() and sdt_decrement_ref_ctr() look symmetrical, _decrement_ should see the same mappings? Ether way, this patch doesn't look right at first glance... Just for example, > +static bool sdt_check_mm_list(struct trace_uprobe *tu, struct mm_struct *mm) > +{ > + struct sdt_mm_list *tmp = tu->sml; > + > + if (!tu->sml || !mm) > + return false; > + > + while (tmp) { > + if (tmp->mm == mm) > + return true; > + tmp = tmp->next; > + } > + > + return false; ... > +} > + > +static void sdt_add_mm_list(struct trace_uprobe *tu, struct mm_struct *mm) > +{ > + struct sdt_mm_list *tmp; > + > + tmp = kzalloc(sizeof(*tmp), GFP_KERNEL); > + if (!tmp) > + return; > + > + tmp->mm = mm; > + tmp->next = tu->sml; > + tu->sml = tmp; > +} > + ... > @@ -1020,8 +1104,16 @@ void trace_uprobe_mmap_callback(struct vm_area_struct *vma) > !trace_probe_is_enabled(&tu->tp)) > continue; > > + down_write(&tu->sml_rw_sem); > + if (sdt_check_mm_list(tu, vma->vm_mm)) > + goto cont; > + > vaddr = vma_offset_to_vaddr(vma, tu->ref_ctr_offset); > - sdt_update_ref_ctr(vma->vm_mm, vaddr, 1); > + if (!sdt_update_ref_ctr(vma->vm_mm, vaddr, 1)) > + sdt_add_mm_list(tu, vma->vm_mm); > + > +cont: > + up_write(&tu->sml_rw_sem); To simplify, suppose that tu->sml is empty. Some process calls this function, increments the counter and adds its ->mm into the list. Then it exits, ->mm is freed. The next fork/exec allocates the same memory for the new ->mm, the new process calls trace_uprobe_mmap_callback() and sdt_check_mm_list() returns T? Oleg.