public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Florian Fainelli <florian.fainelli@broadcom.com>
To: "Rafał Miłecki" <zajec5@gmail.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
	"Waiman Long" <longman@redhat.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	linux-clk@vger.kernel.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Network Development" <netdev@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>
Subject: Re: ARM board lockups/hangs triggered by locks and mutexes
Date: Mon, 7 Aug 2023 11:34:55 -0700	[thread overview]
Message-ID: <ee134dae-8353-5735-e02d-e2cb1088c428@broadcom.com> (raw)
In-Reply-To: <0f9d0cd6-d344-7915-7bc1-7a090b8305d2@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2610 bytes --]

On 8/7/23 04:10, Rafał Miłecki wrote:
> On 4.08.2023 13:07, Rafał Miłecki wrote:
>> I triple checked that. Dropping a single unused function breaks kernel /
>> device stability on BCM53573!
>>
>> AFAIK the only thing below diff actually affects is location of symbols
>> (I actually verified that by comparing System.map before and after -
>> over 22'000 of relocated symbols).
>>
>> Can some unfortunate location of symbols cause those hangs/lockups?
> 
> I performed another experiment. First I dropped mtd_check_of_node() to
> bring kernel back to the stable state.
> 
> Then I started adding useless code to the mtdchar_unlocked_ioctl(). I
> ended up adding just enough to make sure all post-mtd symbols in
> System.map got the same offset as in case of backporting
> mtd_check_of_node().
> 
> I started experiencing lockups/hangs again.
> 
> I repeated the same test with adding dumb code to the brcm_nvram_probe()
> and verifying symbols offsets following brcm_nvram_probe one.
> 
> I believe this confirms that this problem is about offset or alignment
> of some specific symbol(s). The remaining question is what symbols and
> how to fix or workaround that.

In the config.gz file you attached in your first email, both 
CONFIG_MTD_* and CONFIG_NVMEM_* so it is not like we are reaching into 
module space for code and/or data and need veneers or anything, it is 
part of the kernel image so we can assert the maximum distance between 
instructions etc.

Now is it just that specific mutex that is an issue, or do other mutexes 
through the system do cause problems as well?

Do we suspect the toolchain to be possibly problematic?

> 
> Following dump change brings back lockups/hangs:
> 
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index ee437af41..0a24dec55 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -1028,6 +1028,22 @@ static long mtdchar_unlocked_ioctl(struct file 
> *file, u_int cmd, u_long arg)
>   {
>       int ret;
> 
> +    if (!file)
> +        pr_info("Missing\n");
> +    WARN_ON(!file);
> +    WARN_ON(cmd == 1234);
> +    WARN_ON(cmd == 5678);
> +    WARN_ON(cmd == 1234);
> +    WARN_ON(cmd == 5678);
> +    WARN_ON(cmd == 1234);
> +    WARN_ON(cmd == 5678);
> +    WARN_ON(cmd == 1234);
> +    WARN_ON(cmd == 5678);
> +    WARN_ON(cmd == 1234);
> +    WARN_ON(cmd == 5678);
> +    WARN_ON(cmd == 1234);
> +    WARN_ON(cmd == 5678);
> +
>       mutex_lock(&mtd_mutex);
>       ret = mtdchar_ioctl(file, cmd, arg);
>       mutex_unlock(&mtd_mutex);
> 

-- 
Florian


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

  reply	other threads:[~2023-08-07 18:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-01 22:10 ARM board lockups/hangs triggered by locks and mutexes Rafał Miłecki
2023-08-01 22:21 ` Russell King (Oracle)
2023-08-02  7:00   ` Rafał Miłecki
2023-08-02  7:38     ` Rafał Miłecki
2023-08-01 22:25 ` Florian Fainelli
2023-08-02  7:02   ` Rafał Miłecki
2023-08-04 10:24 ` Rafał Miłecki
2023-08-04 11:07 ` Rafał Miłecki
2023-08-07 11:10   ` Rafał Miłecki
2023-08-07 18:34     ` Florian Fainelli [this message]
2023-08-11 10:49       ` Rafał Miłecki
2023-08-14  9:04     ` Geert Uytterhoeven
2023-08-18 20:23       ` Rafał Miłecki
2023-08-18 20:24         ` Rafał Miłecki

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=ee134dae-8353-5735-e02d-e2cb1088c428@broadcom.com \
    --to=florian.fainelli@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=boqun.feng@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=openwrt-devel@lists.openwrt.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=zajec5@gmail.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