lkml.org 
[lkml]   [2019]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
From
Date


> On Aug 21, 2019, at 9:31 PM, Baoquan He <bhe@redhat.com> wrote:
>
> On 08/21/19 at 05:12pm, Qian Cai wrote:
>>>> Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has
>>>> regressed. Effectively we need to find what is causing the kernel to
>>>> sometimes be placed in the middle of a custom reserved memmap= range.
>>>
>>> Yes, disabling KASLR works good so far. Assuming the workaround, i.e.,
>>> f28442497b5c
>>> (“x86/boot: Fix KASLR and memmap= collision”) is correct.
>>>
>>> The only other commit that might regress it from my research so far is,
>>>
>>> d52e7d5a952c ("x86/KASLR: Parse all 'memmap=' boot option entries”)
>>>
>>
>> It turns out that the origin commit f28442497b5c (“x86/boot: Fix KASLR and
>> memmap= collision”) has a bug that is unable to handle "memmap=" in
>> CONFIG_CMDLINE instead of a parameter in bootloader because when it (as well as
>> the commit d52e7d5a952c) calls get_cmd_line_ptr() in order to run
>> mem_avoid_memmap(), "boot_params" has no knowledge of CONFIG_CMDLINE. Only later
>> in setup_arch(), the kernel will deal with parameters over there.
>
> Yes, we didn't consider CONFIG_CMDLINE during boot compressing stage. It
> should be a generic issue since other parameters from CONFIG_CMDLINE could
> be ignored too, not only KASLR handling. Would you like to cast a patch
> to fix it? Or I can fix it later, maybe next week.

I think you have more experience than me in this area, so if you have time to fix it, that
would be nice.

\
 
 \ /
  Last update: 2019-08-22 03:52    [W:0.041 / U:4.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site