| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <537362A0.7030803@huawei.com>
Date: Wed, 14 May 2014 20:33:36 +0800
From: Liu hua <sdu.liu@...wei.com>
To: Atsushi Kumagai <kumagai-atsushi@....nes.nec.co.jp>,
"linux@....linux.org.uk" <linux@....linux.org.uk>
CC: "will.deacon@....com" <will.deacon@....com>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"wangnan0@...wei.com" <wangnan0@...wei.com>,
"peifeiyue@...wei.com" <peifeiyue@...wei.com>,
"liusdu@....com" <liusdu@....com>
Subject: Re: [RFC PATCH 2/2] makedumpfile: get additional information from
vmcore
δΊ 2014/5/14 15:53, Atsushi Kumagai ει:
>> On 2014/5/13 14:21, Atsushi Kumagai wrote:
>>> Hello Liu,
>>>
>>>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as
>>>> macros. So if we deal with vmcores with different values
>>>> of these two macros. We have to recompile makedumpfile.
>>>
>>> There are other macros which have architecture-specific values
>>> (e.g. __PAGE_OFFSET), and some functions are specific to each
>>> architecture (e.g. vaddr_to_paddr()), so we need recompilation
>>> eventually.
>>>
>>> OTOH, we already don't need recompilation for the same architecture
>>> since the values of such macros are defined for each kernel version
>>> like below:
>>>
>>> #ifdef __x86_64__
>>> ...
>>> #define _MAX_PHYSMEM_BITS_ORIG (40)
>>> #define _MAX_PHYSMEM_BITS_2_6_26 (44)
>>> #define _MAX_PHYSMEM_BITS_2_6_31 (46)
>>>
>>> So I don't think this patch is valuable.
>>
>> Hi Atsushi,
>>
>> For x86, it is not necessory. But for arm, different venders
>> may define different SECTION_SIZE_BITS. for example:
>>
>> 1 arch/arm/mach-clps711x/include/mach/memory.h
>> #define SECTION_SIZE_BITS 24
>> 2 arch/arm/mach-exynos/include/mach/memory.h
>> #define SECTION_SIZE_BITS 28
>> 4 arch/arm/mach-hisi/include/mach/memory.h
>> #define SECTION_SIZE_BITS 26
>> 8 arch/arm/mach-sa1100/include/mach/memory.h
>> #define SECTION_SIZE_BITS 27
>>
>> Perhaps we should find another way to let the userspace tools
>> to get the architecture-specific values.
>
> I see, I think this description is better than the first one.
>
> Now, makedumpfile can't get an appropriate values of the two macros since the
> values are variable even if the architecture and the kernel version are fixed
> (at least for arm), and we can't solve this without *manual code fixing*, right?
>
> In practice, the current code expects that all arm machines adopt Exynos
> processors, this is an problem definitely.
>
> #ifdef __arm__
> #define KVBASE_MASK (0xffff)
> #define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK)
> #define _SECTION_SIZE_BITS (28)
> #define _MAX_PHYSMEM_BITS (32)
>
> I think it's better to fix the descriptions to get acceptability,
> but this patch is necessary from the view point of makedumpfile.
> So I recommend you to repost this patch set, then I'll accept it.
>
Ok, Thanks for you suggest. I will repost this patch. By now no one
relpy my kernel patch related to this issue, named "[RFC PATCH 1/2]
kdump: add sparse memory related values to vmcore". Didn't I cc
the right person or something else?
BTW, For patch "[PATCH] makedumpfile: ARM: get correct mem_map offset",
Did I explain my idea clearly ? If not, I would like repost one with
more details.
Thanks,
Liu Hua
>
> Thanks
> Atsushi Kumagai
>
>>>
>>>> This patch makes makedumpfile get these two values from
>>>> vmcore info, if existing. It makes the makedumpfile more
>>>> compatible to vmcores with different section size.
>>>>
>>>> Signed-off-by: Liu Hua <sdu.liu@...wei.com>
>>>> ---
>>>> makedumpfile.c | 17 +++++++++++++++++
>>>> makedumpfile.h | 2 ++
>>>> 2 files changed, 19 insertions(+)
>>>>
>>>> diff --git a/makedumpfile.c b/makedumpfile.c
>>>> index 6cf6e24..3cdf323 100644
>>>> --- a/makedumpfile.c
>>>> +++ b/makedumpfile.c
>>>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void)
>>>> READ_NUMBER("PG_slab", PG_slab);
>>>> READ_NUMBER("PG_buddy", PG_buddy);
>>>> READ_NUMBER("PG_hwpoison", PG_hwpoison);
>>>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS);
>>>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS);
>>>>
>>>> READ_SRCFILE("pud_t", pud_t);
>>>>
>>>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void)
>>>> }
>>>>
>>>> int
>>>> +calibrate_machdep_info(void)
>>>> +{
>>>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0)
>>>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
>>>> +
>>>> + if (NUMBER(SECTION_SIZE_BITS) > 0)
>>>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS);
>>>> +
>>>> + return TRUE;
>>>> +}
>>>> +
>>>> +int
>>>> initial(void)
>>>> {
>>>> off_t offset;
>>>> @@ -3214,6 +3228,9 @@ out:
>>>> if (debug_info && !get_machdep_info())
>>>> return FALSE;
>>>>
>>>> + if (debug_info && !calibrate_machdep_info())
>>>> + return FALSE;
>>>> +
>>>> if (is_xen_memory() && !get_dom0_mapnr())
>>>> return FALSE;
>>>>
>>>> diff --git a/makedumpfile.h b/makedumpfile.h
>>>> index eb03688..7acb23a 100644
>>>> --- a/makedumpfile.h
>>>> +++ b/makedumpfile.h
>>>> @@ -1434,6 +1434,8 @@ struct number_table {
>>>> long PG_hwpoison;
>>>>
>>>> long PAGE_BUDDY_MAPCOUNT_VALUE;
>>>> + long SECTION_SIZE_BITS;
>>>> + long MAX_PHYSMEM_BITS;
>>>> };
>>>>
>>>> struct srcfile_table {
>>>> --
>>>> 1.9.0
>>>
>>> .
>>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists