mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Naresh Kamboju" <naresh.kamboju@linaro.org>,
	linux-stable <stable@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	lkft-triage@lists.linaro.org
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Sasha Levin" <sashal@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>
Subject: Re: arm: TI BeagleBoard X15 : Unable to handle kernel NULL pointer dereference at virtual address 00000369 - Internal error: Oops: 5 [#1] SMP ARM
Date: Wed, 09 Nov 2022 23:03:04 +0100	[thread overview]
Message-ID: <96a99291-7caa-429c-9bbd-29721a2b5637@app.fastmail.com> (raw)
In-Reply-To: <29824864-f076-401f-bfb4-bc105bb2d38f@app.fastmail.com>

On Wed, Nov 9, 2022, at 13:57, Arnd Bergmann wrote:
>
> One thing that sticks out is the print_constraints_debug() function
> in the regulator framework, which uses a larger-than-average stack
> to hold a string buffer, and then calls into the low-level
> driver to get the actual data (regulator_get_voltage_rdev,
> _regulator_is_enabled). Splitting the device access out into a
> different function from the string handling might reduce the
> stack usage enough to stay just under the 8KB limit, though it's
> probably not a complete fix. I added the regulator maintainers
> to Cc for thoughts on this.

I checked the stack usage for each of the 147 functions in the
backtrace, and as I was guessing print_constraints_debug() is
the largest, but it's still only 168 bytes, and everything else
is smaller, so no point hacking this.

168 	print_constraints_debug
96 	timekeeping_advance
64 	set_machine_constraints
64 	of_i2c_register_device
56 	of_platform_bus_create
48 	schedule_timeout

One more idea I had is the unwinder: since this kernel is built
with the frame-pointer unwinder, I think the stack usage per
function is going to be slightly larger than with the arm unwinder.

Naresh, how hard is it to reproduce this bug intentionally?
Can you try if it still happens if you change the .config to
use these:?

# CONFIG_FUNCTION_GRAPH_TRACER is not set
# CONFIG_UNWINDER_FRAME_POINTER is not set
CONFIG_UNWINDER_ARM=y

       Arnd

  reply	other threads:[~2022-11-09 22:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 11:10 Naresh Kamboju
2022-11-09 12:57 ` Arnd Bergmann
2022-11-09 22:03   ` Arnd Bergmann [this message]
2022-11-11  0:48     ` Dmitry Torokhov
2022-11-11  9:21       ` Arnd Bergmann
2022-11-11  6:28     ` Naresh Kamboju
2022-11-11  8:44       ` Arnd Bergmann
2022-11-11  8:55         ` Ard Biesheuvel

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=96a99291-7caa-429c-9bbd-29721a2b5637@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®