Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp444289pxu; Tue, 1 Dec 2020 15:37:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyNq4Car6qKevmMuH0kix8trMLhGFPe6ip45veQb+ASUxA3id9lFYOuY0h0/yX9bZmHgjTh X-Received: by 2002:a50:cd08:: with SMTP id z8mr9493edi.256.1606865842743; Tue, 01 Dec 2020 15:37:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606865842; cv=none; d=google.com; s=arc-20160816; b=t7LxO/Lp0Yg7VoO98xg5iLiq05TDdph37PcejB5gUdrdfcrZgspOAWZsHSZxmUAh0h rR5fCEylAXHoMapeG9odHrukOMrWGmLFtkBVUxRpZVw2l4sMuHKdt9fCn31prUuAFS82 0Bddu5nQOHYYX4NrCfjoZpgmtZ/IzbIG+GhHLHtG98qCbMq1Hi+H97Ofuw6HVNx8HcgR NBfAxFPnvlzgpwIvqrxeE4Eo8D8uHrOazE8PF5uZautncC9N25Q6NqgRCqLKi9GrDPPG c2CcYhrBVcJvq8Ez9dTjINpReIWJljiKDF7cM9zvk75Q7DgYLuJOWLtnYSwZgZjX1BE2 oNdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:dkim-signature :date; bh=ZkDFQjLNbfMTm0OcflvpHOax6Iw7jFNWP7nd0SdZTLk=; b=dUhm84NSX73JunQjv0akp1fKcnQENakKlVW8Nqbqoioxa1EwdEcvUHhIqHHNHFqFx4 FG2WebMWSN/5j4dppynAvLGAHEweBmRF3cS36BsGBsfX3k+m0jxjL6jiyzejz2UJgqFs 5OhlHlReq1IKzp5TN+OMD1X8HVinCmoOEgGvn8C6a1g+Ye9Oq19ugRWzf23SyeyvGFyB eRbIk2ZXrjIn8UJn7ijKY7wyQHT+rzmpjCwdVwIvblOFEIfICyRmRWNTy3HfEEs5I1jE phSsbZgziRNzRJrS9VaamCBEyocTxjDrqUtiMOR3NV4sp7oA2VV4q1nMbJXlFphwKZc5 JQ7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=e0g8qDNq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m17si924818ejq.464.2020.12.01.15.36.58; Tue, 01 Dec 2020 15:37:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=e0g8qDNq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727264AbgLAXdm (ORCPT + 99 others); Tue, 1 Dec 2020 18:33:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:50224 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726891AbgLAXdj (ORCPT ); Tue, 1 Dec 2020 18:33:39 -0500 Date: Wed, 2 Dec 2020 08:32:53 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606865578; bh=RjV/+djLvuKYAFobW56Ovd1Zp//PoPVTo3mRtOOeIX0=; h=From:To:Cc:Subject:In-Reply-To:References:From; b=e0g8qDNqfCmXG96P152wtio6CtzFbaIJJ25PYUN+JAXuaq+VVoGLwLJympieK3mKN RLZZZ9q/BR0Swzs3DA9ycfnAnn3gdsW/fOGO/dK0MYDVGgiTsByRYGqSmpnx/q0hXt nKffPhXuCuUInObTP4g0EL0RPP4kNmXK6NvUReNc= From: Masami Hiramatsu To: Steven Rostedt Cc: Wang ShaoBo , , , , , , Subject: Re: [PATCH] kretprobe: avoid re-registration of the same kretprobe earlier Message-Id: <20201202083253.9dbc76704149261e131345bf@kernel.org> In-Reply-To: <20201130161850.34bcfc8a@gandalf.local.home> References: <20201124115719.11799-1-bobo.shaobowang@huawei.com> <20201130161850.34bcfc8a@gandalf.local.home> X-Mailer: Sylpheed 3.7.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Nov 2020 16:18:50 -0500 Steven Rostedt wrote: > > Masami, > > Can you review this patch, and also, should this go to -rc and stable? > > -- Steve Thanks for ping me! > On Tue, 24 Nov 2020 19:57:19 +0800 > Wang ShaoBo wrote: > > > Our system encountered a re-init error when re-registering same kretprobe, > > where the kretprobe_instance in rp->free_instances is illegally accessed > > after re-init. Ah, OK. Anyway if re-register happens on kretprobe, it must lose instances on the list before checking re-register in register_kprobe(). So the idea looks good to me. > > Implementation to avoid re-registration has been introduced for kprobe > > before, but lags for register_kretprobe(). We must check if kprobe has > > been re-registered before re-initializing kretprobe, otherwise it will > > destroy the data struct of kretprobe registered, which can lead to memory > > leak, system crash, also some unexpected behaviors. > > > > we use check_kprobe_rereg() to check if kprobe has been re-registered > > before calling register_kretprobe(), for giving a warning message and > > terminate registration process. > > > > Signed-off-by: Wang ShaoBo > > Signed-off-by: Cheng Jian > > --- > > kernel/kprobes.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > > index 41fdbb7953c6..7f54a70136f3 100644 > > --- a/kernel/kprobes.c > > +++ b/kernel/kprobes.c > > @@ -2117,6 +2117,14 @@ int register_kretprobe(struct kretprobe *rp) > > } > > } > > > > + /* > > + * Return error if it's being re-registered, > > + * also give a warning message to the developer. > > + */ > > + ret = check_kprobe_rereg(&rp->kp); > > + if (WARN_ON(ret)) > > + return ret; If you call this here, you must make sure kprobe_addr() is called on rp->kp. But if kretprobe_blacklist_size == 0, kprobe_addr() is not called before this check. So it should be in between kprobe_on_func_entry() and kretprobe_blacklist_size check, like this if (!kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset)) return -EINVAL; addr = kprobe_addr(&rp->kp); if (IS_ERR(addr)) return PTR_ERR(addr); rp->kp.addr = addr; ret = check_kprobe_rereg(&rp->kp); if (WARN_ON(ret)) return ret; if (kretprobe_blacklist_size) { for (i = 0; > > + ret = check_kprobe_rereg(&rp->kp); Thank you, -- Masami Hiramatsu