Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
于 2013年03月09日 11:46, HATAYAMA Daisuke 写道:
> From: Yanfei Zhang
> Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes
> in page-size boundary
> Date: Fri, 8 Mar 2013 21:02:50 +0800
>
>> 2013/3/8 HATAYAMA Daisuke :
>>> From: Zhang Yanfei
>>> Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD
>>> notes in page-size boundary
>>> Date: Thu, 7 Mar 2013 18:11:30 +0800
>>>
>>>> 于 2013年03月02日 16:37, HATAYAMA Daisuke 写道:
>>>>> Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
>>>>> note type to make them satisfy mmap()'s page-size boundary
>>>>> requirement.
>>>>>
>>>>> So far, end of note segments has been marked by zero-filled elf
>>>>> header. Instead, this patch writes NT_VMCORE_PAD note in the end of
>>>>> note segments until the offset on page-size boundary.
>>>>
>>>>
>>>> In the codes below, it seems that you assign name "VMCOREINFO" for
>>>> note type NT_VMCORE_PAD, right? This is kind of wired, i think. This
>>>> name has been used for NT_VMCORE_DEBUGINFO note already. Why not something
>>>> like "VMCOREPAD" or "PAD"?
>>>>
>>>
>>> It looks you are confusing or don't know name and type. The name is
>>> namespace and in the namespace, there are multiple note types, each of
>>> which has the corresponding data. In other words, data corresponding
>>> to types differ if they belong to differnet name space even if
>>> integers of the types are coincide with.
>>
>> Yes, I knew this. Just as the spec said " a program must recognize both the
>> name
>> and the type to recognize a descriptor.". But I cannot understand what your
>> word
>> "namespace" came from? I think you complicate simple things here.
>>
>> Only with a type, we cannot recognize a descriptor, because "multiple
>> interpretations of
>> a single type value may exist", So we should combine the name and the type
>> together. If both the name and type of two descriptors are the same,
>> we could say we
>> have two same descriptors. If one of them (type or name) are
>> different, we say the
>> two descriptors are different and the two notes have different data.
>>
>> If I am wrong, please correct me.
>
> ??? I think you're saying here the same thing as my explanation above.
>
> Although the term ''name space'' never occurs in ELF, it seems to me
> standard to represent the same values as different ones by combining
> additional elements as names to them.
>
> Well, formally, it is represented as simply tuples or vector
> space. For example, support set S and S' and define new set S x S' by
>
> S x S' := { (s, s') | s in S, s' in S' }
>
> and equality of the S x S' are defined as usual:
>
> (s1, s1') == (s2, s2') iff s1 == s2 and s1' == s2'.
>
> In ELF, S is names and S' is types. There's no other formal meaning
> there.
>
>>>
>>> The "VMCOREINFO" name represents information exported from
>>> /proc/vmcore that is used in kdump framework. In this sense,
>>> NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework,
>>> should belong to the "VMCOREINFO" name.
>>
>> I cannot understand the name explanation totally. Does the name really
>> have this meaning? Is there any authentic document? I was always thinking we
>> could feel free to name a name by ourselves!
>
> Of course, it's optional for you to decide how to name notes within
> the mechanism. But it's important to treat naming for ease of managing
> note types. In addition to the above formal definition, it's important
> to consider what name gives us. It's readability, telling us that note
> types that belong to unique name are treated in common in the sense of
> the name. This is apart from the formal definition above.
>
> It's certainly possible to distinguish notes by giving names only and
> not giving types. For example, imagine there are new 27 notes and they
> have different names but have 0 as type.
>
> name type
> "SOME_NOTE_A" 0
> "SOME_NOTE_B" 0
> ...
> "SOME_NOTE_Z" 0
>
> Also, for example,
>
> nametype
> "SOME_NOTE" 0 => NT_SOME_NOTE_A
> "SOME_NOTE" 1 => NT_SOME_NOTE_B
> ...
> "SOME_NOTE" 26=> NT_SOME_NOTE_Z
>
> For the former case, it *looks to me* that space of time is not used
> effectively and it *looks to me* that space of name is not consumed
> efficiently.
>
> After all, it amounts to individual preference about naming. I cannot
> say anything more.
>
I see. I know what you mean now. I was just surprised and puzzled about your
"namespace" concept.
Other than the name of NT_VMCORE_PAD, no complaints about the code.
Reviewed-by: Zhang Yanfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
于 2013年03月09日 11:46, HATAYAMA Daisuke 写道:
From: Yanfei Zhang zhangyanfei@gmail.com
Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes
in page-size boundary
Date: Fri, 8 Mar 2013 21:02:50 +0800
2013/3/8 HATAYAMA Daisuke d.hatay...@jp.fujitsu.com:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD
notes in page-size boundary
Date: Thu, 7 Mar 2013 18:11:30 +0800
于 2013年03月02日 16:37, HATAYAMA Daisuke 写道:
Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
note type to make them satisfy mmap()'s page-size boundary
requirement.
So far, end of note segments has been marked by zero-filled elf
header. Instead, this patch writes NT_VMCORE_PAD note in the end of
note segments until the offset on page-size boundary.
In the codes below, it seems that you assign name VMCOREINFO for
note type NT_VMCORE_PAD, right? This is kind of wired, i think. This
name has been used for NT_VMCORE_DEBUGINFO note already. Why not something
like VMCOREPAD or PAD?
It looks you are confusing or don't know name and type. The name is
namespace and in the namespace, there are multiple note types, each of
which has the corresponding data. In other words, data corresponding
to types differ if they belong to differnet name space even if
integers of the types are coincide with.
Yes, I knew this. Just as the spec said a program must recognize both the
name
and the type to recognize a descriptor.. But I cannot understand what your
word
namespace came from? I think you complicate simple things here.
Only with a type, we cannot recognize a descriptor, because multiple
interpretations of
a single type value may exist, So we should combine the name and the type
together. If both the name and type of two descriptors are the same,
we could say we
have two same descriptors. If one of them (type or name) are
different, we say the
two descriptors are different and the two notes have different data.
If I am wrong, please correct me.
??? I think you're saying here the same thing as my explanation above.
Although the term ''name space'' never occurs in ELF, it seems to me
standard to represent the same values as different ones by combining
additional elements as names to them.
Well, formally, it is represented as simply tuples or vector
space. For example, support set S and S' and define new set S x S' by
S x S' := { (s, s') | s in S, s' in S' }
and equality of the S x S' are defined as usual:
(s1, s1') == (s2, s2') iff s1 == s2 and s1' == s2'.
In ELF, S is names and S' is types. There's no other formal meaning
there.
The VMCOREINFO name represents information exported from
/proc/vmcore that is used in kdump framework. In this sense,
NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework,
should belong to the VMCOREINFO name.
I cannot understand the name explanation totally. Does the name really
have this meaning? Is there any authentic document? I was always thinking we
could feel free to name a name by ourselves!
Of course, it's optional for you to decide how to name notes within
the mechanism. But it's important to treat naming for ease of managing
note types. In addition to the above formal definition, it's important
to consider what name gives us. It's readability, telling us that note
types that belong to unique name are treated in common in the sense of
the name. This is apart from the formal definition above.
It's certainly possible to distinguish notes by giving names only and
not giving types. For example, imagine there are new 27 notes and they
have different names but have 0 as type.
name type
SOME_NOTE_A 0
SOME_NOTE_B 0
...
SOME_NOTE_Z 0
Also, for example,
nametype
SOME_NOTE 0 = NT_SOME_NOTE_A
SOME_NOTE 1 = NT_SOME_NOTE_B
...
SOME_NOTE 26= NT_SOME_NOTE_Z
For the former case, it *looks to me* that space of time is not used
effectively and it *looks to me* that space of name is not consumed
efficiently.
After all, it amounts to individual preference about naming. I cannot
say anything more.
I see. I know what you mean now. I was just surprised and puzzled about your
namespace concept.
Other than the name of NT_VMCORE_PAD, no complaints about the code.
Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
From: Yanfei Zhang
Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes
in page-size boundary
Date: Fri, 8 Mar 2013 21:02:50 +0800
> 2013/3/8 HATAYAMA Daisuke :
>> From: Zhang Yanfei
>> Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD
>> notes in page-size boundary
>> Date: Thu, 7 Mar 2013 18:11:30 +0800
>>
>>> 于 2013年03月02日 16:37, HATAYAMA Daisuke 写道:
>>>> Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
>>>> note type to make them satisfy mmap()'s page-size boundary
>>>> requirement.
>>>>
>>>> So far, end of note segments has been marked by zero-filled elf
>>>> header. Instead, this patch writes NT_VMCORE_PAD note in the end of
>>>> note segments until the offset on page-size boundary.
>>>
>>>
>>> In the codes below, it seems that you assign name "VMCOREINFO" for
>>> note type NT_VMCORE_PAD, right? This is kind of wired, i think. This
>>> name has been used for NT_VMCORE_DEBUGINFO note already. Why not something
>>> like "VMCOREPAD" or "PAD"?
>>>
>>
>> It looks you are confusing or don't know name and type. The name is
>> namespace and in the namespace, there are multiple note types, each of
>> which has the corresponding data. In other words, data corresponding
>> to types differ if they belong to differnet name space even if
>> integers of the types are coincide with.
>
> Yes, I knew this. Just as the spec said " a program must recognize both the
> name
> and the type to recognize a descriptor.". But I cannot understand what your
> word
> "namespace" came from? I think you complicate simple things here.
>
> Only with a type, we cannot recognize a descriptor, because "multiple
> interpretations of
> a single type value may exist", So we should combine the name and the type
> together. If both the name and type of two descriptors are the same,
> we could say we
> have two same descriptors. If one of them (type or name) are
> different, we say the
> two descriptors are different and the two notes have different data.
>
> If I am wrong, please correct me.
??? I think you're saying here the same thing as my explanation above.
Although the term ''name space'' never occurs in ELF, it seems to me
standard to represent the same values as different ones by combining
additional elements as names to them.
Well, formally, it is represented as simply tuples or vector
space. For example, support set S and S' and define new set S x S' by
S x S' := { (s, s') | s in S, s' in S' }
and equality of the S x S' are defined as usual:
(s1, s1') == (s2, s2') iff s1 == s2 and s1' == s2'.
In ELF, S is names and S' is types. There's no other formal meaning
there.
>>
>> The "VMCOREINFO" name represents information exported from
>> /proc/vmcore that is used in kdump framework. In this sense,
>> NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework,
>> should belong to the "VMCOREINFO" name.
>
> I cannot understand the name explanation totally. Does the name really
> have this meaning? Is there any authentic document? I was always thinking we
> could feel free to name a name by ourselves!
Of course, it's optional for you to decide how to name notes within
the mechanism. But it's important to treat naming for ease of managing
note types. In addition to the above formal definition, it's important
to consider what name gives us. It's readability, telling us that note
types that belong to unique name are treated in common in the sense of
the name. This is apart from the formal definition above.
It's certainly possible to distinguish notes by giving names only and
not giving types. For example, imagine there are new 27 notes and they
have different names but have 0 as type.
name type
"SOME_NOTE_A" 0
"SOME_NOTE_B" 0
...
"SOME_NOTE_Z" 0
Also, for example,
nametype
"SOME_NOTE" 0 => NT_SOME_NOTE_A
"SOME_NOTE" 1 => NT_SOME_NOTE_B
...
"SOME_NOTE" 26=> NT_SOME_NOTE_Z
For the former case, it *looks to me* that space of time is not used
effectively and it *looks to me* that space of name is not consumed
efficiently.
After all, it amounts to individual preference about naming. I cannot
say anything more.
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
2013/3/8 HATAYAMA Daisuke : > From: Zhang Yanfei > Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes > in page-size boundary > Date: Thu, 7 Mar 2013 18:11:30 +0800 > >> 于 2013年03月02日 16:37, HATAYAMA Daisuke 写道: >>> Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD >>> note type to make them satisfy mmap()'s page-size boundary >>> requirement. >>> >>> So far, end of note segments has been marked by zero-filled elf >>> header. Instead, this patch writes NT_VMCORE_PAD note in the end of >>> note segments until the offset on page-size boundary. >> >> >> In the codes below, it seems that you assign name "VMCOREINFO" for >> note type NT_VMCORE_PAD, right? This is kind of wired, i think. This >> name has been used for NT_VMCORE_DEBUGINFO note already. Why not something >> like "VMCOREPAD" or "PAD"? >> > > It looks you are confusing or don't know name and type. The name is > namespace and in the namespace, there are multiple note types, each of > which has the corresponding data. In other words, data corresponding > to types differ if they belong to differnet name space even if > integers of the types are coincide with. Yes, I knew this. Just as the spec said " a program must recognize both the name and the type to recognize a descriptor.". But I cannot understand what your word "namespace" came from? I think you complicate simple things here. Only with a type, we cannot recognize a descriptor, because "multiple interpretations of a single type value may exist", So we should combine the name and the type together. If both the name and type of two descriptors are the same, we could say we have two same descriptors. If one of them (type or name) are different, we say the two descriptors are different and the two notes have different data. If I am wrong, please correct me. > > The "VMCOREINFO" name represents information exported from > /proc/vmcore that is used in kdump framework. In this sense, > NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework, > should belong to the "VMCOREINFO" name. I cannot understand the name explanation totally. Does the name really have this meaning? Is there any authentic document? I was always thinking we could feel free to name a name by ourselves! > > Thanks. > HATAYAMA, Daisuke > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
2013/3/8 HATAYAMA Daisuke d.hatay...@jp.fujitsu.com: From: Zhang Yanfei zhangyan...@cn.fujitsu.com Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary Date: Thu, 7 Mar 2013 18:11:30 +0800 于 2013年03月02日 16:37, HATAYAMA Daisuke 写道: Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD note type to make them satisfy mmap()'s page-size boundary requirement. So far, end of note segments has been marked by zero-filled elf header. Instead, this patch writes NT_VMCORE_PAD note in the end of note segments until the offset on page-size boundary. In the codes below, it seems that you assign name VMCOREINFO for note type NT_VMCORE_PAD, right? This is kind of wired, i think. This name has been used for NT_VMCORE_DEBUGINFO note already. Why not something like VMCOREPAD or PAD? It looks you are confusing or don't know name and type. The name is namespace and in the namespace, there are multiple note types, each of which has the corresponding data. In other words, data corresponding to types differ if they belong to differnet name space even if integers of the types are coincide with. Yes, I knew this. Just as the spec said a program must recognize both the name and the type to recognize a descriptor.. But I cannot understand what your word namespace came from? I think you complicate simple things here. Only with a type, we cannot recognize a descriptor, because multiple interpretations of a single type value may exist, So we should combine the name and the type together. If both the name and type of two descriptors are the same, we could say we have two same descriptors. If one of them (type or name) are different, we say the two descriptors are different and the two notes have different data. If I am wrong, please correct me. The VMCOREINFO name represents information exported from /proc/vmcore that is used in kdump framework. In this sense, NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework, should belong to the VMCOREINFO name. I cannot understand the name explanation totally. Does the name really have this meaning? Is there any authentic document? I was always thinking we could feel free to name a name by ourselves! Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
From: Yanfei Zhang zhangyanfei@gmail.com
Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes
in page-size boundary
Date: Fri, 8 Mar 2013 21:02:50 +0800
2013/3/8 HATAYAMA Daisuke d.hatay...@jp.fujitsu.com:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD
notes in page-size boundary
Date: Thu, 7 Mar 2013 18:11:30 +0800
于 2013年03月02日 16:37, HATAYAMA Daisuke 写道:
Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
note type to make them satisfy mmap()'s page-size boundary
requirement.
So far, end of note segments has been marked by zero-filled elf
header. Instead, this patch writes NT_VMCORE_PAD note in the end of
note segments until the offset on page-size boundary.
In the codes below, it seems that you assign name VMCOREINFO for
note type NT_VMCORE_PAD, right? This is kind of wired, i think. This
name has been used for NT_VMCORE_DEBUGINFO note already. Why not something
like VMCOREPAD or PAD?
It looks you are confusing or don't know name and type. The name is
namespace and in the namespace, there are multiple note types, each of
which has the corresponding data. In other words, data corresponding
to types differ if they belong to differnet name space even if
integers of the types are coincide with.
Yes, I knew this. Just as the spec said a program must recognize both the
name
and the type to recognize a descriptor.. But I cannot understand what your
word
namespace came from? I think you complicate simple things here.
Only with a type, we cannot recognize a descriptor, because multiple
interpretations of
a single type value may exist, So we should combine the name and the type
together. If both the name and type of two descriptors are the same,
we could say we
have two same descriptors. If one of them (type or name) are
different, we say the
two descriptors are different and the two notes have different data.
If I am wrong, please correct me.
??? I think you're saying here the same thing as my explanation above.
Although the term ''name space'' never occurs in ELF, it seems to me
standard to represent the same values as different ones by combining
additional elements as names to them.
Well, formally, it is represented as simply tuples or vector
space. For example, support set S and S' and define new set S x S' by
S x S' := { (s, s') | s in S, s' in S' }
and equality of the S x S' are defined as usual:
(s1, s1') == (s2, s2') iff s1 == s2 and s1' == s2'.
In ELF, S is names and S' is types. There's no other formal meaning
there.
The VMCOREINFO name represents information exported from
/proc/vmcore that is used in kdump framework. In this sense,
NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework,
should belong to the VMCOREINFO name.
I cannot understand the name explanation totally. Does the name really
have this meaning? Is there any authentic document? I was always thinking we
could feel free to name a name by ourselves!
Of course, it's optional for you to decide how to name notes within
the mechanism. But it's important to treat naming for ease of managing
note types. In addition to the above formal definition, it's important
to consider what name gives us. It's readability, telling us that note
types that belong to unique name are treated in common in the sense of
the name. This is apart from the formal definition above.
It's certainly possible to distinguish notes by giving names only and
not giving types. For example, imagine there are new 27 notes and they
have different names but have 0 as type.
name type
SOME_NOTE_A 0
SOME_NOTE_B 0
...
SOME_NOTE_Z 0
Also, for example,
nametype
SOME_NOTE 0 = NT_SOME_NOTE_A
SOME_NOTE 1 = NT_SOME_NOTE_B
...
SOME_NOTE 26= NT_SOME_NOTE_Z
For the former case, it *looks to me* that space of time is not used
effectively and it *looks to me* that space of name is not consumed
efficiently.
After all, it amounts to individual preference about naming. I cannot
say anything more.
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
From: Zhang Yanfei Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary Date: Thu, 7 Mar 2013 18:11:30 +0800 > 于 2013年03月02日 16:37, HATAYAMA Daisuke 写道: >> Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD >> note type to make them satisfy mmap()'s page-size boundary >> requirement. >> >> So far, end of note segments has been marked by zero-filled elf >> header. Instead, this patch writes NT_VMCORE_PAD note in the end of >> note segments until the offset on page-size boundary. > > > In the codes below, it seems that you assign name "VMCOREINFO" for > note type NT_VMCORE_PAD, right? This is kind of wired, i think. This > name has been used for NT_VMCORE_DEBUGINFO note already. Why not something > like "VMCOREPAD" or "PAD"? > It looks you are confusing or don't know name and type. The name is namespace and in the namespace, there are multiple note types, each of which has the corresponding data. In other words, data corresponding to types differ if they belong to differnet name space even if integers of the types are coincide with. The "VMCOREINFO" name represents information exported from /proc/vmcore that is used in kdump framework. In this sense, NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework, should belong to the "VMCOREINFO" name. Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
于 2013年03月02日 16:37, HATAYAMA Daisuke 写道:
> Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
> note type to make them satisfy mmap()'s page-size boundary
> requirement.
>
> So far, end of note segments has been marked by zero-filled elf
> header. Instead, this patch writes NT_VMCORE_PAD note in the end of
> note segments until the offset on page-size boundary.
In the codes below, it seems that you assign name "VMCOREINFO" for
note type NT_VMCORE_PAD, right? This is kind of wired, i think. This
name has been used for NT_VMCORE_DEBUGINFO note already. Why not something
like "VMCOREPAD" or "PAD"?
>
> Signed-off-by: HATAYAMA Daisuke
> ---
>
> arch/s390/include/asm/kexec.h |7 --
> include/linux/kexec.h | 12 ++-
> kernel/kexec.c| 46
> ++---
> 3 files changed, 40 insertions(+), 25 deletions(-)
>
> diff --git a/arch/s390/include/asm/kexec.h b/arch/s390/include/asm/kexec.h
> index 694bcd6..2a531ce 100644
> --- a/arch/s390/include/asm/kexec.h
> +++ b/arch/s390/include/asm/kexec.h
> @@ -41,8 +41,8 @@
> /*
> * Size for s390x ELF notes per CPU
> *
> - * Seven notes plus zero note at the end: prstatus, fpregset, timer,
> - * tod_cmp, tod_reg, control regs, and prefix
> + * Seven notes plus note with NT_VMCORE_PAD type at the end: prstatus,
> + * fpregset, timer, tod_cmp, tod_reg, control regs, and prefix
> */
> #define KEXEC_NOTE_BYTES \
> (ALIGN(sizeof(struct elf_note), 4) * 8 + \
> @@ -53,7 +53,8 @@
>ALIGN(sizeof(u64), 4) + \
>ALIGN(sizeof(u32), 4) + \
>ALIGN(sizeof(u64) * 16, 4) + \
> - ALIGN(sizeof(u32), 4) \
> + ALIGN(sizeof(u32), 4) + \
> + VMCOREINFO_NOTE_NAME_BYTES \
> )
>
> /* Provide a dummy definition to avoid build failures. */
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 5113570..6592935 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -47,14 +47,16 @@
> #define KEXEC_CORE_NOTE_NAME_BYTES ALIGN(sizeof(KEXEC_CORE_NOTE_NAME), 4)
> #define KEXEC_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)
> /*
> - * The per-cpu notes area is a list of notes terminated by a "NULL"
> - * note header. For kdump, the code in vmcore.c runs in the context
> - * of the second kernel to combine them into one note.
> + * The per-cpu notes area is a list of notes terminated by a note
> + * header with NT_VMCORE_PAD type. For kdump, the code in vmcore.c
> + * runs in the context of the second kernel to combine them into one
> + * note.
> */
> #ifndef KEXEC_NOTE_BYTES
> #define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
> KEXEC_CORE_NOTE_NAME_BYTES +\
> - KEXEC_CORE_NOTE_DESC_BYTES )
> + KEXEC_CORE_NOTE_DESC_BYTES +\
> + VMCOREINFO_NOTE_NAME_BYTES)
> #endif
>
> /*
> @@ -187,7 +189,7 @@ extern struct kimage *kexec_crash_image;
> #define VMCOREINFO_NOTE_NAME_BYTES ALIGN(sizeof(VMCOREINFO_NOTE_NAME), 4)
> #define VMCOREINFO_NOTE_SIZE ALIGN(KEXEC_NOTE_HEAD_BYTES*2 \
>+VMCOREINFO_BYTES \
> - +VMCOREINFO_NOTE_NAME_BYTES, \
> + +VMCOREINFO_NOTE_NAME_BYTES*2, \
>PAGE_SIZE)
>
> /* Location of a reserved region to hold the crash kernel.
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 6597b82..fbdc0f0 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -40,6 +40,7 @@
>
> /* Per cpu memory for storing cpu states in case of system crash. */
> note_buf_t __percpu *crash_notes;
> +static size_t crash_notes_size = ALIGN(sizeof(note_buf_t), PAGE_SIZE);
>
> /* vmcoreinfo stuff */
> static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
> @@ -1177,6 +1178,7 @@ unlock:
> return ret;
> }
>
> +/* If @data is NULL, fill @buf with 0 in @data_len bytes. */
> static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
> size_t data_len)
> {
> @@ -1189,26 +1191,36 @@ static u32 *append_elf_note(u32 *buf, char *name,
> unsigned type, void *data,
> buf += (sizeof(note) + 3)/4;
> memcpy(buf, name, note.n_namesz);
> buf += (note.n_namesz + 3)/4;
> - memcpy(buf, data, note.n_descsz);
> + if (data)
> + memcpy(buf, data, note.n_descsz);
> + else
> + memset(buf, 0, note.n_descsz);
> buf += (note.n_descsz + 3)/4;
>
> return buf;
> }
>
> -static void final_note(u32 *buf)
> +static void final_note(u32 *buf, size_t buf_len, size_t data_len)
> {
> - struct elf_note note;
> + size_t used_bytes, pad_hdr_size;
>
> - note.n_namesz = 0;
> - note.n_descsz = 0;
> - note.n_type = 0;
> - memcpy(buf, , sizeof(note));
> + pad_hdr_size =
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
From: Zhang Yanfei zhangyan...@cn.fujitsu.com Subject: Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary Date: Thu, 7 Mar 2013 18:11:30 +0800 于 2013年03月02日 16:37, HATAYAMA Daisuke 写道: Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD note type to make them satisfy mmap()'s page-size boundary requirement. So far, end of note segments has been marked by zero-filled elf header. Instead, this patch writes NT_VMCORE_PAD note in the end of note segments until the offset on page-size boundary. In the codes below, it seems that you assign name VMCOREINFO for note type NT_VMCORE_PAD, right? This is kind of wired, i think. This name has been used for NT_VMCORE_DEBUGINFO note already. Why not something like VMCOREPAD or PAD? It looks you are confusing or don't know name and type. The name is namespace and in the namespace, there are multiple note types, each of which has the corresponding data. In other words, data corresponding to types differ if they belong to differnet name space even if integers of the types are coincide with. The VMCOREINFO name represents information exported from /proc/vmcore that is used in kdump framework. In this sense, NT_VMCORE_PAD that is specific for /proc/vmcore and kdump framework, should belong to the VMCOREINFO name. Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
于 2013年03月02日 16:37, HATAYAMA Daisuke 写道:
Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
note type to make them satisfy mmap()'s page-size boundary
requirement.
So far, end of note segments has been marked by zero-filled elf
header. Instead, this patch writes NT_VMCORE_PAD note in the end of
note segments until the offset on page-size boundary.
In the codes below, it seems that you assign name VMCOREINFO for
note type NT_VMCORE_PAD, right? This is kind of wired, i think. This
name has been used for NT_VMCORE_DEBUGINFO note already. Why not something
like VMCOREPAD or PAD?
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
arch/s390/include/asm/kexec.h |7 --
include/linux/kexec.h | 12 ++-
kernel/kexec.c| 46
++---
3 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/s390/include/asm/kexec.h b/arch/s390/include/asm/kexec.h
index 694bcd6..2a531ce 100644
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -41,8 +41,8 @@
/*
* Size for s390x ELF notes per CPU
*
- * Seven notes plus zero note at the end: prstatus, fpregset, timer,
- * tod_cmp, tod_reg, control regs, and prefix
+ * Seven notes plus note with NT_VMCORE_PAD type at the end: prstatus,
+ * fpregset, timer, tod_cmp, tod_reg, control regs, and prefix
*/
#define KEXEC_NOTE_BYTES \
(ALIGN(sizeof(struct elf_note), 4) * 8 + \
@@ -53,7 +53,8 @@
ALIGN(sizeof(u64), 4) + \
ALIGN(sizeof(u32), 4) + \
ALIGN(sizeof(u64) * 16, 4) + \
- ALIGN(sizeof(u32), 4) \
+ ALIGN(sizeof(u32), 4) + \
+ VMCOREINFO_NOTE_NAME_BYTES \
)
/* Provide a dummy definition to avoid build failures. */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 5113570..6592935 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -47,14 +47,16 @@
#define KEXEC_CORE_NOTE_NAME_BYTES ALIGN(sizeof(KEXEC_CORE_NOTE_NAME), 4)
#define KEXEC_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)
/*
- * The per-cpu notes area is a list of notes terminated by a NULL
- * note header. For kdump, the code in vmcore.c runs in the context
- * of the second kernel to combine them into one note.
+ * The per-cpu notes area is a list of notes terminated by a note
+ * header with NT_VMCORE_PAD type. For kdump, the code in vmcore.c
+ * runs in the context of the second kernel to combine them into one
+ * note.
*/
#ifndef KEXEC_NOTE_BYTES
#define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
KEXEC_CORE_NOTE_NAME_BYTES +\
- KEXEC_CORE_NOTE_DESC_BYTES )
+ KEXEC_CORE_NOTE_DESC_BYTES +\
+ VMCOREINFO_NOTE_NAME_BYTES)
#endif
/*
@@ -187,7 +189,7 @@ extern struct kimage *kexec_crash_image;
#define VMCOREINFO_NOTE_NAME_BYTES ALIGN(sizeof(VMCOREINFO_NOTE_NAME), 4)
#define VMCOREINFO_NOTE_SIZE ALIGN(KEXEC_NOTE_HEAD_BYTES*2 \
+VMCOREINFO_BYTES \
- +VMCOREINFO_NOTE_NAME_BYTES, \
+ +VMCOREINFO_NOTE_NAME_BYTES*2, \
PAGE_SIZE)
/* Location of a reserved region to hold the crash kernel.
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 6597b82..fbdc0f0 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -40,6 +40,7 @@
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
+static size_t crash_notes_size = ALIGN(sizeof(note_buf_t), PAGE_SIZE);
/* vmcoreinfo stuff */
static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
@@ -1177,6 +1178,7 @@ unlock:
return ret;
}
+/* If @data is NULL, fill @buf with 0 in @data_len bytes. */
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
{
@@ -1189,26 +1191,36 @@ static u32 *append_elf_note(u32 *buf, char *name,
unsigned type, void *data,
buf += (sizeof(note) + 3)/4;
memcpy(buf, name, note.n_namesz);
buf += (note.n_namesz + 3)/4;
- memcpy(buf, data, note.n_descsz);
+ if (data)
+ memcpy(buf, data, note.n_descsz);
+ else
+ memset(buf, 0, note.n_descsz);
buf += (note.n_descsz + 3)/4;
return buf;
}
-static void final_note(u32 *buf)
+static void final_note(u32 *buf, size_t buf_len, size_t data_len)
{
- struct elf_note note;
+ size_t used_bytes, pad_hdr_size;
- note.n_namesz = 0;
- note.n_descsz = 0;
- note.n_type = 0;
- memcpy(buf, note, sizeof(note));
+ pad_hdr_size = KEXEC_NOTE_HEAD_BYTES + VMCOREINFO_NOTE_NAME_BYTES;
+
+ /*
+ * keep space for ELF note
[PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
note type to make them satisfy mmap()'s page-size boundary
requirement.
So far, end of note segments has been marked by zero-filled elf
header. Instead, this patch writes NT_VMCORE_PAD note in the end of
note segments until the offset on page-size boundary.
Signed-off-by: HATAYAMA Daisuke
---
arch/s390/include/asm/kexec.h |7 --
include/linux/kexec.h | 12 ++-
kernel/kexec.c| 46 ++---
3 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/s390/include/asm/kexec.h b/arch/s390/include/asm/kexec.h
index 694bcd6..2a531ce 100644
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -41,8 +41,8 @@
/*
* Size for s390x ELF notes per CPU
*
- * Seven notes plus zero note at the end: prstatus, fpregset, timer,
- * tod_cmp, tod_reg, control regs, and prefix
+ * Seven notes plus note with NT_VMCORE_PAD type at the end: prstatus,
+ * fpregset, timer, tod_cmp, tod_reg, control regs, and prefix
*/
#define KEXEC_NOTE_BYTES \
(ALIGN(sizeof(struct elf_note), 4) * 8 + \
@@ -53,7 +53,8 @@
ALIGN(sizeof(u64), 4) + \
ALIGN(sizeof(u32), 4) + \
ALIGN(sizeof(u64) * 16, 4) + \
-ALIGN(sizeof(u32), 4) \
+ALIGN(sizeof(u32), 4) + \
+VMCOREINFO_NOTE_NAME_BYTES \
)
/* Provide a dummy definition to avoid build failures. */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 5113570..6592935 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -47,14 +47,16 @@
#define KEXEC_CORE_NOTE_NAME_BYTES ALIGN(sizeof(KEXEC_CORE_NOTE_NAME), 4)
#define KEXEC_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)
/*
- * The per-cpu notes area is a list of notes terminated by a "NULL"
- * note header. For kdump, the code in vmcore.c runs in the context
- * of the second kernel to combine them into one note.
+ * The per-cpu notes area is a list of notes terminated by a note
+ * header with NT_VMCORE_PAD type. For kdump, the code in vmcore.c
+ * runs in the context of the second kernel to combine them into one
+ * note.
*/
#ifndef KEXEC_NOTE_BYTES
#define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
KEXEC_CORE_NOTE_NAME_BYTES +\
- KEXEC_CORE_NOTE_DESC_BYTES )
+ KEXEC_CORE_NOTE_DESC_BYTES +\
+ VMCOREINFO_NOTE_NAME_BYTES)
#endif
/*
@@ -187,7 +189,7 @@ extern struct kimage *kexec_crash_image;
#define VMCOREINFO_NOTE_NAME_BYTES ALIGN(sizeof(VMCOREINFO_NOTE_NAME), 4)
#define VMCOREINFO_NOTE_SIZE ALIGN(KEXEC_NOTE_HEAD_BYTES*2 \
+VMCOREINFO_BYTES \
-+VMCOREINFO_NOTE_NAME_BYTES, \
++VMCOREINFO_NOTE_NAME_BYTES*2, \
PAGE_SIZE)
/* Location of a reserved region to hold the crash kernel.
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 6597b82..fbdc0f0 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -40,6 +40,7 @@
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
+static size_t crash_notes_size = ALIGN(sizeof(note_buf_t), PAGE_SIZE);
/* vmcoreinfo stuff */
static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
@@ -1177,6 +1178,7 @@ unlock:
return ret;
}
+/* If @data is NULL, fill @buf with 0 in @data_len bytes. */
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
{
@@ -1189,26 +1191,36 @@ static u32 *append_elf_note(u32 *buf, char *name,
unsigned type, void *data,
buf += (sizeof(note) + 3)/4;
memcpy(buf, name, note.n_namesz);
buf += (note.n_namesz + 3)/4;
- memcpy(buf, data, note.n_descsz);
+ if (data)
+ memcpy(buf, data, note.n_descsz);
+ else
+ memset(buf, 0, note.n_descsz);
buf += (note.n_descsz + 3)/4;
return buf;
}
-static void final_note(u32 *buf)
+static void final_note(u32 *buf, size_t buf_len, size_t data_len)
{
- struct elf_note note;
+ size_t used_bytes, pad_hdr_size;
- note.n_namesz = 0;
- note.n_descsz = 0;
- note.n_type = 0;
- memcpy(buf, , sizeof(note));
+ pad_hdr_size = KEXEC_NOTE_HEAD_BYTES + VMCOREINFO_NOTE_NAME_BYTES;
+
+ /*
+* keep space for ELF note header and "VMCOREINFO" name to
+* terminate ELF segment by NT_VMCORE_PAD note.
+*/
+ BUG_ON(data_len + pad_hdr_size > buf_len);
+
+ used_bytes = data_len + pad_hdr_size;
+ append_elf_note(buf, VMCOREINFO_NOTE_NAME, NT_VMCORE_PAD, NULL,
+ roundup(used_bytes, PAGE_SIZE) - used_bytes);
}
void
[PATCH v2 15/20] kexec: fill note buffers by NT_VMCORE_PAD notes in page-size boundary
Fill both crash_notes and vmcoreinfo_note buffers by NT_VMCORE_PAD
note type to make them satisfy mmap()'s page-size boundary
requirement.
So far, end of note segments has been marked by zero-filled elf
header. Instead, this patch writes NT_VMCORE_PAD note in the end of
note segments until the offset on page-size boundary.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
arch/s390/include/asm/kexec.h |7 --
include/linux/kexec.h | 12 ++-
kernel/kexec.c| 46 ++---
3 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/s390/include/asm/kexec.h b/arch/s390/include/asm/kexec.h
index 694bcd6..2a531ce 100644
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -41,8 +41,8 @@
/*
* Size for s390x ELF notes per CPU
*
- * Seven notes plus zero note at the end: prstatus, fpregset, timer,
- * tod_cmp, tod_reg, control regs, and prefix
+ * Seven notes plus note with NT_VMCORE_PAD type at the end: prstatus,
+ * fpregset, timer, tod_cmp, tod_reg, control regs, and prefix
*/
#define KEXEC_NOTE_BYTES \
(ALIGN(sizeof(struct elf_note), 4) * 8 + \
@@ -53,7 +53,8 @@
ALIGN(sizeof(u64), 4) + \
ALIGN(sizeof(u32), 4) + \
ALIGN(sizeof(u64) * 16, 4) + \
-ALIGN(sizeof(u32), 4) \
+ALIGN(sizeof(u32), 4) + \
+VMCOREINFO_NOTE_NAME_BYTES \
)
/* Provide a dummy definition to avoid build failures. */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 5113570..6592935 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -47,14 +47,16 @@
#define KEXEC_CORE_NOTE_NAME_BYTES ALIGN(sizeof(KEXEC_CORE_NOTE_NAME), 4)
#define KEXEC_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)
/*
- * The per-cpu notes area is a list of notes terminated by a NULL
- * note header. For kdump, the code in vmcore.c runs in the context
- * of the second kernel to combine them into one note.
+ * The per-cpu notes area is a list of notes terminated by a note
+ * header with NT_VMCORE_PAD type. For kdump, the code in vmcore.c
+ * runs in the context of the second kernel to combine them into one
+ * note.
*/
#ifndef KEXEC_NOTE_BYTES
#define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
KEXEC_CORE_NOTE_NAME_BYTES +\
- KEXEC_CORE_NOTE_DESC_BYTES )
+ KEXEC_CORE_NOTE_DESC_BYTES +\
+ VMCOREINFO_NOTE_NAME_BYTES)
#endif
/*
@@ -187,7 +189,7 @@ extern struct kimage *kexec_crash_image;
#define VMCOREINFO_NOTE_NAME_BYTES ALIGN(sizeof(VMCOREINFO_NOTE_NAME), 4)
#define VMCOREINFO_NOTE_SIZE ALIGN(KEXEC_NOTE_HEAD_BYTES*2 \
+VMCOREINFO_BYTES \
-+VMCOREINFO_NOTE_NAME_BYTES, \
++VMCOREINFO_NOTE_NAME_BYTES*2, \
PAGE_SIZE)
/* Location of a reserved region to hold the crash kernel.
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 6597b82..fbdc0f0 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -40,6 +40,7 @@
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
+static size_t crash_notes_size = ALIGN(sizeof(note_buf_t), PAGE_SIZE);
/* vmcoreinfo stuff */
static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
@@ -1177,6 +1178,7 @@ unlock:
return ret;
}
+/* If @data is NULL, fill @buf with 0 in @data_len bytes. */
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
{
@@ -1189,26 +1191,36 @@ static u32 *append_elf_note(u32 *buf, char *name,
unsigned type, void *data,
buf += (sizeof(note) + 3)/4;
memcpy(buf, name, note.n_namesz);
buf += (note.n_namesz + 3)/4;
- memcpy(buf, data, note.n_descsz);
+ if (data)
+ memcpy(buf, data, note.n_descsz);
+ else
+ memset(buf, 0, note.n_descsz);
buf += (note.n_descsz + 3)/4;
return buf;
}
-static void final_note(u32 *buf)
+static void final_note(u32 *buf, size_t buf_len, size_t data_len)
{
- struct elf_note note;
+ size_t used_bytes, pad_hdr_size;
- note.n_namesz = 0;
- note.n_descsz = 0;
- note.n_type = 0;
- memcpy(buf, note, sizeof(note));
+ pad_hdr_size = KEXEC_NOTE_HEAD_BYTES + VMCOREINFO_NOTE_NAME_BYTES;
+
+ /*
+* keep space for ELF note header and VMCOREINFO name to
+* terminate ELF segment by NT_VMCORE_PAD note.
+*/
+ BUG_ON(data_len + pad_hdr_size buf_len);
+
+ used_bytes = data_len + pad_hdr_size;
+ append_elf_note(buf, VMCOREINFO_NOTE_NAME, NT_VMCORE_PAD, NULL,
+ roundup(used_bytes, PAGE_SIZE) -
