[PATCH 0/3 v2] add reserved e820 ranges to the kdump kernel e820 table

[PATCH 0/3 v2] add reserved e820 ranges to the kdump kernel e820 table

[Lianbo Jiang]

E820 reserved ranges is useful in kdump kernel, we have added this in
kexec-tools code.

One reason is PCI mmconf (extended mode) requires reserved region otherwise
it falls back to legacy mode.

Furthermore, when AMD SME kdump support, it needs to map dmi table area as
unencrypted. For normal boot these ranges sit in e820 reserved ranges thus
the early ioremap code naturally map them as unencrypted. So if we have same
e820 reserve setup in kdump kernel then it will just work like normal kernel.

Kdump use walk_iomem_res_desc to iterate resources then add matched desc to
e820 table for the kdump kernel.

But IORES_DESC_NONE resource type includes several different e820 types, we
need add exact e820 type to the kdump kernel e820 table thus need an extra
checking in memmap_entry_callback() to match the e820 type and resource name.

By the way, we also fix an error which walks through iomem resources, the
values of the function parameter may be modified in the while loop of
__walk_iomem_res_desc(), which will cause us to not get the desired result
in some cases.

Changes since v1:
1. We modified the value of flags to "0", when walking through the whole
tree for e820 reserved ranges.

Lianbo Jiang (3):
  resource: fix an error which walks through iomem resources
  x86/kexec_file: add e820 entry in case e820 type string matches to io
    resource name
  x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table

 arch/x86/include/asm/e820/api.h |  2 ++
 arch/x86/kernel/crash.c         | 11 ++++++++++-
 arch/x86/kernel/e820.c          |  2 +-
 kernel/resource.c               |  3 +++
 4 files changed, 16 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH 0/3 v2] add reserved e820 ranges to the kdump kernel e820 table

[Lianbo Jiang]

E820 reserved ranges is useful in kdump kernel, we have added this in
kexec-tools code.

One reason is PCI mmconf (extended mode) requires reserved region otherwise
it falls back to legacy mode.

Furthermore, when AMD SME kdump support, it needs to map dmi table area as
unencrypted. For normal boot these ranges sit in e820 reserved ranges thus
the early ioremap code naturally map them as unencrypted. So if we have same
e820 reserve setup in kdump kernel then it will just work like normal kernel.

Kdump use walk_iomem_res_desc to iterate resources then add matched desc to
e820 table for the kdump kernel.

But IORES_DESC_NONE resource type includes several different e820 types, we
need add exact e820 type to the kdump kernel e820 table thus need an extra
checking in memmap_entry_callback() to match the e820 type and resource name.

By the way, we also fix an error which walks through iomem resources, the
values of the function parameter may be modified in the while loop of
__walk_iomem_res_desc(), which will cause us to not get the desired result
in some cases.

Changes since v1:
1. We modified the value of flags to "0", when walking through the whole
tree for e820 reserved ranges.

Lianbo Jiang (3):
  resource: fix an error which walks through iomem resources
  x86/kexec_file: add e820 entry in case e820 type string matches to io
    resource name
  x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table

 arch/x86/include/asm/e820/api.h |  2 ++
 arch/x86/kernel/crash.c         | 11 ++++++++++-
 arch/x86/kernel/e820.c          |  2 +-
 kernel/resource.c               |  3 +++
 4 files changed, 16 insertions(+), 2 deletions(-)

-- 
2.17.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[Lianbo Jiang]

When we walk through iomem resources by calling walk_iomem_res_desc(),
the values of the function parameter may be modified in the while loop
of __walk_iomem_res_desc(), which will cause us to not get the desired
result in some cases.

At present, it only restores the original value of res->end, but it
doesn't restore the original value of res->flags in the while loop of
__walk_iomem _res_desc(). Whenever the find_next_iomem_res() finds a
resource and returns the result, the original values of this resource
will be modified, which might lead to an error in the next loop. For
example:

The original value of resource flags is:
 res->flags=0x80000200(initial value)

p->flags   _ 0x81000200 _                _ 0x80000200 _
          /              \              /              \
|________|_______A________|____|_....._|______B_________|..........___|
0                                                            0xffffffff
                (memory address ranges)

Note: if ((p->flags & res->flags) != res->flags) continue;

When the resource A is found, the original value of this resource flags
will be changed to 0x81000200(res->flags=0x81000200), and continue to
look for the next resource, when the loop reaches resource B, it can not
get the resource B any more(you can refer to the for loop of find_next
_iomem_res()), because the value of conditional expression will become
true and will also jump the resource B.

In fact, we should get the resource A and B when we walk through the
whole tree, but it only gets the resource A, the resource B is missed.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
 kernel/resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/resource.c b/kernel/resource.c
index 30e1bc68503b..f5d9fc70a04c 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -375,6 +375,7 @@ static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
 				 int (*func)(struct resource *, void *))
 {
 	u64 orig_end = res->end;
+	u64 orig_flags = res->flags;
 	int ret = -1;
 
 	while ((res->start < res->end) &&
@@ -385,6 +386,7 @@ static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
 
 		res->start = res->end + 1;
 		res->end = orig_end;
+		res->flags = orig_flags;
 	}
 
 	return ret;
-- 
2.17.1

[PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[Lianbo Jiang]

When we walk through iomem resources by calling walk_iomem_res_desc(),
the values of the function parameter may be modified in the while loop
of __walk_iomem_res_desc(), which will cause us to not get the desired
result in some cases.

At present, it only restores the original value of res->end, but it
doesn't restore the original value of res->flags in the while loop of
__walk_iomem _res_desc(). Whenever the find_next_iomem_res() finds a
resource and returns the result, the original values of this resource
will be modified, which might lead to an error in the next loop. For
example:

The original value of resource flags is:
 res->flags=0x80000200(initial value)

p->flags   _ 0x81000200 _                _ 0x80000200 _
          /              \              /              \
|________|_______A________|____|_....._|______B_________|..........___|
0                                                            0xffffffff
                (memory address ranges)

Note: if ((p->flags & res->flags) != res->flags) continue;

When the resource A is found, the original value of this resource flags
will be changed to 0x81000200(res->flags=0x81000200), and continue to
look for the next resource, when the loop reaches resource B, it can not
get the resource B any more(you can refer to the for loop of find_next
_iomem_res()), because the value of conditional expression will become
true and will also jump the resource B.

In fact, we should get the resource A and B when we walk through the
whole tree, but it only gets the resource A, the resource B is missed.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
 kernel/resource.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/resource.c b/kernel/resource.c
index 30e1bc68503b..f5d9fc70a04c 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -375,6 +375,7 @@ static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
 				 int (*func)(struct resource *, void *))
 {
 	u64 orig_end = res->end;
+	u64 orig_flags = res->flags;
 	int ret = -1;
 
 	while ((res->start < res->end) &&
@@ -385,6 +386,7 @@ static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
 
 		res->start = res->end + 1;
 		res->end = orig_end;
+		res->flags = orig_flags;
 	}
 
 	return ret;
-- 
2.17.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/3 v2] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name

[Lianbo Jiang]

kdump use walk_iomem_res_desc to iterate io resources then add matched
desc to e820 table for kdump kernel.

But IORES_DESC_NONE resource type includes several different e820 types,
we need add exact e820 type to kdump kernel e820 table thus need an extra
checking in memmap_entry_callback() to match the e820 type and resource
name.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
 arch/x86/include/asm/e820/api.h | 2 ++
 arch/x86/kernel/crash.c         | 6 +++++-
 arch/x86/kernel/e820.c          | 2 +-
 kernel/resource.c               | 1 +
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
index 62be73b23d5c..6d5451b36e80 100644
--- a/arch/x86/include/asm/e820/api.h
+++ b/arch/x86/include/asm/e820/api.h
@@ -42,6 +42,8 @@ extern void e820__register_nosave_regions(unsigned long limit_pfn);
 
 extern int  e820__get_entry_type(u64 start, u64 end);
 
+extern const char *e820_type_to_string(struct e820_entry *entry);
+
 /*
  * Returns true iff the specified range [start,end) is completely contained inside
  * the ISA region.
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index f631a3f15587..ae724a6e0a5f 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -37,6 +37,7 @@
 #include <asm/reboot.h>
 #include <asm/virtext.h>
 #include <asm/intel_pt.h>
+#include <asm/e820/api.h>
 
 /* Used while preparing memory map entries for second kernel */
 struct crash_memmap_data {
@@ -314,11 +315,14 @@ static int memmap_entry_callback(struct resource *res, void *arg)
 	struct crash_memmap_data *cmd = arg;
 	struct boot_params *params = cmd->params;
 	struct e820_entry ei;
+	const char *name;
 
 	ei.addr = res->start;
 	ei.size = resource_size(res);
 	ei.type = cmd->type;
-	add_e820_entry(params, &ei);
+	name = e820_type_to_string(&ei);
+	if (res->name && !strcmp(name, res->name))
+		add_e820_entry(params, &ei);
 
 	return 0;
 }
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index c88c23c658c1..f9761b2f7abb 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1012,7 +1012,7 @@ void __init e820__finish_early_params(void)
 	}
 }
 
-static const char *__init e820_type_to_string(struct e820_entry *entry)
+const char *e820_type_to_string(struct e820_entry *entry)
 {
 	switch (entry->type) {
 	case E820_TYPE_RESERVED_KERN:	/* Fall-through: */
diff --git a/kernel/resource.c b/kernel/resource.c
index f5d9fc70a04c..cc90633f35f9 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -366,6 +366,7 @@ static int find_next_iomem_res(struct resource *res, unsigned long desc,
 		res->end = p->end;
 	res->flags = p->flags;
 	res->desc = p->desc;
+	res->name = p->name;
 	return 0;
 }
 
-- 
2.17.1

[PATCH 2/3 v2] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name

[Lianbo Jiang]

kdump use walk_iomem_res_desc to iterate io resources then add matched
desc to e820 table for kdump kernel.

But IORES_DESC_NONE resource type includes several different e820 types,
we need add exact e820 type to kdump kernel e820 table thus need an extra
checking in memmap_entry_callback() to match the e820 type and resource
name.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
 arch/x86/include/asm/e820/api.h | 2 ++
 arch/x86/kernel/crash.c         | 6 +++++-
 arch/x86/kernel/e820.c          | 2 +-
 kernel/resource.c               | 1 +
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
index 62be73b23d5c..6d5451b36e80 100644
--- a/arch/x86/include/asm/e820/api.h
+++ b/arch/x86/include/asm/e820/api.h
@@ -42,6 +42,8 @@ extern void e820__register_nosave_regions(unsigned long limit_pfn);
 
 extern int  e820__get_entry_type(u64 start, u64 end);
 
+extern const char *e820_type_to_string(struct e820_entry *entry);
+
 /*
  * Returns true iff the specified range [start,end) is completely contained inside
  * the ISA region.
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index f631a3f15587..ae724a6e0a5f 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -37,6 +37,7 @@
 #include <asm/reboot.h>
 #include <asm/virtext.h>
 #include <asm/intel_pt.h>
+#include <asm/e820/api.h>
 
 /* Used while preparing memory map entries for second kernel */
 struct crash_memmap_data {
@@ -314,11 +315,14 @@ static int memmap_entry_callback(struct resource *res, void *arg)
 	struct crash_memmap_data *cmd = arg;
 	struct boot_params *params = cmd->params;
 	struct e820_entry ei;
+	const char *name;
 
 	ei.addr = res->start;
 	ei.size = resource_size(res);
 	ei.type = cmd->type;
-	add_e820_entry(params, &ei);
+	name = e820_type_to_string(&ei);
+	if (res->name && !strcmp(name, res->name))
+		add_e820_entry(params, &ei);
 
 	return 0;
 }
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index c88c23c658c1..f9761b2f7abb 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1012,7 +1012,7 @@ void __init e820__finish_early_params(void)
 	}
 }
 
-static const char *__init e820_type_to_string(struct e820_entry *entry)
+const char *e820_type_to_string(struct e820_entry *entry)
 {
 	switch (entry->type) {
 	case E820_TYPE_RESERVED_KERN:	/* Fall-through: */
diff --git a/kernel/resource.c b/kernel/resource.c
index f5d9fc70a04c..cc90633f35f9 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -366,6 +366,7 @@ static int find_next_iomem_res(struct resource *res, unsigned long desc,
 		res->end = p->end;
 	res->flags = p->flags;
 	res->desc = p->desc;
+	res->name = p->name;
 	return 0;
 }
 
-- 
2.17.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 3/3 v2] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table

[Lianbo Jiang]

E820 reserved ranges is useful in kdump kernel, we have added this in
kexec-tools code.

One reason is PCI mmconf (extended mode) requires reserved region
otherwise it falls back to legacy mode.

When AMD SME kdump support, it needs to map dmi table area as unencrypted.
For normal boot these ranges sit in e820 reserved ranges thus the early
ioremap code naturally map them as unencrypted. So if we have same e820
reserve setup in kdump kernel then it will just work like normal kernel.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
 arch/x86/kernel/crash.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index ae724a6e0a5f..3460be990e0c 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -384,6 +384,11 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)
 	walk_iomem_res_desc(IORES_DESC_ACPI_NV_STORAGE, flags, 0, -1, &cmd,
 			memmap_entry_callback);
 
+	/* Add all reserved ranges */
+	cmd.type = E820_TYPE_RESERVED;
+	walk_iomem_res_desc(IORES_DESC_NONE, 0, 0, -1, &cmd,
+			memmap_entry_callback);
+
 	/* Add crashk_low_res region */
 	if (crashk_low_res.end) {
 		ei.addr = crashk_low_res.start;
-- 
2.17.1

[PATCH 3/3 v2] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table

[Lianbo Jiang]

E820 reserved ranges is useful in kdump kernel, we have added this in
kexec-tools code.

One reason is PCI mmconf (extended mode) requires reserved region
otherwise it falls back to legacy mode.

When AMD SME kdump support, it needs to map dmi table area as unencrypted.
For normal boot these ranges sit in e820 reserved ranges thus the early
ioremap code naturally map them as unencrypted. So if we have same e820
reserve setup in kdump kernel then it will just work like normal kernel.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
 arch/x86/kernel/crash.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index ae724a6e0a5f..3460be990e0c 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -384,6 +384,11 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)
 	walk_iomem_res_desc(IORES_DESC_ACPI_NV_STORAGE, flags, 0, -1, &cmd,
 			memmap_entry_callback);
 
+	/* Add all reserved ranges */
+	cmd.type = E820_TYPE_RESERVED;
+	walk_iomem_res_desc(IORES_DESC_NONE, 0, 0, -1, &cmd,
+			memmap_entry_callback);
+
 	/* Add crashk_low_res region */
 	if (crashk_low_res.end) {
 		ei.addr = crashk_low_res.start;
-- 
2.17.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[Borislav Petkov]

On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:

...

> In fact, we should get the resource A and B when we walk through the
> whole tree, but it only gets the resource A, the resource B is missed.
> 
> Signed-off-by: Dave Young <dyoung@redhat.com>
> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>

Before looking at this: the SOB chain of all three patches is wrong.
Hint: see section 12) in Documentation/process/submitting-patches.rst

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Re: [PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[Borislav Petkov]

On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:

...

> In fact, we should get the resource A and B when we walk through the
> whole tree, but it only gets the resource A, the resource B is missed.
> 
> Signed-off-by: Dave Young <dyoung@redhat.com>
> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>

Before looking at this: the SOB chain of all three patches is wrong.
Hint: see section 12) in Documentation/process/submitting-patches.rst

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[lijiang]

在 2018年09月19日 21:29, Borislav Petkov 写道:
> On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:
> 
> ...
> 
>> In fact, we should get the resource A and B when we walk through the
>> whole tree, but it only gets the resource A, the resource B is missed.
>>
>> Signed-off-by: Dave Young <dyoung@redhat.com>
>> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
> 
> Before looking at this: the SOB chain of all three patches is wrong.
> Hint: see section 12) in Documentation/process/submitting-patches.rst
> 
Thanks for your advice, Borislav.

I have discussed with Dave Young, and he suggested that i might add a Suggested-by
tag instead of Signed-off-by tag for him. What do you think about?

I will modify the invalid SOB chain and post it again.

Re: [PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[lijiang]

在 2018年09月19日 21:29, Borislav Petkov 写道:
> On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:
> 
> ...
> 
>> In fact, we should get the resource A and B when we walk through the
>> whole tree, but it only gets the resource A, the resource B is missed.
>>
>> Signed-off-by: Dave Young <dyoung@redhat.com>
>> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
> 
> Before looking at this: the SOB chain of all three patches is wrong.
> Hint: see section 12) in Documentation/process/submitting-patches.rst
> 
Thanks for your advice, Borislav.

I have discussed with Dave Young, and he suggested that i might add a Suggested-by
tag instead of Signed-off-by tag for him. What do you think about?

I will modify the invalid SOB chain and post it again.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[Dave Young]

On 09/20/18 at 02:39pm, lijiang wrote:
> 在 2018年09月19日 21:29, Borislav Petkov 写道:
> > On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:
> > 
> > ...
> > 
> >> In fact, we should get the resource A and B when we walk through the
> >> whole tree, but it only gets the resource A, the resource B is missed.
> >>
> >> Signed-off-by: Dave Young <dyoung@redhat.com>
> >> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
> > 
> > Before looking at this: the SOB chain of all three patches is wrong.
> > Hint: see section 12) in Documentation/process/submitting-patches.rst
> > 
> Thanks for your advice, Borislav.
> 
> I have discussed with Dave Young, and he suggested that i might add a Suggested-by

patch 2 and patch 3 are based on my draft patch, but since you did debugging
and changes you can move my SOB to Suggested-by for patch 2 and patch 3,
for patch 1 please just drop my SOB and leave yours only. 


> tag instead of Signed-off-by tag for him. What do you think about?
> 
> I will modify the invalid SOB chain and post it again.
> 

Thanks
Dave

Re: [PATCH 1/3 v2] resource: fix an error which walks through iomem resources

[Dave Young]

On 09/20/18 at 02:39pm, lijiang wrote:
> 在 2018年09月19日 21:29, Borislav Petkov 写道:
> > On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:
> > 
> > ...
> > 
> >> In fact, we should get the resource A and B when we walk through the
> >> whole tree, but it only gets the resource A, the resource B is missed.
> >>
> >> Signed-off-by: Dave Young <dyoung@redhat.com>
> >> Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
> > 
> > Before looking at this: the SOB chain of all three patches is wrong.
> > Hint: see section 12) in Documentation/process/submitting-patches.rst
> > 
> Thanks for your advice, Borislav.
> 
> I have discussed with Dave Young, and he suggested that i might add a Suggested-by

patch 2 and patch 3 are based on my draft patch, but since you did debugging
and changes you can move my SOB to Suggested-by for patch 2 and patch 3,
for patch 1 please just drop my SOB and leave yours only. 


> tag instead of Signed-off-by tag for him. What do you think about?
> 
> I will modify the invalid SOB chain and post it again.
> 

Thanks
Dave

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec