All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Philipp Rudo <prudo@linux.ibm.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	dhowells@redhat.com, vgoyal@redhat.com,
	herbert@gondor.apana.org.au, davem@davemloft.net, bhe@redhat.com,
	arnd@arndb.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	ard.biesheuvel@linaro.org, james.morse@arm.com,
	bhsharma@redhat.com, kexec@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Subject: Re: [PATCH v13 03/16] s390, kexec_file: drop arch_kexec_mem_walk()
Date: Mon, 6 Aug 2018 13:50:47 +0800	[thread overview]
Message-ID: <20180806055047.GC4246@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20180802000150.GN11258@linaro.org>

Add Thiago in cc so that he can review from powerpc point of view. 

On 08/02/18 at 09:01am, AKASHI Takahiro wrote:
> Hi,
> 
> On Wed, Aug 01, 2018 at 10:29:51AM +0200, Philipp Rudo wrote:
> > Hey Akashi,
> > 
> > I kept thinking about this patch and remembered why I didn't made the change
> > you are suggesting now.
> 
> Hmm.
> 
> > The problem is when you only check for kbuf->mem you are excluding address 0,
> > which might be a valid address to load the kernel to. On s390 this is actually
> > done when the kernel is not loaded via a boot loader. For kexec_file however,
> > we cut off the first few kB of the image and jump directly to 'startup'. So
> > checking for !0 does not cause a problem here.
> 
> Yeah, as Dave(RedHat) described, all the current kexec-capable architectures,
> except arm64, implicitly initialize kbuf.mem to zero with "kbuf = { ... }"
> initializer. So surely my change would not break anything on the existing code.
> On the other hand, I also see your concern here.
> 
> > Anyway, the long term safer solution would be something like
> > 
> > #define KEXEC_BUF_MEM_UNKNOWN (-1UL)
> > 
> > for architectures to tell common code to search a fitting mem hole.
> 
> This would require the existing code on every arch to be modified, which
> I think should be avoided if possible. Instead,
> we'd better define in linux/kexec.h:
>   #ifndef KEXEC_BUF_MEM_UNKNOWN
>   #define KEXEC_BUF_MEM_UNKNOWN 0
>   #endif
> and then check for kbuf in kexec_locate_mem_hole():
>   if (kbuf->mem != KEXEC_BUF_MEM_UNKNOWN)
>         return 0;
>   ...
> 
> This way if some arch wants to treat *zero* as a valid address, it can
> redefine this macro in arch/asm/kexec.h.

I think this way works if powerpc is safe for using zero as the unknown
address in this case.  Thiago, can you provide some review?

Philipp, thanks for catching the problem!

> 
> Thanks,
> -Takahiro AKASHI
> 
> > 
> > Back then I didn't do the change because I had the other workaround, which
> > didn't require a common code change. But when you are touching the code now it
> > is worth thinking about it.
> > 
> > Just wanted to let you know
> > Philipp
> > 
> > 
> > On Wed,  1 Aug 2018 16:58:07 +0900
> > AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > 
> > > Since s390 already knows where to locate buffers, calling
> > > arch_kexec_mem_walk() has no sense. So we can just drop it as kbuf->mem
> > > indicates this while all other architectures sets it to 0 initially.
> > > 
> > > This change is a preparatory work for the next patch, where all the
> > > variant memory walks, either on system resource or memblock, will be
> > > put in one common place so that it will satisfy all the architectures'
> > > need.
> > > 
> > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
> > > Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > > Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> > > Cc: Dave Young <dyoung@redhat.com>
> > > Cc: Vivek Goyal <vgoyal@redhat.com>
> > > Cc: Baoquan He <bhe@redhat.com>
> > > ---
> > >  arch/s390/kernel/machine_kexec_file.c | 10 ----------
> > >  kernel/kexec_file.c                   |  4 ++++
> > >  2 files changed, 4 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
> > > index f413f57f8d20..32023b4f9dc0 100644
> > > --- a/arch/s390/kernel/machine_kexec_file.c
> > > +++ b/arch/s390/kernel/machine_kexec_file.c
> > > @@ -134,16 +134,6 @@ int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data,
> > >  	return ret;
> > >  }
> > >  
> > > -/*
> > > - * The kernel is loaded to a fixed location. Turn off kexec_locate_mem_hole
> > > - * and provide kbuf->mem by hand.
> > > - */
> > > -int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > -			int (*func)(struct resource *, void *))
> > > -{
> > > -	return 1;
> > > -}
> > > -
> > >  int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> > >  				     Elf_Shdr *section,
> > >  				     const Elf_Shdr *relsec,
> > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > > index 63c7ce1c0c3e..bf39df5e5bb9 100644
> > > --- a/kernel/kexec_file.c
> > > +++ b/kernel/kexec_file.c
> > > @@ -534,6 +534,10 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> > >  {
> > >  	int ret;
> > >  
> > > +	/* Arch knows where to place */
> > > +	if (kbuf->mem)
> > > +		return 0;
> > > +
> > >  	ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> > >  
> > >  	return ret == 1 ? 0 : -EADDRNOTAVAIL;
> > 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Thanks
Dave

WARNING: multiple messages have this Message-ID (diff)
From: dyoung@redhat.com (Dave Young)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v13 03/16] s390, kexec_file: drop arch_kexec_mem_walk()
Date: Mon, 6 Aug 2018 13:50:47 +0800	[thread overview]
Message-ID: <20180806055047.GC4246@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20180802000150.GN11258@linaro.org>

Add Thiago in cc so that he can review from powerpc point of view. 

On 08/02/18 at 09:01am, AKASHI Takahiro wrote:
> Hi,
> 
> On Wed, Aug 01, 2018 at 10:29:51AM +0200, Philipp Rudo wrote:
> > Hey Akashi,
> > 
> > I kept thinking about this patch and remembered why I didn't made the change
> > you are suggesting now.
> 
> Hmm.
> 
> > The problem is when you only check for kbuf->mem you are excluding address 0,
> > which might be a valid address to load the kernel to. On s390 this is actually
> > done when the kernel is not loaded via a boot loader. For kexec_file however,
> > we cut off the first few kB of the image and jump directly to 'startup'. So
> > checking for !0 does not cause a problem here.
> 
> Yeah, as Dave(RedHat) described, all the current kexec-capable architectures,
> except arm64, implicitly initialize kbuf.mem to zero with "kbuf = { ... }"
> initializer. So surely my change would not break anything on the existing code.
> On the other hand, I also see your concern here.
> 
> > Anyway, the long term safer solution would be something like
> > 
> > #define KEXEC_BUF_MEM_UNKNOWN (-1UL)
> > 
> > for architectures to tell common code to search a fitting mem hole.
> 
> This would require the existing code on every arch to be modified, which
> I think should be avoided if possible. Instead,
> we'd better define in linux/kexec.h:
>   #ifndef KEXEC_BUF_MEM_UNKNOWN
>   #define KEXEC_BUF_MEM_UNKNOWN 0
>   #endif
> and then check for kbuf in kexec_locate_mem_hole():
>   if (kbuf->mem != KEXEC_BUF_MEM_UNKNOWN)
>         return 0;
>   ...
> 
> This way if some arch wants to treat *zero* as a valid address, it can
> redefine this macro in arch/asm/kexec.h.

I think this way works if powerpc is safe for using zero as the unknown
address in this case.  Thiago, can you provide some review?

Philipp, thanks for catching the problem!

> 
> Thanks,
> -Takahiro AKASHI
> 
> > 
> > Back then I didn't do the change because I had the other workaround, which
> > didn't require a common code change. But when you are touching the code now it
> > is worth thinking about it.
> > 
> > Just wanted to let you know
> > Philipp
> > 
> > 
> > On Wed,  1 Aug 2018 16:58:07 +0900
> > AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > 
> > > Since s390 already knows where to locate buffers, calling
> > > arch_kexec_mem_walk() has no sense. So we can just drop it as kbuf->mem
> > > indicates this while all other architectures sets it to 0 initially.
> > > 
> > > This change is a preparatory work for the next patch, where all the
> > > variant memory walks, either on system resource or memblock, will be
> > > put in one common place so that it will satisfy all the architectures'
> > > need.
> > > 
> > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
> > > Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > > Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> > > Cc: Dave Young <dyoung@redhat.com>
> > > Cc: Vivek Goyal <vgoyal@redhat.com>
> > > Cc: Baoquan He <bhe@redhat.com>
> > > ---
> > >  arch/s390/kernel/machine_kexec_file.c | 10 ----------
> > >  kernel/kexec_file.c                   |  4 ++++
> > >  2 files changed, 4 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
> > > index f413f57f8d20..32023b4f9dc0 100644
> > > --- a/arch/s390/kernel/machine_kexec_file.c
> > > +++ b/arch/s390/kernel/machine_kexec_file.c
> > > @@ -134,16 +134,6 @@ int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data,
> > >  	return ret;
> > >  }
> > >  
> > > -/*
> > > - * The kernel is loaded to a fixed location. Turn off kexec_locate_mem_hole
> > > - * and provide kbuf->mem by hand.
> > > - */
> > > -int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > -			int (*func)(struct resource *, void *))
> > > -{
> > > -	return 1;
> > > -}
> > > -
> > >  int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> > >  				     Elf_Shdr *section,
> > >  				     const Elf_Shdr *relsec,
> > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > > index 63c7ce1c0c3e..bf39df5e5bb9 100644
> > > --- a/kernel/kexec_file.c
> > > +++ b/kernel/kexec_file.c
> > > @@ -534,6 +534,10 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> > >  {
> > >  	int ret;
> > >  
> > > +	/* Arch knows where to place */
> > > +	if (kbuf->mem)
> > > +		return 0;
> > > +
> > >  	ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> > >  
> > >  	return ret == 1 ? 0 : -EADDRNOTAVAIL;
> > 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Thanks
Dave

WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Philipp Rudo <prudo@linux.ibm.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	dhowells@redhat.com, vgoyal@redhat.com,
	herbert@gondor.apana.org.au, davem@davemloft.net, bhe@redhat.com,
	arnd@arndb.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	ard.biesheuvel@linaro.org, james.morse@arm.com,
	bhsharma@redhat.com, kexec@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Subject: Re: [PATCH v13 03/16] s390, kexec_file: drop arch_kexec_mem_walk()
Date: Mon, 6 Aug 2018 13:50:47 +0800	[thread overview]
Message-ID: <20180806055047.GC4246@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20180802000150.GN11258@linaro.org>

Add Thiago in cc so that he can review from powerpc point of view. 

On 08/02/18 at 09:01am, AKASHI Takahiro wrote:
> Hi,
> 
> On Wed, Aug 01, 2018 at 10:29:51AM +0200, Philipp Rudo wrote:
> > Hey Akashi,
> > 
> > I kept thinking about this patch and remembered why I didn't made the change
> > you are suggesting now.
> 
> Hmm.
> 
> > The problem is when you only check for kbuf->mem you are excluding address 0,
> > which might be a valid address to load the kernel to. On s390 this is actually
> > done when the kernel is not loaded via a boot loader. For kexec_file however,
> > we cut off the first few kB of the image and jump directly to 'startup'. So
> > checking for !0 does not cause a problem here.
> 
> Yeah, as Dave(RedHat) described, all the current kexec-capable architectures,
> except arm64, implicitly initialize kbuf.mem to zero with "kbuf = { ... }"
> initializer. So surely my change would not break anything on the existing code.
> On the other hand, I also see your concern here.
> 
> > Anyway, the long term safer solution would be something like
> > 
> > #define KEXEC_BUF_MEM_UNKNOWN (-1UL)
> > 
> > for architectures to tell common code to search a fitting mem hole.
> 
> This would require the existing code on every arch to be modified, which
> I think should be avoided if possible. Instead,
> we'd better define in linux/kexec.h:
>   #ifndef KEXEC_BUF_MEM_UNKNOWN
>   #define KEXEC_BUF_MEM_UNKNOWN 0
>   #endif
> and then check for kbuf in kexec_locate_mem_hole():
>   if (kbuf->mem != KEXEC_BUF_MEM_UNKNOWN)
>         return 0;
>   ...
> 
> This way if some arch wants to treat *zero* as a valid address, it can
> redefine this macro in arch/asm/kexec.h.

I think this way works if powerpc is safe for using zero as the unknown
address in this case.  Thiago, can you provide some review?

Philipp, thanks for catching the problem!

> 
> Thanks,
> -Takahiro AKASHI
> 
> > 
> > Back then I didn't do the change because I had the other workaround, which
> > didn't require a common code change. But when you are touching the code now it
> > is worth thinking about it.
> > 
> > Just wanted to let you know
> > Philipp
> > 
> > 
> > On Wed,  1 Aug 2018 16:58:07 +0900
> > AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > 
> > > Since s390 already knows where to locate buffers, calling
> > > arch_kexec_mem_walk() has no sense. So we can just drop it as kbuf->mem
> > > indicates this while all other architectures sets it to 0 initially.
> > > 
> > > This change is a preparatory work for the next patch, where all the
> > > variant memory walks, either on system resource or memblock, will be
> > > put in one common place so that it will satisfy all the architectures'
> > > need.
> > > 
> > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
> > > Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > > Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> > > Cc: Dave Young <dyoung@redhat.com>
> > > Cc: Vivek Goyal <vgoyal@redhat.com>
> > > Cc: Baoquan He <bhe@redhat.com>
> > > ---
> > >  arch/s390/kernel/machine_kexec_file.c | 10 ----------
> > >  kernel/kexec_file.c                   |  4 ++++
> > >  2 files changed, 4 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
> > > index f413f57f8d20..32023b4f9dc0 100644
> > > --- a/arch/s390/kernel/machine_kexec_file.c
> > > +++ b/arch/s390/kernel/machine_kexec_file.c
> > > @@ -134,16 +134,6 @@ int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data,
> > >  	return ret;
> > >  }
> > >  
> > > -/*
> > > - * The kernel is loaded to a fixed location. Turn off kexec_locate_mem_hole
> > > - * and provide kbuf->mem by hand.
> > > - */
> > > -int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > -			int (*func)(struct resource *, void *))
> > > -{
> > > -	return 1;
> > > -}
> > > -
> > >  int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> > >  				     Elf_Shdr *section,
> > >  				     const Elf_Shdr *relsec,
> > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > > index 63c7ce1c0c3e..bf39df5e5bb9 100644
> > > --- a/kernel/kexec_file.c
> > > +++ b/kernel/kexec_file.c
> > > @@ -534,6 +534,10 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> > >  {
> > >  	int ret;
> > >  
> > > +	/* Arch knows where to place */
> > > +	if (kbuf->mem)
> > > +		return 0;
> > > +
> > >  	ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> > >  
> > >  	return ret == 1 ? 0 : -EADDRNOTAVAIL;
> > 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Thanks
Dave

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

  reply	other threads:[~2018-08-06  5:51 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01  7:58 [PATCH v13 00/16] subject: arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-08-01  7:58 ` AKASHI Takahiro
2018-08-01  7:58 ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 01/16] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 02/16] kexec_file: make kexec_image_post_load_cleanup_default() global AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 03/16] s390, kexec_file: drop arch_kexec_mem_walk() AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  8:29   ` Philipp Rudo
2018-08-01  8:29     ` Philipp Rudo
2018-08-01  8:29     ` Philipp Rudo
2018-08-02  0:01     ` AKASHI Takahiro
2018-08-02  0:01       ` AKASHI Takahiro
2018-08-02  0:01       ` AKASHI Takahiro
2018-08-06  5:50       ` Dave Young [this message]
2018-08-06  5:50         ` Dave Young
2018-08-06  5:50         ` Dave Young
2018-08-09  3:34         ` Dave Young
2018-08-09  3:34           ` Dave Young
2018-08-09  3:34           ` Dave Young
2018-08-09  4:14           ` Pingfan Liu
2018-08-09  4:14             ` Pingfan Liu
2018-08-09  4:14             ` Pingfan Liu
2018-08-28  5:21             ` AKASHI Takahiro
2018-08-28  5:21               ` AKASHI Takahiro
2018-08-28  5:21               ` AKASHI Takahiro
2018-08-28 13:43               ` Dave Young
2018-08-28 13:43                 ` Dave Young
2018-08-28 13:43                 ` Dave Young
2018-08-29  0:28                 ` AKASHI Takahiro
2018-08-29  0:28                   ` AKASHI Takahiro
2018-08-29  0:28                   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 04/16] powerpc, kexec_file: factor out memblock-based arch_kexec_walk_mem() AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 05/16] kexec_file: kexec_walk_memblock() only walks a dedicated region at kdump AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 06/16] of/fdt: add helper functions for handling properties AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 07/16] arm64: add image head flag definitions AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 08/16] arm64: cpufeature: add MMFR0 helper functions AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 09/16] arm64: enable KEXEC_FILE config AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 10/16] arm64: kexec_file: load initrd and device-tree AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 11/16] arm64: kexec_file: allow for loading Image-format kernel AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 12/16] arm64: kexec_file: add crash dump support AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 13/16] arm64: kexec_file: invoke the kernel without purgatory AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 14/16] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 15/16] arm64: kexec_file: add kernel signature verification support AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58 ` [PATCH v13 16/16] arm64: kexec_file: add kaslr support AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro
2018-08-01  7:58   ` AKASHI Takahiro

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=20180806055047.GC4246@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=bhe@redhat.com \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prudo@linux.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=vgoyal@redhat.com \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.