From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C68AC43217 for ; Fri, 11 Nov 2022 06:32:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232401AbiKKGce (ORCPT ); Fri, 11 Nov 2022 01:32:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232935AbiKKGbY (ORCPT ); Fri, 11 Nov 2022 01:31:24 -0500 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A46EC1AF24 for ; Thu, 10 Nov 2022 22:29:01 -0800 (PST) Received: by mail-yb1-xb2a.google.com with SMTP id y192so1557973yby.1 for ; Thu, 10 Nov 2022 22:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YfGpV2JA6patueMGzEYztlKL5Nu/nd16bt9DITnJUsw=; b=EhhSM3ubjZZaNZW6RsLRC5+FRMYk1rWzaPCdefEyP6qJ3zQelmXzARbaV4VbwNhuUU Z5Es/matWC2laMecuVrAfpFH43B8jkn6BuywA3Rl38VFl4g0dkFqhMMv7pVWyLLTH4Vh IhmS6VaIQOHK9sMSN+nIaVZ67YvF7rbs4J5b0MXjABKQiXCL1DgICa4ZfLmB68aAw7M0 uggrcvUXW+11tHXofn0LcNQlrKdteVdAHkc7ruWcANvyDoSNB9mnrs6Z7228tVlIu77B 8zxW2oxbAvd1G87KDie6SBwvO6O/n9muMnP4eHQsL+/wwZ2fTx+xq79Y26xQyK4pijoz 7TpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YfGpV2JA6patueMGzEYztlKL5Nu/nd16bt9DITnJUsw=; b=AOoEadkwiYy92TU34mnPrMZAiEzYQ+ToSayvgGOIeoyJ+g5B2Lip1Kz/vVarclYmcn cE9hFQAl0bbhVkoFH/muOVr0ix8OZFFGlQl0yjAio/GvGF6jJPSg70oNZ3lSqs7By2jS 4390r9Bd0jacBXizyp8UZ5eTFylzfhlEyXBXKXIA0Qrm/ZlQ9L6W9olLzCJ/xnIxli/x oSj8nBpN18E7QxvhPKuTzHESulmTIFRQ7pgc1OWV3qLB11zbMqXeV4avoRox5/n01XgQ 53zI1EJPKX3vxxOJ6eeIFZnKzrbFAt+vuIZrs3A89wVFFu5pslcacCqtO+YhNmmYUVEC amFg== X-Gm-Message-State: ANoB5pmuDQDHZakFSTqJoTjureR4+0Oaq46xjCRh78cMQYpR3FT4itkM mfz5qSYa4JFmXNwBxFj845LMqSCCkLfb9ohypyqDcw== X-Google-Smtp-Source: AA0mqf7h9gVbHC9AIBKiyUShaRgyYmJgsc/IKxG8U0ryPQvMgEnypOPr6AWgIEdMQtAbmXCJHUnS5NDMJkuqCMSxkJQ= X-Received: by 2002:a25:900c:0:b0:6c4:8a9:e4d2 with SMTP id s12-20020a25900c000000b006c408a9e4d2mr544847ybl.164.1668148140428; Thu, 10 Nov 2022 22:29:00 -0800 (PST) MIME-Version: 1.0 References: <29824864-f076-401f-bfb4-bc105bb2d38f@app.fastmail.com> <96a99291-7caa-429c-9bbd-29721a2b5637@app.fastmail.com> In-Reply-To: <96a99291-7caa-429c-9bbd-29721a2b5637@app.fastmail.com> From: Naresh Kamboju Date: Fri, 11 Nov 2022 11:58:48 +0530 Message-ID: Subject: Re: arm: TI BeagleBoard X15 : Unable to handle kernel NULL pointer dereference at virtual address 00000369 - Internal error: Oops: 5 [#1] SMP ARM To: Arnd Bergmann Cc: linux-stable , open list , Linux ARM , lkft-triage@lists.linaro.org, Greg Kroah-Hartman , Sasha Levin , Linus Walleij , Mark Brown , Liam Girdwood Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On Thu, 10 Nov 2022 at 03:33, Arnd Bergmann wrote: > > 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 I have done this experiment and reported crash not reproduced after eight rounds of testing [1]. https://lkft.validation.linaro.org/scheduler/job/5835922#L1993 > > Arnd - Naresh