From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>,
linux-mips@vger.kernel.org, Paul Burton <paulburton@kernel.org>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] MIPS: reserve the memblock right after the kernel
Date: Mon, 9 Nov 2020 12:08:03 +0100 [thread overview]
Message-ID: <27310707-78d5-0f96-7048-749db4959a07@nokia.com> (raw)
In-Reply-To: <1d6a424e-944e-7f21-1f30-989fb61018a8@nokia.com>
Hi Thomas,
On 09/11/2020 11:34, Alexander Sverdlin wrote:
>>> Linux doesn't own the memory immediately after the kernel image. On Octeon
>>> bootloader places a shared structure right close after the kernel _end,
>>> refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c.
>>>
>>> If check_kernel_sections_mem() rounds the PFNs up, first memblock_alloc()
>>> inside early_init_dt_alloc_memory_arch() <= device_tree_init() returns
>>> memory block overlapping with the above octeon_bootinfo structure, which
>>> is being overwritten afterwards.
>> as this special for Octeon how about added the memblock_reserve
>> in octen specific code ?
> while the shared structure which is being corrupted is indeed Octeon-specific,
> the wrong assumption that the memory right after the kernel can be allocated by memblock
> allocator and re-used somewhere in Linux is in MIPS-generic check_kernel_sections_mem().
>
> I personally will be fine with repairing Octeon only as I don't have other MIPS
> targets to care about, but maybe someone else in the MIPS community will find
> this fix useful...
another reason for not putting that to Octeon platform code was the fact, that one
would need to put the knowledge about wrong assumption of ARCH (MIPS) code into
different code area of Octeon platform.
If at some point in time check_kernel_sections_mem() will be altered/fixed, nobody
will understand why Octeon still has this workaround.
--
Best regards,
Alexander Sverdlin.
next prev parent reply other threads:[~2020-11-09 11:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 14:10 [PATCH] MIPS: reserve the memblock right after the kernel Alexander A Sverdlin
2020-11-07 9:40 ` Thomas Bogendoerfer
2020-11-09 10:34 ` Alexander Sverdlin
2020-11-09 11:08 ` Alexander Sverdlin [this message]
2020-11-10 9:55 ` Thomas Bogendoerfer
2020-11-10 10:29 ` Alexander Sverdlin
2020-11-11 14:52 ` Serge Semin
2020-11-13 2:30 ` Jiaxun Yang
2020-11-13 3:28 ` Jinyang He
2020-11-13 3:49 ` Maciej W. Rozycki
2020-11-13 12:29 ` Alexander Sverdlin
2020-11-13 12:56 ` Alexander Sverdlin
2020-11-13 9:17 ` Alexander Sverdlin
2020-11-13 13:09 ` Alexander Sverdlin
2020-11-16 22:31 ` Serge Semin
2020-11-17 9:41 ` Alexander Sverdlin
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=27310707-78d5-0f96-7048-749db4959a07@nokia.com \
--to=alexander.sverdlin@nokia.com \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paulburton@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
/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;
as well as URLs for NNTP newsgroup(s).