Received: by 10.213.65.68 with SMTP id h4csp539886imn; Fri, 16 Mar 2018 10:52:00 -0700 (PDT) X-Google-Smtp-Source: AG47ELuKR4e4qx5QuX6nEXtB0HHbBpo4dpdTkcfjBqegtR6gfK/y0givepYIGV/TyUXzo4DuRuZF X-Received: by 10.99.143.3 with SMTP id n3mr2118596pgd.159.1521222720729; Fri, 16 Mar 2018 10:52:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521222720; cv=none; d=google.com; s=arc-20160816; b=j4V5mzHJGzAB1WMHx2AcXIJ0HPe5BLwYVzghU2Aufzm8rHFLtTsIXdlnSjx0uZs7MN ek8btndTHQstdr1iR/+4njtFUSJUr3yYRJSoShlc68oxFJM+0CiPwhFALrz1HsIAYq1v on0pT7aqGG9C+YYJMQ1gC3y3V1JLkt+CJmzVhso1ciEzkw8iyun/Q/YNMBfMIt0I2164 iexffQ40RIyshyAE9sj1NWn+OhBsFxeIJsvfw0IpEee0GiLOlun/BlwHJj0O22HM586n bxYmMv0vdAIv5q4l1xM1Q4SBlDIO76KRBh63Ex0B3kv+DWrBwPuiOmCfqrgxWbkJKDgB ekwQ== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=G49CLIrvhU/L2R75PTWrJILQu3VW3lWD0CCBRbmrR3E=; b=vXREtwA4icpKE9zZqsDVydSEEyWtU8HMSkR2sLFro3vDfuDfwCzFEhiQ80xy93QWwA 2S6nECWGQqffUB2w2VVnIctob2Ipz9cNAUl3goWRhfSRkmo4wV8aDdiG4e555FQ69A+d /ysUoLpDvmTf3S3M3L7wFV/vCJd84jP6sbl20eNzN+ydlx5wfuv5fAw0KqIgMw8yCx40 4Bhb/h2W+Rpo/qnm5DWOZjIqUtXweSz1xJ5QEYPzp6TpvmH1RsC7+ZBnzZSd3RT/nCc7 GS7QCtyEFMu5AiVZWYsSk2JkqP2gDCQCO3sS5/nLZxTvkbKGSzhxg8Z9RNJuC8tNDId9 x+Dw== 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 n8si85032pgt.480.2018.03.16.10.51.42; Fri, 16 Mar 2018 10:52:00 -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 S1751665AbeCPRuj (ORCPT + 99 others); Fri, 16 Mar 2018 13:50:39 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:32860 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751454AbeCPRuh (ORCPT ); Fri, 16 Mar 2018 13:50:37 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 912F481A8123; Fri, 16 Mar 2018 17:50:36 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.34.27.30]) by smtp.corp.redhat.com (Postfix) with SMTP id 76503202322B; Fri, 16 Mar 2018 17:50:31 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Fri, 16 Mar 2018 18:50:36 +0100 (CET) Date: Fri, 16 Mar 2018 18:50:30 +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: <20180316175030.GA28770@redhat.com> References: <20180313125603.19819-1-ravi.bangoria@linux.vnet.ibm.com> <20180313125603.19819-7-ravi.bangoria@linux.vnet.ibm.com> <20180315144959.GB19643@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 16 Mar 2018 17:50:36 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 16 Mar 2018 17:50:36 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.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/16, Ravi Bangoria wrote: > > On 03/15/2018 08:19 PM, Oleg Nesterov wrote: > > 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? ... > ??? # strace -o out python > ?? ?? mmap(NULL, 2738968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fff92460000 > ????? mmap(0x7fff926a0000, 327680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x230000) = 0x7fff926a0000 > ????? mprotect(0x7fff926a0000, 65536, PROT_READ) = 0 Ah, in this case everything is clear, thanks. I was confused by the changelog, I misinterpreted it as if inc/dec are not balanced in case of multiple mappings even if the application doesn't play with mmap/mprotect/etc. And it seems that you are trying to confuse yourself, not only me ;) Just suppose that an application does mmap+munmap in a loop and the mapped region contains uprobe but not the counter. And this all makes me think that we should do something else. Ideally, install_breakpoint() and remove_breakpoint() should inc/dec the counter if they do not fail... Btw, why do we need a counter, not a boolean? Who else can modify it? Or different uprobes can share the same counter? Oleg.