Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Shiji Yang <yangshiji66@outlook.com>
To: tsbogend@alpha.franken.de
Cc: arnd@arndb.de, bhe@redhat.com, fancer.lancer@gmail.com,
	gregkh@linuxfoundation.org, javierm@redhat.com,
	jiaxun.yang@flygoat.com, khalid@gonehiking.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	namiltd@yahoo.com, yangshiji66@outlook.com
Subject: Re: [PATCH V2] mips: kernel: fix detect_memory_region() function
Date: Sat, 29 Jun 2024 13:19:01 +0800	[thread overview]
Message-ID: <TYCP286MB08959EDF4C5BD304E3A292C5BCD12@TYCP286MB0895.JPNP286.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <Znp3JKF6UUn2YuvL@alpha.franken.de>

On Tue, 25 Jun 2024 09:46:34 +0200, Thomas Bogendoerfer wrote:
>>  	for (size = sz_min; size < sz_max; size <<= 1) {
>> -		if (!memcmp(dm, dm + size, sizeof(detect_magic)))
>> -			break;
>> +		__raw_writel(MIPS_MEM_TEST_PATTERN, dm);
>> +		if (__raw_readl(dm) == __raw_readl(dm + size)) {
>> +			__raw_writel(~MIPS_MEM_TEST_PATTERN, dm);
>> +			if (__raw_readl(dm) == __raw_readl(dm + size))
>> +				break;
>> +		}
>
>you are testing memory, so just use pointers. __raw_readl and __raw_writel
>are for io regions (which should be ioremppaed before usage).

Fixed in v3:
https://lore.kernel.org/linux-mips/TYCP286MB0895F65439037ED134FEA7DDBCD12@TYCP286MB0895.JPNP286.PROD.OUTLOOK.COM/


>
>> The detect_memory_region() has been broken on 6.6 kernel[1]. This
>> patch fixes it by:
>> 1. Do not use memcmp() on unallocated memory, as the new introduced
>>    fortify dynamic object size check[2] will return unexpected result.
>
>hmm, so there should a new way for doing memory probing without
>triggering this fortify check. How do other platforms deal with this ?

I guess __builtin_memcmp() should work. But this patch also fixes a
potential wrong memory size issue[1] by fliping magic number and
double checking it. And there is no need to ues memcmp() to check
an u32 variable.

It seems that other ARCHs directly read some registers to judge
the memory size. However, the theory in mips ARCH is checking the
overlapping memory address.

>
>> 2. Use a fixed pattern instead of a random function pointer as the
>>    magic value.
>
>why is this better ?

Just engineering experience. Byte 0xaa/0x55 has the largest information
entropy and is widely used in memory testing. Most codes in v2 patch
are copied from 'arch/mips/ralink/mt7621.c'.

>
>Thomas.
>

[1] https://github.com/openwrt/openwrt/pull/14282


Regards,
Shiji Yang

  reply	other threads:[~2024-06-29  5:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25  1:44 [PATCH V2] mips: kernel: fix detect_memory_region() function Shiji Yang
2024-06-25  1:58 ` Jiaxun Yang
2024-06-29  4:56   ` Shiji Yang
2024-06-25  7:46 ` Thomas Bogendoerfer
2024-06-25  7:52 ` Thomas Bogendoerfer
2024-06-29  5:19   ` Shiji Yang [this message]
2024-06-28 16:07 ` kernel test robot

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=TYCP286MB08959EDF4C5BD304E3A292C5BCD12@TYCP286MB0895.JPNP286.PROD.OUTLOOK.COM \
    --to=yangshiji66@outlook.com \
    --cc=arnd@arndb.de \
    --cc=bhe@redhat.com \
    --cc=fancer.lancer@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=javierm@redhat.com \
    --cc=jiaxun.yang@flygoat.com \
    --cc=khalid@gonehiking.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=namiltd@yahoo.com \
    --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