Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3110533imw; Mon, 18 Jul 2022 02:15:32 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tII6TYiAxjI68WOOQ253AMz2JRbuNZXih7ks/MT4w+JoMD2u4hkDYyu6SW5FYRNlL7q9qa X-Received: by 2002:a17:907:9619:b0:72b:4761:be19 with SMTP id gb25-20020a170907961900b0072b4761be19mr26322828ejc.20.1658135732259; Mon, 18 Jul 2022 02:15:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658135732; cv=none; d=google.com; s=arc-20160816; b=gWquG9ItLPVjrf98E0pYkXVE2NdVcqY+GKMeNq8jFzOyqRpE62duU9NH7lsYMC1dzf ue41xGr7/eY9KgsRW+gaOyOweQWtgBYvhnUcXvShYxd8GwhqAnFBR1w3bxK8lt9+/WDj uqQE7AW5rDpOk3gJh5VKZiDOFAoW2LbycqTyc4jgMI3Xwdddf0SJZHwrT/Gr951HnOUe q7ym2ySCdg7wMjV31uP5dqIaBLPO7iViVFTG9v4Z6vRtpxjQ66PFp7/rD0xUV8EOBlOF X+GRigmwa47m5KAWz3E/qn4aqCync+Ls598Gs1LfBXvBdKglQRZba7r7lfES1inUnVDa 5z4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=9eJN+m0pEHtjJ1cyznLRwut5IHeAG8qD1A+Zq2Ji8RE=; b=QWi+ndbJhUa3/iNou1XngFFrvzx8/ggaQohASl995PfCbPG2l/c76Lqzgn3XZiCGP6 f0I2zBTiNTKkKCNrUageVg9dfKI7uSgFHIavGpeZXuL4N7QzcZZnWooHmIwvhCoy7M5v OucOYRB3To9/34CjyCigSAdOlFte5YTk+mu4At9Wro3K7V8BCS38KV6SlCB0DL7iU0Jh o1B5cCWLSO2X/6RH/5QB/kXgJFE4xS2GdvDb0wu3wHUpl7zEy2juI4v2IUPqo3revzwd SprjNsbQMI5y89+ZCy6+v0tRQ/W4y52lQ6NZucuOZSTRr96VZOcRjlLGvks7J7gZb7Xj 1Yiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=a28ILWIb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a5-20020a17090680c500b007269a156f59si8462926ejx.348.2022.07.18.02.15.07; Mon, 18 Jul 2022 02:15:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=a28ILWIb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234093AbiGRJH6 (ORCPT + 99 others); Mon, 18 Jul 2022 05:07:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234084AbiGRJH5 (ORCPT ); Mon, 18 Jul 2022 05:07:57 -0400 Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 710AC11810 for ; Mon, 18 Jul 2022 02:07:56 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id 64so19637126ybt.12 for ; Mon, 18 Jul 2022 02:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9eJN+m0pEHtjJ1cyznLRwut5IHeAG8qD1A+Zq2Ji8RE=; b=a28ILWIbndvvHjicaKV1NVvzz3vVS0NEL6I/oMvaX5/7dAEFb7NRO6NFh1gJmzRhjg S7cDPxX9yShHvrtd8+TZ51ZmL8uwlX5cRDVVaECNYg4D8Zbc62fQHXLhFrBJJENJ4v6u kzR43CopMtm1pqMP0OSbhlTtIlZMrv1/q0pq4PTIa0HKg+vNGOlV8pe7y+lydcP1vf8M U1ddaGUxm1eDRD+vr3PN2rZWBXhr6ch2fQsZvGk8zSjLTVFOt1HiSInkS4Z6GhHFQADs HNEiR0CGvpjp+HRQ2UCXxkm8OdgxA0xdMJSBynsOWBIx2M+10rZJe+KjZkKJTc6NjBYv 71jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9eJN+m0pEHtjJ1cyznLRwut5IHeAG8qD1A+Zq2Ji8RE=; b=57utpJeSeafh24iMbTFeIkDp24lNwHRAVdKe3CDSqL39hK7NIh0Jpqv+RdTV7nke2t IQa5/KhX8Ra1KRwFEy52my+cgppLOOli/QQJhbOQ2VriU1CikwWYJnsXiQniLshxnSAU cNxlJ8Dxe1a+q177axwm5NYW4vMjatSaeI7c54ePEpBaN2PnjfCUUsUhqYbKCBww8zZX h6czqhrLjmSy69cIs8HEcLe1vJIrM4c3gU/B7Cmt2rAQFfZjZf3dZn2pCKnq00C6PX9J gk8IAKUZ08wz3HpB8NsSCl0Y2K8HV1E48N007Add0wu82NMt+bX+a2Mo8mYbgO/+JwGU bhcA== X-Gm-Message-State: AJIora+rUiPp+42yh0Y2/G0o2/Ezrg0vQhxNzAzdwCfTKp2UV6e2rdeL thPXP2yoG89WRBa6l2KcYQjT4OmGCNc5/ww/mBpLPw== X-Received: by 2002:a25:f508:0:b0:66f:3c5f:c39f with SMTP id a8-20020a25f508000000b0066f3c5fc39fmr24891200ybe.374.1658135275708; Mon, 18 Jul 2022 02:07:55 -0700 (PDT) MIME-Version: 1.0 References: <20220712021527.109921-1-lihuafei1@huawei.com> <20220712021527.109921-4-lihuafei1@huawei.com> In-Reply-To: <20220712021527.109921-4-lihuafei1@huawei.com> From: Linus Walleij Date: Mon, 18 Jul 2022 11:07:43 +0200 Message-ID: Subject: Re: [PATCH 3/5] ARM: stacktrace: Allow stack trace saving for non-current tasks To: Li Huafei Cc: linux@armlinux.org.uk, rmk+kernel@armlinux.org.uk, ardb@kernel.org, will@kernel.org, mark.rutland@arm.com, broonie@kernel.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@kernel.org, namhyung@kernel.org, arnd@arndb.de, rostedt@goodmis.org, nick.hawkins@hpe.com, john@phrozen.org, mhiramat@kernel.org, ast@kernel.org, linyujun809@huawei.com, ndesaulniers@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 12, 2022 at 4:18 AM Li Huafei wrote: > The current ARM implementation of save_stack_trace_tsk() does not allow > saving stack trace for non-current tasks, which may limit the scenarios > in which stack_trace_save_tsk() can be used. Like other architectures, > or like ARM's unwind_backtrace(), we can leave it up to the caller to > ensure that the task that needs to be unwound is not running. > > Signed-off-by: Li Huafei That sounds good, but: > if (tsk != current) { > -#ifdef CONFIG_SMP > - /* > - * What guarantees do we have here that 'tsk' is not > - * running on another CPU? For now, ignore it as we > - * can't guarantee we won't explode. > - */ > - return; > -#else > + /* task blocked in __switch_to */ The commit text is not consistent with the comment you are removing. The commit is talking about "non-current" tasks which is one thing, but the code is avoiding any tasks under SMP because they may be running on another CPU. So you need to update the commit message to say something like "non-current or running on another CPU". If this condition will be checked at call sites in following patches, then mention that in the commit as well, so we know the end result is that we do not break it, I think Russell want to check this commit as well, Yours, Linus Walleij