Received: by 10.192.165.156 with SMTP id m28csp1292968imm; Wed, 18 Apr 2018 07:26:29 -0700 (PDT) X-Google-Smtp-Source: AIpwx49vkwlBCLRg9JCUZOi4tl2u76nZmDIgTYO5IfdMWfoXzVmdohJbcbxtrFPVp2X+2lYwhox9 X-Received: by 2002:a17:902:b604:: with SMTP id b4-v6mr2322091pls.109.1524061589359; Wed, 18 Apr 2018 07:26:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524061589; cv=none; d=google.com; s=arc-20160816; b=PqjGHGxYliN8UpmqIGIO5L3xQFe8dh4ZA96Ce9MrpKvUt3gsf2edu57RQi51BxtUEx 6Yg6afNt0BL4QEOBRuiXZT1niHLQpnC22iWl2yIVSZtZZrOXuaVbVxGGcZLPinj8Xcgb f3HQhQEY+DnSMMQBDh6HkwhiOUK6h3EYOfnaCo4FmMvLeu0gpnMm8LibWDEpxa7eBnnx iClmDVFS1gFOdCcXSXXDE2bxwijE8mH/3Jps6tJX7THtNcFnx8r/LD85AeFUNFl2JW7d I4uuFuq6iURxGcwiU+gjILvnNE5tyN9pXwmYkzaG/BrcC0gfO/pyxaOErMBQ2apy7NGp R5JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=Qk9k50h6DJp6hjT09gZBTH6y5avxI8lBYcCfBjwhAH8=; b=er0T30F0i216cDIhbc9GREvoeroHM5jSpNEluXzSg4fwdU3JdD1ZSZBBl4dtUGrjsy bXY51XA297+X3kRZcmyHgbQFMJrz1xHVaCSJcesZRmQyebsYHmS9Yae07ENVMVpwLfOD JiUSuJA8l+2wu/Ng1I2OGO0Pha45EoLcpob3SyskqUPlluqxZldtYNrcL0XdF2yNoNDY nahNDviw0iuee7JHEHNAXe6ZAqQFra0sqkSvuexjSVJNfj2IAZGgL+S7iXHeU8XMR1Ae yPNrO+rTiGCftwtbGaVTACNZB2w7egSpSzrJ991lemt6YLUD+e9P/gHTnTwEiclWBKJ8 kivA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v66si1232510pfd.341.2018.04.18.07.26.14; Wed, 18 Apr 2018 07:26:29 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753696AbeDROZJ (ORCPT + 99 others); Wed, 18 Apr 2018 10:25:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:38948 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752659AbeDROZI (ORCPT ); Wed, 18 Apr 2018 10:25:08 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF394204EF; Wed, 18 Apr 2018 14:25:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF394204EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 18 Apr 2018 10:25:04 -0400 From: Steven Rostedt To: Miklos Szeredi Cc: Song Liu , LKML , kernel-team , Ingo Molnar , Howard McLauchlan , Josef Bacik , Srikar Dronamraju Subject: Re: [PATCH 1/2] tracing: fix bad use of igrab in trace_uprobe.c Message-ID: <20180418102504.7673a7f3@gandalf.local.home> In-Reply-To: References: <20180418062907.3210386-1-songliubraving@fb.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 Apr 2018 16:03:42 +0200 Miklos Szeredi wrote: > > @@ -937,7 +928,8 @@ probe_event_enable(struct trace_uprobe *tu, struct trace_event_file *file, > > goto err_flags; > > > > tu->consumer.filter = filter; > > - ret = uprobe_register(tu->inode, tu->offset, &tu->consumer); > > + ret = uprobe_register(d_inode(tu->path.dentry), tu->offset, > > + &tu->consumer); > > It is not entirely clear how the lifetime of uprobe relates to the > lifetime of trace_uprobe. Is the uprobe object never going to survive > its creator trace_uprobe object? Not exactly sure what you mean here. The trace_uprobe (the probe event) is created, it doesn't do anything until it is enabled. This function is called when it is enabled. The trace_uprobe (probe event) can not be deleted while it is enabled (EBUSY). Are you asking what happens if the file is deleted while it has probe? That I don't know about (haven't tried it out). But I would hope that it keeps a reference to the inode, isn't that what the igrab is for? And is now being replaced by a reference on the path, or is that the problem? -- Steve > > If that's the case, it warrants a comment. If that's not the case, > then the path would need to be passed to uprobe_resister() which would > need to obtain its own reference. > > > if (ret) > > goto err_buffer; > >