Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3278996pxj; Mon, 7 Jun 2021 06:57:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsxeUL9jzv78ZnQibZwHozgKVAMtAJzx4uXlA/YJYEACFLFPvv3LCUGlar9A6ryIBAoh+C X-Received: by 2002:aa7:d388:: with SMTP id x8mr19736865edq.338.1623074221581; Mon, 07 Jun 2021 06:57:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623074221; cv=none; d=google.com; s=arc-20160816; b=W6UjorPJ4XFmHXhhtAl7Lx18o9/R1QzAfIboikJKk1g8uY3PcSOAtFDtDnhvkd2tud a3gLQ5W2ZttAIKNstEiyuod+UOlLz8eRBLC0tLyTBkB2ZiRYAfaZCXtmj2doEWRMy2Bn x4IzmRNNGDuspVIPQoyJQ5yj50sMC7Kia4JDOLNgLU6VrwXVHZwAn3XWUxc4JXjUND3p /FQWnN0PnYT0Na86dtHZW9TnuOb4bGUJGAmivTat81C+SsAbP1SsdrjJ/PKInDJLgaf0 9dzBoOH1RBQmOJfj3lc0Yqjb4xg+1rX+VONvITRxW4RNqxNriUZbmFQD9JtI3A5CsW3G 0kMA== 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:date; bh=SBHj+XsLVvK4cKjj7IzGHIan0f68oYytjTjB9Pjmti4=; b=z08hGKdS0rxsnCa5JO2x+oTrXEuMFMSaxrxWCJkgO+PfWAo8kADghj/PZSJR7ZsmkZ 6EfrPbmKxx+d7TVa15lSYzidUF+/EkQTuHOyHy4+N2WKRcXAEt+/POMa+rEcZO4iw/hq dWNmzcGSV7UwqSgdSxokaCSvLsed6p5QxaabheOZBF6d61oE7D2gjyeh33H+vzJF8D9m WzCxhXZ+8ithqYvouhF6cotI4CzUwZnP0sNKmM0nhsfU9VrXcvKF74Wy34fwQte/wRNv Q/sIeLggLLV5gXQZgIjf+6IbF0v4zbybYjYhFiOFZp/1WMS49XzgbrRxmC5M0B5PvwPm 8x2g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lx17si12736198ejb.539.2021.06.07.06.56.38; Mon, 07 Jun 2021 06:57:01 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230233AbhFGN5N (ORCPT + 99 others); Mon, 7 Jun 2021 09:57:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:59184 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230211AbhFGN5M (ORCPT ); Mon, 7 Jun 2021 09:57:12 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 62BFB610FB; Mon, 7 Jun 2021 13:55:20 +0000 (UTC) Date: Mon, 7 Jun 2021 09:55:18 -0400 From: Steven Rostedt To: Mark-PK Tsai Cc: Ingo Molnar , Catalin Marinas , Will Deacon , Matthias Brugger , , , , Subject: Re: [PATCH] arm64: ftrace: don't dereference a probably invalid address Message-ID: <20210607095518.12694437@oasis.local.home> In-Reply-To: <20210607032329.28671-1-mark-pk.tsai@mediatek.com> References: <20210607032329.28671-1-mark-pk.tsai@mediatek.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.33; 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, 7 Jun 2021 11:23:30 +0800 Mark-PK Tsai wrote: > Address in __mcount_loc may be invalid if somthing goes wrong. > On our arm64 platform, the bug in recordmcount make kernel > crash in ftrace_init(). How did it crash? The link below doesn't show any crash. > > https://lore.kernel.org/lkml/20210607023839.26387-1-mark-pk.tsai@mediatek.com/ > > Return -EFAULT if we are dealing with out-of-range condition > to prevent dereference the invalid address in ftrace_bug(), > then the kernel can disable ftrace safely for problematic > __mcount_loc. !mod is not an out-of-range condition. It just happened that the other bug caused this strange side-effect. A !mod does not mean a fault happened. Just because it may have been caused by a fault in your use case does not mean that it's a fault in all use cases. That's like saying that your dog is a poodle, so all dogs are poodles. A return of -EINVAL should not cause a crash. If it does, then that needs to be fixed. -- Steve > > Signed-off-by: Mark-PK Tsai > --- > arch/arm64/kernel/ftrace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c > index b5d3ddaf69d9..98bec8445a58 100644 > --- a/arch/arm64/kernel/ftrace.c > +++ b/arch/arm64/kernel/ftrace.c > @@ -201,7 +201,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec, > preempt_enable(); > > if (WARN_ON(!mod)) > - return -EINVAL; > + return -EFAULT; > } > > /*