Received: by 2002:ab2:3350:0:b0:1f4:6588:b3a7 with SMTP id o16csp1107079lqe; Sun, 7 Apr 2024 20:29:15 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXmComHyqwdleL+0kuJycOa3RCthXtD9J3E2hKQiYcvJY+heOzPsX0uSG2/TaNpd8GaL8jnvm5qwdibpAiFTurL0KFa1xDB40pV+KvpDA== X-Google-Smtp-Source: AGHT+IG4ENr790Uqdk7be6expFHqxdsSvX7SsYsEa/rHEEVH6hb8LWbWXMWpdeM4RLFETrHVLv0i X-Received: by 2002:a05:620a:4692:b0:78d:5d7c:9896 with SMTP id bq18-20020a05620a469200b0078d5d7c9896mr7528887qkb.36.1712546955712; Sun, 07 Apr 2024 20:29:15 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712546955; cv=pass; d=google.com; s=arc-20160816; b=wGDzf/9lW/8KQv+4c5Xx0RrBLJPfk+7wfI7B5rhpmh+bTILcdJ0zXpEKoaJWFZ6nW6 trVhbzPPM6XFC68ZoUbEb7yDlbY6o4roE/pOi+/AT2EfxFMhq9VoLfBboUWORY2NiMw6 Oh2GUBQ3F3zBMg69SXiBr+iJzwuYHlkRMvDe4JijSwAHTgXtSXRYOCzabDT45/2i8aKF 1sdfU+fglGwJsfwfP1RJzKUuRvIgG5ZmIul6bHnNTkIBdJW6vdI7Fu26nklyBO5xgMSG +m9gGpE7Yzj+/aTqLbXXb17jKppgagLM5U2NW3f+EuSSHzasOqYx1zC2huJwZNFImjZ7 fJ1w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=1HyQKZz13yqurHGDM/plcPbhEDMhOKKylfa2fu6EqJ4=; fh=eMMljrMqJ1PBkYvqw0qxOj+GZzTK050FPPirWsSc/Og=; b=tJpRw4runrcA8zdRwjw7Tens0YRa8MOYz0lJZcoA3IR51+YOT/UrvSrQSWbjB0fSmE KaxeENnQ0I15oaeNGsjgJ2NA6TaAH95t6k9waXJZ3ud4oGiS/DntKOkiOjc7oALTPHCK Pz7lm2oWAJI4Bd8zrD3Pad8WmeAXEmi0wEsH7cpXtML3AbNVj5H88W3HU1a5M6AbNcB5 WI1TXumRQ8Ksb16Unc4UIhNTeWw+AeyIsEFhLU3VWv3m8/pbdVvPOrDI+k8UpRJHsrzG y2sGJfwBqGaoNw+uktvYEy8Lfd1o2Ko55h2zVUqBePH1f6nmu7VzbBCezNHp/Ymcc8BB A6Ow==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-134753-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-134753-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id ec26-20020a05622a5b9a00b00434b716e318si139223qtb.485.2024.04.07.20.29.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Apr 2024 20:29:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-134753-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-134753-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-134753-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 7278E1C2095F for ; Mon, 8 Apr 2024 03:29:15 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9DFD61C3E; Mon, 8 Apr 2024 03:29:10 +0000 (UTC) Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 985831860; Mon, 8 Apr 2024 03:29:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.32 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712546950; cv=none; b=UU5+J9zirklsT3VhzkZN+13+XPkQ4htZmYzJawrJn3iLHCgaXDnZZuxrxIArAS26b0y8IMr2A3Cjd90oV30pINir7iEQNqMta/NMomJBACHA4IfcjIJA+juQW3WlCO3TyvwXTq6QyBc6/ZKm7f2WFH1P9xh62T5MyAce8oVoIAg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712546950; c=relaxed/simple; bh=lxXWSdVbvt7G6rco2TqN9WSRsNT27Sr3Ycoc2phECj0=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=q64NR9p+vpI5ixEwWwLO89rAZZHpUvWGYGk+BItSeUz2+ha+TWPJaIyU9INCpNarGH3B/ChlGM2fhsE0/Igm3fefBfb9dc+1H1s8OqeC1KYFtaKCjPSkpkjVupgwbkTVizSV55shIUeQONYmDRP5TGfx39OLg50svy3+GGy/svo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4VCZL25kvdz21kcw; Mon, 8 Apr 2024 11:28:10 +0800 (CST) Received: from dggpeml500012.china.huawei.com (unknown [7.185.36.15]) by mail.maildlp.com (Postfix) with ESMTPS id 3E5CB1401E0; Mon, 8 Apr 2024 11:29:05 +0800 (CST) Received: from [10.67.111.172] (10.67.111.172) by dggpeml500012.china.huawei.com (7.185.36.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 8 Apr 2024 11:29:04 +0800 Message-ID: Date: Mon, 8 Apr 2024 11:29:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH] kprobes: Fix possible warn in __arm_kprobe_ftrace() Content-Language: en-US To: "Masami Hiramatsu (Google)" CC: , , , , References: <20240407035904.2556645-1-zhengyejian1@huawei.com> <20240408115038.b0c85767bf1f249eccc32fff@kernel.org> From: Zheng Yejian In-Reply-To: <20240408115038.b0c85767bf1f249eccc32fff@kernel.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpeml500012.china.huawei.com (7.185.36.15) On 2024/4/8 10:50, Masami Hiramatsu (Google) wrote: > On Sun, 7 Apr 2024 11:59:04 +0800 > Zheng Yejian wrote: > >> There is once warn in __arm_kprobe_ftrace() on: >> >> ret = ftrace_set_filter_ip(ops, (unsigned long)p->addr, 0, 0); >> if (WARN_ONCE(..., "Failed to arm kprobe-ftrace at %pS (error %d)\n", ...) >> return ret; >> >> This warning is due to 'p->addr' is not a valid ftrace_location and >> that invalid 'p->addr' was bypassed in check_kprobe_address_safe(): > > Ah, this is a guard warning to detect changes on ftrace_set_filter() and/or > preparation steps. (A kind of debug message.) > The ftrace address check is done by check_ftrace_location() at the beginning of > check_kprobe_address_safe(). At that point, ftrace_location(addr) == addr should > return true if the module is loaded. But there is a small window that we check > the ftrace_location() and get the module refcount, even if the "addr" was ftrace > location, the module is unloaded and failed to get the module refcount and fail > to register the kprobe. Thanks, I'll complete the description in V2. > >> check_kprobe_address_safe() { >> ... >> // 1. p->addr is in some module, this check passed >> is_module_text_address((unsigned long) p->addr) >> ... >> // 2. If the moudle is removed, the *probed_mod is NULL, but then >> // the return value would still be 0 !!! >> *probed_mod = __module_text_address((unsigned long) p->addr); >> ... >> } >> >> So adjust the module text check to fix it. > > This seems just optimizing code (skip the 2nd module search), right? Yes, optimze more than fix, but this can still avoid latter warn like in __arm_kprobe_ftrace() > Also some comments needs to be updated. Will do in V2. > >> >> Signed-off-by: Zheng Yejian >> --- >> kernel/kprobes.c | 13 +++++++++---- >> 1 file changed, 9 insertions(+), 4 deletions(-) >> >> diff --git a/kernel/kprobes.c b/kernel/kprobes.c >> index 9d9095e81792..e0612cc3e2a3 100644 >> --- a/kernel/kprobes.c >> +++ b/kernel/kprobes.c >> @@ -1567,10 +1567,16 @@ static int check_kprobe_address_safe(struct kprobe *p, >> jump_label_lock(); >> preempt_disable(); >> > > /* Ensure the address is in a text area, and find a module if exists. */ > >> + *probed_mod = NULL; >> + if (!core_kernel_text((unsigned long) p->addr)) { >> + *probed_mod = __module_text_address((unsigned long) p->addr); >> + if (!(*probed_mod)) { >> + ret = -EINVAL; >> + goto out; >> + } > > nit: this should get the module refcount soon after getting probed_mod. > (I think this should be an atomic operation, but we don't have such interface.) Yes, it's better to get the module refcount right here, but suppose the module is expected to be unloaded soon, we don't really need to make the registration succeed. > >> + } > >> /* Ensure it is not in reserved area nor out of text */ > > /* Ensure it is not in reserved area. */ > >> - if (!(core_kernel_text((unsigned long) p->addr) || >> - is_module_text_address((unsigned long) p->addr)) || > > Note that this part is doing same thing. If the probe address is !kernel_text > and !module_text, it will be rejected. > Yes. >> - in_gate_area_no_mm((unsigned long) p->addr) || >> + if (in_gate_area_no_mm((unsigned long) p->addr) || >> within_kprobe_blacklist((unsigned long) p->addr) || >> jump_label_text_reserved(p->addr, p->addr) || >> static_call_text_reserved(p->addr, p->addr) || >> @@ -1581,7 +1587,6 @@ static int check_kprobe_address_safe(struct kprobe *p, >> } >> >> /* Check if 'p' is probing a module. */ > > /* Get module refcount and reject __init functions for loaded modules. */ > >> - *probed_mod = __module_text_address((unsigned long) p->addr); >> if (*probed_mod) { >> /* >> * We must hold a refcount of the probed module while updating >> -- >> 2.25.1 >> > > Thank you, > -- Thank you, Zheng Yejian