All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Perret <qperret@google.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Alexandre TORGUE <alexandre.torgue@foss.st.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>, stable <stable@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	KarimAllah Ahmed <karahmed@amazon.de>,
	Android Kernel Team <kernel-team@android.com>,
	Architecture Mailman List <boot-architecture@lists.linaro.org>,
	Frank Rowand <frowand.list@gmail.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region
Date: Wed, 21 Apr 2021 08:45:42 +0000	[thread overview]
Message-ID: <YH/mNosARuC1KiuY@google.com> (raw)
In-Reply-To: <YH/ixPnHMxNo08mJ@google.com>

On Wednesday 21 Apr 2021 at 08:31:00 (+0000), Quentin Perret wrote:
> FWIW I did test this on Qemu before posting. With 5.12-rc8 and a 1MiB
> no-map region at 0x80000000, I have the following:
> 
> 40000000-7fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
> 80000000-800fffff : reserved
> 80100000-13fffffff : System RAM
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> If I remove the 'no-map' qualifier from DT, I get this:
> 
> 40000000-13fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
>   80000000-800fffff : reserved
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> So this does seem to be working fine on my setup. I'll try again with
> 5.4 to see if I can repro.

I just ran the same experiment on v5.4.102 which is where the
regression was reported, and I'm seeing the same correct result...

> Also, 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already
> reserved regions") looks more likely to cause the issue observed here,
> but that shouldn't be silent. I get the following error message in dmesg
> if I if place the no-map region on top of the kernel image:
> 
> OF: fdt: Reserved memory: failed to reserve memory for node 'foobar@40210000': base 0x0000000040210000, size 1 MiB
> 
> Is that triggering on your end?

So that really sounds like the cause of the issue here, though arguably
this should be indicative a something funny in the DT.

Thanks,
Quentin

WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <qperret@google.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Alexandre TORGUE <alexandre.torgue@foss.st.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>, stable <stable@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	KarimAllah Ahmed <karahmed@amazon.de>,
	Android Kernel Team <kernel-team@android.com>,
	Architecture Mailman List <boot-architecture@lists.linaro.org>,
	Frank Rowand <frowand.list@gmail.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region
Date: Wed, 21 Apr 2021 08:45:42 +0000	[thread overview]
Message-ID: <YH/mNosARuC1KiuY@google.com> (raw)
In-Reply-To: <YH/ixPnHMxNo08mJ@google.com>

On Wednesday 21 Apr 2021 at 08:31:00 (+0000), Quentin Perret wrote:
> FWIW I did test this on Qemu before posting. With 5.12-rc8 and a 1MiB
> no-map region at 0x80000000, I have the following:
> 
> 40000000-7fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
> 80000000-800fffff : reserved
> 80100000-13fffffff : System RAM
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> If I remove the 'no-map' qualifier from DT, I get this:
> 
> 40000000-13fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
>   80000000-800fffff : reserved
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> So this does seem to be working fine on my setup. I'll try again with
> 5.4 to see if I can repro.

I just ran the same experiment on v5.4.102 which is where the
regression was reported, and I'm seeing the same correct result...

> Also, 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already
> reserved regions") looks more likely to cause the issue observed here,
> but that shouldn't be silent. I get the following error message in dmesg
> if I if place the no-map region on top of the kernel image:
> 
> OF: fdt: Reserved memory: failed to reserve memory for node 'foobar@40210000': base 0x0000000040210000, size 1 MiB
> 
> Is that triggering on your end?

So that really sounds like the cause of the issue here, though arguably
this should be indicative a something funny in the DT.

Thanks,
Quentin

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

  reply	other threads:[~2021-04-21  8:45 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20 14:02 [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region Alexandre TORGUE
2021-04-20 14:45 ` Rob Herring
2021-04-20 15:12   ` Alexandre TORGUE
2021-04-20 15:54     ` Rob Herring
2021-04-20 15:54       ` Rob Herring
2021-04-20 16:10       ` Ard Biesheuvel
2021-04-20 16:10         ` Ard Biesheuvel
2021-04-20 16:33         ` Florian Fainelli
2021-04-20 16:33           ` Florian Fainelli
2021-04-21  8:31           ` Quentin Perret
2021-04-21  8:31             ` Quentin Perret
2021-04-21  8:45             ` Quentin Perret [this message]
2021-04-21  8:45               ` Quentin Perret
2021-04-21 14:33             ` Florian Fainelli
2021-04-21 14:33               ` Florian Fainelli
2021-04-21 15:17               ` Florian Fainelli
2021-04-21 15:17                 ` Florian Fainelli
2021-04-22 13:03                 ` Quentin Perret
2021-04-22 13:03                   ` Quentin Perret
2021-04-22 12:59               ` Quentin Perret
2021-04-22 12:59                 ` Quentin Perret
2021-05-07 15:15                 ` Alexandre TORGUE
2021-05-07 15:15                   ` Alexandre TORGUE
2021-05-10 10:09                   ` Quentin Perret
2021-05-10 10:09                     ` Quentin Perret
2021-05-12 10:55                     ` Alexandre TORGUE
2021-05-12 10:55                       ` Alexandre TORGUE
2021-05-12 12:34                       ` Quentin Perret
2021-05-12 12:34                         ` Quentin Perret
2021-05-12 12:44                         ` Alexandre TORGUE
2021-05-12 12:44                           ` Alexandre TORGUE
2021-04-20 21:05         ` Rob Herring
2021-04-20 21:05           ` Rob Herring

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=YH/mNosARuC1KiuY@google.com \
    --to=qperret@google.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=boot-architecture@lists.linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=f.fainelli@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=karahmed@amazon.de \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=swboyd@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.