Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: x86@kernel.org, Andreas Herrmann <aherrmann@suse.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Chen Yu <yu.c.chen@intel.com>, Len Brown <len.brown@intel.com>,
	Radu Rendec <rrendec@redhat.com>,
	Pierre Gondois <Pierre.Gondois@arm.com>, Pu Wen <puwen@hygon.cn>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Will Deacon <will@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
	stable@vger.kernel.org, Ricardo Neri <ricardo.neri@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/3] cacheinfo: Allocate memory for memory if not done from the primary CPU
Date: Wed, 30 Aug 2023 12:49:18 +0100	[thread overview]
Message-ID: <20230830114918.be4mvwfogdqmsxk6@bogus> (raw)
In-Reply-To: <20230805012421.7002-2-ricardo.neri-calderon@linux.intel.com>

On Fri, Aug 04, 2023 at 06:24:19PM -0700, Ricardo Neri wrote:
> Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")
> adds functionality that architectures can use to optionally allocate and
> build cacheinfo early during boot. Commit 6539cffa9495 ("cacheinfo: Add
> arch specific early level initializer") lets secondary CPUs correct (and
> reallocate memory) cacheinfo data if needed.
> 
> If the early build functionality is not used and cacheinfo does not need
> correction, memory for cacheinfo is never allocated. x86 does not use the
> early build functionality. Consequently, during the cacheinfo CPU hotplug
> callback, last_level_cache_is_valid() attempts to dereference a NULL
> pointer:
> 
>      BUG: kernel NULL pointer dereference, address: 0000000000000100
>      #PF: supervisor read access in kernel mode
>      #PF: error_code(0x0000) - not present page
>      PGD 0 P4D 0
>      Oops: 0000 [#1] PREEPMT SMP NOPTI
>      CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1
>      RIP: 0010: last_level_cache_is_valid+0x95/0xe0a
> 
> Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if
> not done earlier.
> 
> Cc: Andreas Herrmann <aherrmann@suse.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Chen Yu <yu.c.chen@intel.com>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Radu Rendec <rrendec@redhat.com>
> Cc: Pierre Gondois <Pierre.Gondois@arm.com>
> Cc: Pu Wen <puwen@hygon.cn>
> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: stable@vger.kernel.org
> Acked-by: Len Brown <len.brown@intel.com>
> Fixes: 6539cffa9495 ("cacheinfo: Add arch specific early level initializer")

Not sure if we strictly need this(details below), but I am fine either way.

> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
> The motivation for commit 5944ce092b97 was to prevent a BUG splat in
> PREEMPT_RT kernels during memory allocation. This splat is not observed on
> x86 because the memory allocation for cacheinfo happens in
> detect_cache_attributes() from the cacheinfo CPU hotplug callback.
> 
> The dereference of a NULL pointer is not observed today because
> cache_leaves(cpu) is zero until after init_cache_level() is called (also
> during the CPU hotplug callback). Patch2 will set it earlier and the NULL-
> pointer dereference will be observed.

Right, this is the information I have been asking in the previous versions.
This clarifies a lot. The trigger is in the patch 2/3 which is why it didn't
make complete sense to me without it when you posted this patch independently.
Thanks for posting it together and sorry for the delay(both reviewing this
and in understanding the issue).

Given the trigger for NULL pointer dereference is in 2/3, I am not sure
if it is really worth applying this to all the stable kernels with the
commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU").
That is the reason why I asked to drop fixes tag if you agree with me.
It is simple fix, so I am OK if you prefer to see that in the stable kernels
as well.

Since there are x86 changes and patch 2/3 triggers NULL pointer dereference
without this patch, I prefer you route all 3 via x86. So,

Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-08-30 11:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230805012421.7002-1-ricardo.neri-calderon@linux.intel.com>
2023-08-05  1:24 ` [PATCH v3 1/3] cacheinfo: Allocate memory for memory if not done from the primary CPU Ricardo Neri
2023-08-05 14:28   ` Radu Rendec
2023-08-07 23:12     ` Ricardo Neri
2023-08-30 11:49   ` Sudeep Holla [this message]
2023-08-30 12:13     ` Radu Rendec
2023-08-30 15:47       ` Sudeep Holla
2023-08-30 16:45         ` Radu Rendec
2023-09-12  0:30           ` Ricardo Neri
2023-08-05  1:24 ` [PATCH v3 2/3] x86/cacheinfo: Delete global num_cache_leaves Ricardo Neri
2023-08-05  1:24 ` [PATCH v3 3/3] x86/cacheinfo: Clean out init_cache_level() Ricardo Neri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230830114918.be4mvwfogdqmsxk6@bogus \
    --to=sudeep.holla@arm.com \
    --cc=Pierre.Gondois@arm.com \
    --cc=aherrmann@suse.com \
    --cc=catalin.marinas@arm.com \
    --cc=len.brown@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=puwen@hygon.cn \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=ricardo.neri@intel.com \
    --cc=rrendec@redhat.com \
    --cc=rui.zhang@intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox