Message ID | 20230530201955.848176-1-florian.fainelli@broadcom.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2444418vqr; Tue, 30 May 2023 13:33:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4jyZoKlz3SUkxjrmkSc+bCghBp6Y76vOXSv5FVzxwJeME3thlZOM0dg0sdyJqSuL0D29e9 X-Received: by 2002:a05:6a20:e486:b0:10b:cdb1:3563 with SMTP id ni6-20020a056a20e48600b0010bcdb13563mr3398345pzb.46.1685478793035; Tue, 30 May 2023 13:33:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685478793; cv=none; d=google.com; s=arc-20160816; b=qm53JXwzWGn0DvBOEuuL3dB3Vet4p7JI+Ga1+BV1Ms7I8JqLjryM6LnbeVcYPQQC2D 35IT7xN4/Co1hPTRuUkzXmWtXEnzXzG9wk4k3aAorpzNU/fXmyTMvssp6Pi1jkBl9Tlh NpK9l39Iq+YaGIMIf6PEOi2Zm7Ty1Op//wQNxYNFykWotLSDVmlWbGT9gUrBsnv0MfgU r3VjaNVvBAcXqQ/8Y1t/utovTH14ok0zaLycbR7RXUSjiBN8gMqb96tKLshEzXnnNYuj XCtiXAHxu+3wZPOJEM8IABILyeJUjJ/sSkbGiM800henMvmhqN5/8BrOVKHLyjnzDzr9 /Ulw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=CNALgEou4+OqM+ORFPFW2dor3ylhB/+d4Xmh6hWNqx0=; b=PzJ2ALqhW1zWZf+6xYMC14YG8CWTUamvqxEyntZgYmlt/msym5vOjuehWf5D8Cg75H 5LtCItbR3D9ceggNpLOMMRWxzSJQmyNCAxiVJY8w36hTTiAmxBG69ZXUpssiQuQPIiI+ CPzm+qlYPpFi9bvQzZAAJlRp3qocZ4Yy7mB3jm6eIdcIBAWUbJnCeItZmROGWcu5JNjh Xjp0iRqJ5zqq5GbBgsupk2qQGcgtw4xk0BKKs3o8PYCeGsShOpaU3sGiWRtUyVZWneCH 7fUajjikIK942F9uS4OPwjmGkELd1nVIddjxxTw5pk2z1mRChE8uyZCivodrWbgylO1R gO0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b="BLJaRk/2"; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k130-20020a633d88000000b00528d0d8b7bbsi1863987pga.595.2023.05.30.13.33.00; Tue, 30 May 2023 13:33:12 -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=@broadcom.com header.s=google header.b="BLJaRk/2"; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231434AbjE3UUL (ORCPT <rfc822;andrewvogler123@gmail.com> + 99 others); Tue, 30 May 2023 16:20:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233383AbjE3UUH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 30 May 2023 16:20:07 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AAD4124 for <linux-kernel@vger.kernel.org>; Tue, 30 May 2023 13:20:05 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1b025d26f4fso33477365ad.1 for <linux-kernel@vger.kernel.org>; Tue, 30 May 2023 13:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1685478005; x=1688070005; h=mime-version:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=CNALgEou4+OqM+ORFPFW2dor3ylhB/+d4Xmh6hWNqx0=; b=BLJaRk/2rwuF8oqfzoj3p3LvSyuEhTVG/N17+9uTWFVTSVBqlimo6EQPHJ+hfQvhDN 4TJJHHihrXTmXFB/GnbZ2cCdmVzSXY7Yj6j1VZTUwS/K4tKDd8j/L75EhE3SwtMHzfrg 6cqmXcBm4dBroSgckSZ0DiOBZ446yNvsFBV4Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685478005; x=1688070005; h=mime-version:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CNALgEou4+OqM+ORFPFW2dor3ylhB/+d4Xmh6hWNqx0=; b=gI24MKTf1coL60SegI6YgNLdNWzU+GhJq+kBKOXBu1S36CW4wqTVePyDU+41zoDDvA AifnBoINZJqwgs+NDvAPCNKK22sE2cUjdm7lwaGm0WUQcHVQZyDzCSZR0iPH5rKZ6wJ9 LbTTrL5RnCJIHyeAOjfPEqerBeLMX28BMUbqgt3s8gn5isq9YJ2gDYG+/+puB9W8Livu oK3PjVuxdfPdaX7aa3mUslrNy6pItc7fIbR1KFmxzMlQRtTmR6FY+4vrbuikpgZ+q9mm ZRB36IwTOD9LpXK7K0/fxK7c/Fc8k2oNiC+R+7EJ+A8l3azD1qWRWT0MR5rAE1GGQGu0 XPeA== X-Gm-Message-State: AC+VfDzfOubVpptZhDwm/8czkR8zgbJIZwF8LQZ17+qIsREIwNS1AAah SSaFA8RA/dZnKt9uFVpdaajJ1g== X-Received: by 2002:a17:902:aa86:b0:1b0:2d08:eb51 with SMTP id d6-20020a170902aa8600b001b02d08eb51mr3426185plr.12.1685478004778; Tue, 30 May 2023 13:20:04 -0700 (PDT) Received: from stbirv-lnx-3.igp.broadcom.net ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id u9-20020a17090341c900b001ac7af58b66sm10676712ple.224.2023.05.30.13.20.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 May 2023 13:20:04 -0700 (PDT) From: Florian Fainelli <florian.fainelli@broadcom.com> To: stable@vger.kernel.org Cc: Pierre Gondois <pierre.gondois@arm.com>, Conor Dooley <conor.dooley@microchip.com>, Sudeep Holla <sudeep.holla@arm.com>, Florian Fainelli <florian.fainelli@broadcom.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, linux-kernel@vger.kernel.org (open list:GENERIC ARCHITECTURE TOPOLOGY) Subject: [PATCH stable 6.3 v2] arch_topology: Remove early cacheinfo error message if -ENOENT Date: Tue, 30 May 2023 13:19:55 -0700 Message-Id: <20230530201955.848176-1-florian.fainelli@broadcom.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c75bbe05fceeedd7" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MIME_NO_TEXT, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767352557834496786?= X-GMAIL-MSGID: =?utf-8?q?1767352610666342335?= |
Series |
[stable,6.3,v2] arch_topology: Remove early cacheinfo error message if -ENOENT
|
|
Commit Message
Florian Fainelli
May 30, 2023, 8:19 p.m. UTC
From: Pierre Gondois <pierre.gondois@arm.com> commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream fetch_cache_info() tries to get the number of cache leaves/levels for each CPU in order to pre-allocate memory for cacheinfo struct. Allocating this memory later triggers a: 'BUG: sleeping function called from invalid context' in PREEMPT_RT kernels. If there is no cache related information available in DT or ACPI, fetch_cache_info() fails and an error message is printed: 'Early cacheinfo failed, ret = ...' Not having cache information should be a valid configuration. Remove the error message if fetch_cache_info() fails with -ENOENT. Suggested-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> --- Changes in v2: - Added missing upstream commit reference - Added missing S-o-b drivers/base/arch_topology.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Comments
Yo Florian, On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: > From: Pierre Gondois <pierre.gondois@arm.com> > > commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream > > fetch_cache_info() tries to get the number of cache leaves/levels > for each CPU in order to pre-allocate memory for cacheinfo struct. > Allocating this memory later triggers a: > 'BUG: sleeping function called from invalid context' > in PREEMPT_RT kernels. > > If there is no cache related information available in DT or ACPI, > fetch_cache_info() fails and an error message is printed: > 'Early cacheinfo failed, ret = ...' > > Not having cache information should be a valid configuration. > Remove the error message if fetch_cache_info() fails with -ENOENT. > > Suggested-by: Conor Dooley <conor.dooley@microchip.com> > Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> How come this now needs a backport? Did the rest of the series get backported, but not this one since it has no fixes tag? Cheers, Conor.
Hi Conor, On 5/30/23 14:39, Conor Dooley wrote: > Yo Florian, > > On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: >> From: Pierre Gondois <pierre.gondois@arm.com> >> >> commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream >> >> fetch_cache_info() tries to get the number of cache leaves/levels >> for each CPU in order to pre-allocate memory for cacheinfo struct. >> Allocating this memory later triggers a: >> 'BUG: sleeping function called from invalid context' >> in PREEMPT_RT kernels. >> >> If there is no cache related information available in DT or ACPI, >> fetch_cache_info() fails and an error message is printed: >> 'Early cacheinfo failed, ret = ...' >> >> Not having cache information should be a valid configuration. >> Remove the error message if fetch_cache_info() fails with -ENOENT. >> >> Suggested-by: Conor Dooley <conor.dooley@microchip.com> >> Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ >> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> >> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> >> Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> > > How come this now needs a backport? Did the rest of the series get > backported, but not this one since it has no fixes tag? Humm, indeed, this has been present in v6.3.2 since I requested it to be included. The error that I saw this morning was not -ENOENT, but -EINVAL. With those patches applied, no more -EINVAL: cacheinfo: Allow early level detection when DT/ACPI info is missing/broken cacheinfo: Add arm64 early level initializer implementation cacheinfo: Add arch specific early level initializer cacheinfo: Add use_arch[|_cache]_info field/function I will submit those shortly unless we think they better not be in 6.3, in which case it would be nice to silence those -EINVAL errors.
On Tue, May 30, 2023 at 03:42:45PM -0700, Florian Fainelli wrote: > Hi Conor, > > On 5/30/23 14:39, Conor Dooley wrote: > > Yo Florian, > > > > On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: > > > From: Pierre Gondois <pierre.gondois@arm.com> > > > > > > commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream > > > > > > fetch_cache_info() tries to get the number of cache leaves/levels > > > for each CPU in order to pre-allocate memory for cacheinfo struct. > > > Allocating this memory later triggers a: > > > 'BUG: sleeping function called from invalid context' > > > in PREEMPT_RT kernels. > > > > > > If there is no cache related information available in DT or ACPI, > > > fetch_cache_info() fails and an error message is printed: > > > 'Early cacheinfo failed, ret = ...' > > > > > > Not having cache information should be a valid configuration. > > > Remove the error message if fetch_cache_info() fails with -ENOENT. > > > > > > Suggested-by: Conor Dooley <conor.dooley@microchip.com> > > > Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ > > > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> > > > > How come this now needs a backport? Did the rest of the series get > > backported, but not this one since it has no fixes tag? > > Humm, indeed, this has been present in v6.3.2 since I requested it to be > included. The error that I saw this morning was not -ENOENT, but -EINVAL. > > With those patches applied, no more -EINVAL: > > cacheinfo: Allow early level detection when DT/ACPI info is missing/broken > cacheinfo: Add arm64 early level initializer implementation > cacheinfo: Add arch specific early level initializer > cacheinfo: Add use_arch[|_cache]_info field/function > > I will submit those shortly unless we think they better not be in 6.3, in > which case it would be nice to silence those -EINVAL errors. I prefer this option instead of back porting all the above 4 as there are some pending fixes for the issues found in those patches. I am fine if Greg is happy with the backport, so no strong rejection from my side :).
On Wed, May 31, 2023 at 09:53:56AM +0100, Sudeep Holla wrote: > On Tue, May 30, 2023 at 03:42:45PM -0700, Florian Fainelli wrote: > > Hi Conor, > > > > On 5/30/23 14:39, Conor Dooley wrote: > > > Yo Florian, > > > > > > On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: > > > > From: Pierre Gondois <pierre.gondois@arm.com> > > > > > > > > commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream > > > > > > > > fetch_cache_info() tries to get the number of cache leaves/levels > > > > for each CPU in order to pre-allocate memory for cacheinfo struct. > > > > Allocating this memory later triggers a: > > > > 'BUG: sleeping function called from invalid context' > > > > in PREEMPT_RT kernels. > > > > > > > > If there is no cache related information available in DT or ACPI, > > > > fetch_cache_info() fails and an error message is printed: > > > > 'Early cacheinfo failed, ret = ...' > > > > > > > > Not having cache information should be a valid configuration. > > > > Remove the error message if fetch_cache_info() fails with -ENOENT. > > > > > > > > Suggested-by: Conor Dooley <conor.dooley@microchip.com> > > > > Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ > > > > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> > > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > > Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> > > > > > > How come this now needs a backport? Did the rest of the series get > > > backported, but not this one since it has no fixes tag? > > > > Humm, indeed, this has been present in v6.3.2 since I requested it to be > > included. The error that I saw this morning was not -ENOENT, but -EINVAL. > > > > With those patches applied, no more -EINVAL: > > > > cacheinfo: Allow early level detection when DT/ACPI info is missing/broken > > cacheinfo: Add arm64 early level initializer implementation > > cacheinfo: Add arch specific early level initializer > > cacheinfo: Add use_arch[|_cache]_info field/function > > > > I will submit those shortly unless we think they better not be in 6.3, in > > which case it would be nice to silence those -EINVAL errors. > > I prefer this option instead of back porting all the above 4 as there are > some pending fixes for the issues found in those patches. I am fine if Greg > is happy with the backport, so no strong rejection from my side :). Just to be clear, I was not objecting, just curious!
On 5/31/2023 1:53 AM, Sudeep Holla wrote: > On Tue, May 30, 2023 at 03:42:45PM -0700, Florian Fainelli wrote: >> Hi Conor, >> >> On 5/30/23 14:39, Conor Dooley wrote: >>> Yo Florian, >>> >>> On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: >>>> From: Pierre Gondois <pierre.gondois@arm.com> >>>> >>>> commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream >>>> >>>> fetch_cache_info() tries to get the number of cache leaves/levels >>>> for each CPU in order to pre-allocate memory for cacheinfo struct. >>>> Allocating this memory later triggers a: >>>> 'BUG: sleeping function called from invalid context' >>>> in PREEMPT_RT kernels. >>>> >>>> If there is no cache related information available in DT or ACPI, >>>> fetch_cache_info() fails and an error message is printed: >>>> 'Early cacheinfo failed, ret = ...' >>>> >>>> Not having cache information should be a valid configuration. >>>> Remove the error message if fetch_cache_info() fails with -ENOENT. >>>> >>>> Suggested-by: Conor Dooley <conor.dooley@microchip.com> >>>> Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ >>>> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> >>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> >>>> Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com >>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>>> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> >>> >>> How come this now needs a backport? Did the rest of the series get >>> backported, but not this one since it has no fixes tag? >> >> Humm, indeed, this has been present in v6.3.2 since I requested it to be >> included. The error that I saw this morning was not -ENOENT, but -EINVAL. >> >> With those patches applied, no more -EINVAL: >> >> cacheinfo: Allow early level detection when DT/ACPI info is missing/broken >> cacheinfo: Add arm64 early level initializer implementation >> cacheinfo: Add arch specific early level initializer >> cacheinfo: Add use_arch[|_cache]_info field/function >> >> I will submit those shortly unless we think they better not be in 6.3, in >> which case it would be nice to silence those -EINVAL errors. > > I prefer this option instead of back porting all the above 4 as there are > some pending fixes for the issues found in those patches. I am fine if Greg > is happy with the backport, so no strong rejection from my side :). OK, so are you suggesting that we specific check for -EINVAL and -ENOENT rather than take all of the 4 above patches, if so, any preference on how to do it given the state of 6.3 stable?
On Wed, May 31, 2023 at 08:28:26AM -0700, Florian Fainelli wrote: > > > On 5/31/2023 1:53 AM, Sudeep Holla wrote: > > On Tue, May 30, 2023 at 03:42:45PM -0700, Florian Fainelli wrote: > > > Hi Conor, > > > > > > On 5/30/23 14:39, Conor Dooley wrote: > > > > Yo Florian, > > > > > > > > On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: > > > > > From: Pierre Gondois <pierre.gondois@arm.com> > > > > > > > > > > commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream > > > > > > > > > > fetch_cache_info() tries to get the number of cache leaves/levels > > > > > for each CPU in order to pre-allocate memory for cacheinfo struct. > > > > > Allocating this memory later triggers a: > > > > > 'BUG: sleeping function called from invalid context' > > > > > in PREEMPT_RT kernels. > > > > > > > > > > If there is no cache related information available in DT or ACPI, > > > > > fetch_cache_info() fails and an error message is printed: > > > > > 'Early cacheinfo failed, ret = ...' > > > > > > > > > > Not having cache information should be a valid configuration. > > > > > Remove the error message if fetch_cache_info() fails with -ENOENT. > > > > > > > > > > Suggested-by: Conor Dooley <conor.dooley@microchip.com> > > > > > Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ > > > > > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> > > > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > > > Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> > > > > > > > > How come this now needs a backport? Did the rest of the series get > > > > backported, but not this one since it has no fixes tag? > > > > > > Humm, indeed, this has been present in v6.3.2 since I requested it to be > > > included. The error that I saw this morning was not -ENOENT, but -EINVAL. > > > > > > With those patches applied, no more -EINVAL: > > > > > > cacheinfo: Allow early level detection when DT/ACPI info is missing/broken > > > cacheinfo: Add arm64 early level initializer implementation > > > cacheinfo: Add arch specific early level initializer > > > cacheinfo: Add use_arch[|_cache]_info field/function > > > > > > I will submit those shortly unless we think they better not be in 6.3, in > > > which case it would be nice to silence those -EINVAL errors. > > > > I prefer this option instead of back porting all the above 4 as there are > > some pending fixes for the issues found in those patches. I am fine if Greg > > is happy with the backport, so no strong rejection from my side :). > > OK, so are you suggesting that we specific check for -EINVAL and -ENOENT > rather than take all of the 4 above patches, Yes that is my preference ATM or if possible to wait until all the fixes are sorted for the bugs associated with above 4 commits [1] and [2]. I have queued [1] but waiting for response/patch on [2] and hence not yet bothered Greg. > if so, any preference on how to do it given the state of 6.3 stable? I don't understand what exactly do you mean ? -- Regards, Sudeep [1] https://lore.kernel.org/all/20230508084115.1157-1-kprateek.nayak@amd.com [2] https://lore.kernel.org/all/20230518012703.GA19967@ranerica-svr.sc.intel.com
On 5/31/2023 8:43 AM, Sudeep Holla wrote: > On Wed, May 31, 2023 at 08:28:26AM -0700, Florian Fainelli wrote: >> >> >> On 5/31/2023 1:53 AM, Sudeep Holla wrote: >>> On Tue, May 30, 2023 at 03:42:45PM -0700, Florian Fainelli wrote: >>>> Hi Conor, >>>> >>>> On 5/30/23 14:39, Conor Dooley wrote: >>>>> Yo Florian, >>>>> >>>>> On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: >>>>>> From: Pierre Gondois <pierre.gondois@arm.com> >>>>>> >>>>>> commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream >>>>>> >>>>>> fetch_cache_info() tries to get the number of cache leaves/levels >>>>>> for each CPU in order to pre-allocate memory for cacheinfo struct. >>>>>> Allocating this memory later triggers a: >>>>>> 'BUG: sleeping function called from invalid context' >>>>>> in PREEMPT_RT kernels. >>>>>> >>>>>> If there is no cache related information available in DT or ACPI, >>>>>> fetch_cache_info() fails and an error message is printed: >>>>>> 'Early cacheinfo failed, ret = ...' >>>>>> >>>>>> Not having cache information should be a valid configuration. >>>>>> Remove the error message if fetch_cache_info() fails with -ENOENT. >>>>>> >>>>>> Suggested-by: Conor Dooley <conor.dooley@microchip.com> >>>>>> Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ >>>>>> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> >>>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> >>>>>> Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com >>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>>>>> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> >>>>> >>>>> How come this now needs a backport? Did the rest of the series get >>>>> backported, but not this one since it has no fixes tag? >>>> >>>> Humm, indeed, this has been present in v6.3.2 since I requested it to be >>>> included. The error that I saw this morning was not -ENOENT, but -EINVAL. >>>> >>>> With those patches applied, no more -EINVAL: >>>> >>>> cacheinfo: Allow early level detection when DT/ACPI info is missing/broken >>>> cacheinfo: Add arm64 early level initializer implementation >>>> cacheinfo: Add arch specific early level initializer >>>> cacheinfo: Add use_arch[|_cache]_info field/function >>>> >>>> I will submit those shortly unless we think they better not be in 6.3, in >>>> which case it would be nice to silence those -EINVAL errors. >>> >>> I prefer this option instead of back porting all the above 4 as there are >>> some pending fixes for the issues found in those patches. I am fine if Greg >>> is happy with the backport, so no strong rejection from my side :). >> >> OK, so are you suggesting that we specific check for -EINVAL and -ENOENT >> rather than take all of the 4 above patches, > > Yes that is my preference ATM or if possible to wait until all the fixes > are sorted for the bugs associated with above 4 commits [1] and [2]. > I have queued [1] but waiting for response/patch on [2] and hence not yet > bothered Greg. > >> if so, any preference on how to do it given the state of 6.3 stable? > > I don't understand what exactly do you mean ? Linux 6.3.y currently contains: cacheinfo: Check sib_leaf in cache_leaves_are_shared() cacheinfo: Check cache properties are present in DT arch_topology: Remove early cacheinfo error message if -ENOENT however my logs are full of: [ 0.001484] Early cacheinfo failed, ret = -22 reverting these 3 patches mentioned above does not eliminate the error. What I am asking is if we need a targeted fix for 6.3 like this: diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index c4b6198d7461..a72fcf836ed3 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -845,7 +845,7 @@ void __init init_cpu_topology(void) ret = fetch_cache_info(cpu); if (!ret) continue; - else if (ret != -ENOENT) + else if (ret != -ENOENT && ret != -EINVAL) pr_err("Early cacheinfo failed, ret = %d\n", ret); return; }
On Wed, May 31, 2023 at 12:52:22PM -0700, Florian Fainelli wrote: > > > On 5/31/2023 8:43 AM, Sudeep Holla wrote: > > On Wed, May 31, 2023 at 08:28:26AM -0700, Florian Fainelli wrote: > > > > > > > > > On 5/31/2023 1:53 AM, Sudeep Holla wrote: > > > > On Tue, May 30, 2023 at 03:42:45PM -0700, Florian Fainelli wrote: > > > > > Hi Conor, > > > > > > > > > > On 5/30/23 14:39, Conor Dooley wrote: > > > > > > Yo Florian, > > > > > > > > > > > > On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: > > > > > > > From: Pierre Gondois <pierre.gondois@arm.com> > > > > > > > > > > > > > > commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream > > > > > > > > > > > > > > fetch_cache_info() tries to get the number of cache leaves/levels > > > > > > > for each CPU in order to pre-allocate memory for cacheinfo struct. > > > > > > > Allocating this memory later triggers a: > > > > > > > 'BUG: sleeping function called from invalid context' > > > > > > > in PREEMPT_RT kernels. > > > > > > > > > > > > > > If there is no cache related information available in DT or ACPI, > > > > > > > fetch_cache_info() fails and an error message is printed: > > > > > > > 'Early cacheinfo failed, ret = ...' > > > > > > > > > > > > > > Not having cache information should be a valid configuration. > > > > > > > Remove the error message if fetch_cache_info() fails with -ENOENT. > > > > > > > > > > > > > > Suggested-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ > > > > > > > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> > > > > > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com > > > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > > > > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> > > > > > > > > > > > > How come this now needs a backport? Did the rest of the series get > > > > > > backported, but not this one since it has no fixes tag? > > > > > > > > > > Humm, indeed, this has been present in v6.3.2 since I requested it to be > > > > > included. The error that I saw this morning was not -ENOENT, but -EINVAL. > > > > > > > > > > With those patches applied, no more -EINVAL: > > > > > > > > > > cacheinfo: Allow early level detection when DT/ACPI info is missing/broken > > > > > cacheinfo: Add arm64 early level initializer implementation > > > > > cacheinfo: Add arch specific early level initializer > > > > > cacheinfo: Add use_arch[|_cache]_info field/function > > > > > > > > > > I will submit those shortly unless we think they better not be in 6.3, in > > > > > which case it would be nice to silence those -EINVAL errors. > > > > > > > > I prefer this option instead of back porting all the above 4 as there are > > > > some pending fixes for the issues found in those patches. I am fine if Greg > > > > is happy with the backport, so no strong rejection from my side :). > > > > > > OK, so are you suggesting that we specific check for -EINVAL and -ENOENT > > > rather than take all of the 4 above patches, > > > > Yes that is my preference ATM or if possible to wait until all the fixes > > are sorted for the bugs associated with above 4 commits [1] and [2]. > > I have queued [1] but waiting for response/patch on [2] and hence not yet > > bothered Greg. > > > > > if so, any preference on how to do it given the state of 6.3 stable? > > > > I don't understand what exactly do you mean ? > > Linux 6.3.y currently contains: > > cacheinfo: Check sib_leaf in cache_leaves_are_shared() > cacheinfo: Check cache properties are present in DT > arch_topology: Remove early cacheinfo error message if -ENOENT > > however my logs are full of: > > [ 0.001484] Early cacheinfo failed, ret = -22 > > reverting these 3 patches mentioned above does not eliminate the error. > > What I am asking is if we need a targeted fix for 6.3 like this: > I am fine with that. Please note Greg has now pulled the fixes I pointed. So I am fine if you want to backport the 4 patches discussed earlier as the stable will get the fixes soon which was my main concern earlier. The other issue I pointed should also be resolved soon based on [1]
On Thu, Jun 01, 2023 at 07:32:31AM +0100, Sudeep Holla wrote: > On Wed, May 31, 2023 at 12:52:22PM -0700, Florian Fainelli wrote: > > > > > > On 5/31/2023 8:43 AM, Sudeep Holla wrote: > > > On Wed, May 31, 2023 at 08:28:26AM -0700, Florian Fainelli wrote: > > > > > > > > > > > > On 5/31/2023 1:53 AM, Sudeep Holla wrote: > > > > > On Tue, May 30, 2023 at 03:42:45PM -0700, Florian Fainelli wrote: > > > > > > Hi Conor, > > > > > > > > > > > > On 5/30/23 14:39, Conor Dooley wrote: > > > > > > > Yo Florian, > > > > > > > > > > > > > > On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: > > > > > > > > From: Pierre Gondois <pierre.gondois@arm.com> > > > > > > > > > > > > > > > > commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream > > > > > > > > > > > > > > > > fetch_cache_info() tries to get the number of cache leaves/levels > > > > > > > > for each CPU in order to pre-allocate memory for cacheinfo struct. > > > > > > > > Allocating this memory later triggers a: > > > > > > > > 'BUG: sleeping function called from invalid context' > > > > > > > > in PREEMPT_RT kernels. > > > > > > > > > > > > > > > > If there is no cache related information available in DT or ACPI, > > > > > > > > fetch_cache_info() fails and an error message is printed: > > > > > > > > 'Early cacheinfo failed, ret = ...' > > > > > > > > > > > > > > > > Not having cache information should be a valid configuration. > > > > > > > > Remove the error message if fetch_cache_info() fails with -ENOENT. > > > > > > > > > > > > > > > > Suggested-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ > > > > > > > > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> > > > > > > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com > > > > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > > > > > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> > > > > > > > > > > > > > > How come this now needs a backport? Did the rest of the series get > > > > > > > backported, but not this one since it has no fixes tag? > > > > > > > > > > > > Humm, indeed, this has been present in v6.3.2 since I requested it to be > > > > > > included. The error that I saw this morning was not -ENOENT, but -EINVAL. > > > > > > > > > > > > With those patches applied, no more -EINVAL: > > > > > > > > > > > > cacheinfo: Allow early level detection when DT/ACPI info is missing/broken > > > > > > cacheinfo: Add arm64 early level initializer implementation > > > > > > cacheinfo: Add arch specific early level initializer > > > > > > cacheinfo: Add use_arch[|_cache]_info field/function > > > > > > > > > > > > I will submit those shortly unless we think they better not be in 6.3, in > > > > > > which case it would be nice to silence those -EINVAL errors. > > > > > > > > > > I prefer this option instead of back porting all the above 4 as there are > > > > > some pending fixes for the issues found in those patches. I am fine if Greg > > > > > is happy with the backport, so no strong rejection from my side :). > > > > > > > > OK, so are you suggesting that we specific check for -EINVAL and -ENOENT > > > > rather than take all of the 4 above patches, > > > > > > Yes that is my preference ATM or if possible to wait until all the fixes > > > are sorted for the bugs associated with above 4 commits [1] and [2]. > > > I have queued [1] but waiting for response/patch on [2] and hence not yet > > > bothered Greg. > > > > > > > if so, any preference on how to do it given the state of 6.3 stable? > > > > > > I don't understand what exactly do you mean ? > > > > Linux 6.3.y currently contains: > > > > cacheinfo: Check sib_leaf in cache_leaves_are_shared() > > cacheinfo: Check cache properties are present in DT > > arch_topology: Remove early cacheinfo error message if -ENOENT > > > > however my logs are full of: > > > > [ 0.001484] Early cacheinfo failed, ret = -22 > > > > reverting these 3 patches mentioned above does not eliminate the error. > > > > What I am asking is if we need a targeted fix for 6.3 like this: > > > > I am fine with that. Please note Greg has now pulled the fixes I pointed. > So I am fine if you want to backport the 4 patches discussed earlier as > the stable will get the fixes soon which was my main concern earlier. > > The other issue I pointed should also be resolved soon based on [1] Ok, I don't know what to do here. I think I'll take this simple patch, and not the longer series as that seems to be too much for 6.3.y now, especially as the fixes for it are not in Linus's tree yet. If, after a bit, all of those need to go to 6.3.y, can someone please send them here for inclusion? thanks, greg k-h
On Tue, May 30, 2023 at 01:19:55PM -0700, Florian Fainelli wrote: > From: Pierre Gondois <pierre.gondois@arm.com> > > commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream Wait, this is already in 6.3.2, so why add it again? totally confused, greg k-h
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 147fb7d4af96..b741b5ba82bd 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -843,10 +843,11 @@ void __init init_cpu_topology(void) for_each_possible_cpu(cpu) { ret = fetch_cache_info(cpu); - if (ret) { + if (!ret) + continue; + else if (ret != -ENOENT) pr_err("Early cacheinfo failed, ret = %d\n", ret); - break; - } + return; } }