On Fri, May 24, 2024 at 04:13:53PM +0200, Jiri Bohac wrote:
> On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote:
> > On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote:
> > > Nice, but then why was this commit worded this way? Now we check twice?
On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote:
> On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote:
> > Nice, but then why was this commit worded this way? Now we check twice?
> > Double safe? Should it be reverted?
>
> double safe's good;
On Fri, May 24, 2024 at 12:02:10PM +0200, Jiri Bohac wrote:
> On Tue, May 21, 2024 at 05:31:59PM +0200, Greg Kroah-Hartman wrote:
> > kernel: kexec: copy user-array safely
> >
> > Currently, there is no overflow-check with memdup_user().
>
> This is false.
>
On Wed, Jun 21, 2023 at 11:09:57AM +0200, Joel Granados wrote:
> static int __init random_sysctls_init(void)
> {
> - register_sysctl_init("kernel/random", random_table);
> + register_sysctl_init("kernel/random", random_table,
> + ARRAY_SIZE(random_table));
As
On Thu, Apr 27, 2023 at 06:18:34PM +0800, Li Zhijian wrote:
> It does:
> 1. Add pmem region into PT_LOADs of vmcore
> 2. Mark pmem region's p_flags as PF_DEV
I'm sorry, but I can not parse this changelog.
Please take a look at the kernel documentation for how to write a good
changelog message so
From: Robbie Harwood
[ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ]
These particular errors can be encountered while trying to kexec when
secureboot lockdown is in place. Without this change, even with a
signed debug build, one still needs to reboot the machine to add the
From: Robbie Harwood
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal. Therefore, the field is not required
to
From: Robbie Harwood
[ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ]
These particular errors can be encountered while trying to kexec when
secureboot lockdown is in place. Without this change, even with a
signed debug build, one still needs to reboot the machine to add the
From: Robbie Harwood
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal. Therefore, the field is not required
to
From: Robbie Harwood
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal. Therefore, the field is not required
to
From: Robbie Harwood
[ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ]
These particular errors can be encountered while trying to kexec when
secureboot lockdown is in place. Without this change, even with a
signed debug build, one still needs to reboot the machine to add the
From: Robbie Harwood
[ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ]
These particular errors can be encountered while trying to kexec when
secureboot lockdown is in place. Without this change, even with a
signed debug build, one still needs to reboot the machine to add the
From: Robbie Harwood
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal. Therefore, the field is not required
to
From: Robbie Harwood
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal. Therefore, the field is not required
to
From: Robbie Harwood
[ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ]
These particular errors can be encountered while trying to kexec when
secureboot lockdown is in place. Without this change, even with a
signed debug build, one still needs to reboot the machine to add the
From: Robbie Harwood
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal. Therefore, the field is not required
to
From: Robbie Harwood
[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
The PE Format Specification (section "The Attribute Certificate Table
(Image Only)") states that `dwLength` is to be rounded up to 8-byte
alignment when used for traversal. Therefore, the field is not required
to
On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote:
> On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote:
> > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote:
&
On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote:
> On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote:
> > > Hello,
> > >
> > > this is backport of commit 0d
On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote:
> Hello,
>
> this is backport of commit 0d519cadf751
> ("arm64: kexec_file: use more system keyrings to verify kernel image
> signature")
> to table 5.15 tree including the preparatory patches.
This feels to me like a new feature
From: Coiby Xu
[ Upstream commit 0d519cadf75184a24313568e7f489a7fc9b1be3b ]
Currently, when loading a kernel image via the kexec_file_load() system
call, arm64 can only use the .builtin_trusted_keys keyring to verify
a signature whereas x86 can use three more keyrings i.e.
ernel.org
Signed-off-by: Michal Suchanek
Reviewed-by: "Lee, Chun-Yi"
Acked-by: Baoquan He
Signed-off-by: Coiby Xu
Acked-by: Heiko Carstens
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/kernel/machine_kexec_file.c | 18 +-
1 file changed,
From: Michal Suchanek
[ Upstream commit 0828c4a39be57768b8788e8cbd0d84683ea757e5 ]
commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
adds support for KEXEC_SIG verification with keys from platform keyring
but the built-in keys and secondary keyring are not used.
Add
chal Suchanek
Acked-by: Will Deacon
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/kernel/kexec_image.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_im
chal Suchanek
Acked-by: Will Deacon
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/kernel/kexec_image.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_im
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kexec-bzimage64.c | 20 +---
include/linux/kexec.h |7 +++
kernel/kexec_file.c | 17 +
3 files changed, 25 insertions(+), 19
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kexec-bzimage64.c | 20 +---
include/linux/kexec.h |7 +++
kernel/kexec_file.c | 17 +
3 files changed, 25 insertions(+), 19
chal Suchanek
Acked-by: Will Deacon
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/kernel/kexec_image.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_im
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kexec-bzimage64.c | 20 +---
include/linux/kexec.h |7 +++
kernel/kexec_file.c | 17 +
3 files changed, 25 insertions(+), 19
From: Michal Suchanek
[ Upstream commit 0828c4a39be57768b8788e8cbd0d84683ea757e5 ]
commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
adds support for KEXEC_SIG verification with keys from platform keyring
but the built-in keys and secondary keyring are not used.
Add
From: Michal Suchanek
[ Upstream commit 0828c4a39be57768b8788e8cbd0d84683ea757e5 ]
commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
adds support for KEXEC_SIG verification with keys from platform keyring
but the built-in keys and secondary keyring are not used.
Add
From: Michal Suchanek
[ Upstream commit 0828c4a39be57768b8788e8cbd0d84683ea757e5 ]
commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
adds support for KEXEC_SIG verification with keys from platform keyring
but the built-in keys and secondary keyring are not used.
Add
On Mon, Aug 08, 2022 at 12:37:46PM -0300, Guilherme G. Piccoli wrote:
> Let me clarify / ask something: this series, for example, is composed as
> a bunch of patches "centered" around the same idea, panic notifiers
> improvements/fixes. But its patches belong to completely different
> subsystems,
On Mon, Aug 08, 2022 at 12:14:30PM -0300, Guilherme G. Piccoli wrote:
> On 08/08/2022 02:07, Evan Green wrote:
> > On Tue, Jul 19, 2022 at 12:55 PM Guilherme G. Piccoli
> > wrote:
> >>
> >> Currently the gsmi driver registers a panic notifier as well as
> >> reboot and die notifiers. The
On Mon, Sep 06, 2021 at 01:10:34PM +0530, Naresh Kamboju wrote:
> On Sun, 5 Sept 2021 at 20:28, Greg Kroah-Hartman
> wrote:
> >
> > On Sun, Sep 05, 2021 at 07:28:35PM +0530, Naresh Kamboju wrote:
> > > Following build errors noticed while building stable rc Linu
On Sun, Sep 05, 2021 at 07:28:35PM +0530, Naresh Kamboju wrote:
> Following build errors noticed while building stable rc Linux 5.13.14
> with gcc-11 for powerpc architecture.
>
> # to reproduce this build locally:
> tuxmake --target-arch=powerpc --kconfig=defconfig --toolchain=gcc-11
>
From: Lianbo Jiang
[ Upstream commit 6f599d84231fd27e42f4ca2a786a6641e8cddf00 ]
On x86, purgatory() copies the first 640K of memory to a backup region
because the kernel needs those first 640K for the real mode trampoline
during boot, among others.
However, when SME is enabled, the kernel
; Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Ard Biesheuvel
> Cc: Pankaj Gupta
> Cc: Baoquan He
> Cc: Wei Yang
> Cc: Eric Biederman
> Cc: Thomas Gleixner
> Cc: Greg Kroah-Hartman
> Cc: kexec@lists.infradead.org
> Signed-off-by: David Hildenbrand
> ---
> in
> Suggested-by: Christoph Hellwig
> Signed-off-by: Scott Branden
Acked-by: Greg Kroah-Hartman
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
From: Bhupesh Sharma
[ Upstream commit 73e030977f7884dbe1be0018bab517e8d02760f8 ]
Normally kdump kernel(s) run under severe memory constraint with the
basic idea being to save the crashdump vmcore reliably when the primary
kernel panics/hangs.
Currently the qed* ethernet driver ends up
From: Bhupesh Sharma
[ Upstream commit 73e030977f7884dbe1be0018bab517e8d02760f8 ]
Normally kdump kernel(s) run under severe memory constraint with the
basic idea being to save the crashdump vmcore reliably when the primary
kernel panics/hangs.
Currently the qed* ethernet driver ends up
From: Bhupesh Sharma
[ Upstream commit 73e030977f7884dbe1be0018bab517e8d02760f8 ]
Normally kdump kernel(s) run under severe memory constraint with the
basic idea being to save the crashdump vmcore reliably when the primary
kernel panics/hangs.
Currently the qed* ethernet driver ends up
From: Bhupesh Sharma
[ Upstream commit 73e030977f7884dbe1be0018bab517e8d02760f8 ]
Normally kdump kernel(s) run under severe memory constraint with the
basic idea being to save the crashdump vmcore reliably when the primary
kernel panics/hangs.
Currently the qed* ethernet driver ends up
On Wed, Jun 17, 2020 at 08:17:10AM -0700, Scott Branden wrote:
> Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h
> include file. That header gets pulled in just about everywhere
> and doesn't really need functions not related to the general fs interface.
>
>
On Tue, Jun 16, 2020 at 08:31:52PM -0700, Scott Branden wrote:
> Move kernel_read_file* to it own kernel_read_file.h include file.
That says what you did, but not _why_ you are doing it :(
___
kexec mailing list
kexec@lists.infradead.org
From: Dave Young
[ Upstream commit af164898482817a1d487964b68f3c21bae7a1beb ]
Michael Weiser reported that he got this error during a kexec rebooting:
esrt: Unsupported ESRT version 2904149718861218184.
The ESRT memory stays in EFI boot services data, and it was reserved
in kernel via
From: Dave Young
[ Upstream commit af164898482817a1d487964b68f3c21bae7a1beb ]
Michael Weiser reported that he got this error during a kexec rebooting:
esrt: Unsupported ESRT version 2904149718861218184.
The ESRT memory stays in EFI boot services data, and it was reserved
in kernel via
From: Dave Young
[ Upstream commit af164898482817a1d487964b68f3c21bae7a1beb ]
Michael Weiser reported that he got this error during a kexec rebooting:
esrt: Unsupported ESRT version 2904149718861218184.
The ESRT memory stays in EFI boot services data, and it was reserved
in kernel via
From: Lianbo Jiang
[ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ]
Add a forward declaration of struct kimage to the crash.h header because
future changes will invoke a crash-specific function from the realmode
init path and the compiler will complain otherwise like this:
In
From: Lianbo Jiang
[ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ]
Add a forward declaration of struct kimage to the crash.h header because
future changes will invoke a crash-specific function from the realmode
init path and the compiler will complain otherwise like this:
In
From: Lianbo Jiang
[ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ]
Add a forward declaration of struct kimage to the crash.h header because
future changes will invoke a crash-specific function from the realmode
init path and the compiler will complain otherwise like this:
In
From: Lianbo Jiang
[ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ]
Add a forward declaration of struct kimage to the crash.h header because
future changes will invoke a crash-specific function from the realmode
init path and the compiler will complain otherwise like this:
In
From: Lianbo Jiang
[ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ]
Add a forward declaration of struct kimage to the crash.h header because
future changes will invoke a crash-specific function from the realmode
init path and the compiler will complain otherwise like this:
In
etkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
C
From: Lianbo Jiang
[ Upstream commit 9cf38d5559e813cccdba8b44c82cc46ba48d0896 ]
When SME is enabled in the first kernel, it needs to allocate decrypted
pages for kdump because when the kdump kernel boots, these pages need to
be accessed decrypted in the initial boot stage, before SME is
From: Lianbo Jiang
[ Upstream commit 9cf38d5559e813cccdba8b44c82cc46ba48d0896 ]
When SME is enabled in the first kernel, it needs to allocate decrypted
pages for kdump because when the kdump kernel boots, these pages need to
be accessed decrypted in the initial boot stage, before SME is
etkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
C
etkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
C
etkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
C
[ Upstream commit 010a93bf97c72f43aac664d0a685942f83d1a103 ]
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current
[ Upstream commit a98959fdbda1849a01b2150bb635ed559ec06700 ]
find_next_iomem_res() finds an iomem resource that covers part of a range
described by "start, end". All callers expect that range to be inclusive,
i.e., both start and end are included, but find_next_iomem_res() doesn't
handle the end
5.0-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit ccec81e4251f5a5421e02874e394338a897056ca ]
When efi=noruntime or efi=oldmap is used on the kernel command line, EFI
services won't be available in the second kernel, therefore the
4.4-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 2aa958c99c7fd3162b089a1a56a34a0cdb778de1 ]
Kexec-ing a kernel with "efi=noruntime" on the first kernel's command
line causes the following null pointer dereference:
BUG: unable to
3.18-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 2aa958c99c7fd3162b089a1a56a34a0cdb778de1 ]
Kexec-ing a kernel with "efi=noruntime" on the first kernel's command
line causes the following null pointer dereference:
BUG: unable
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 2aa958c99c7fd3162b089a1a56a34a0cdb778de1 ]
Kexec-ing a kernel with "efi=noruntime" on the first kernel's command
line causes the following null pointer dereference:
BUG: unable to
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 2aa958c99c7fd3162b089a1a56a34a0cdb778de1 ]
Kexec-ing a kernel with "efi=noruntime" on the first kernel's command
line causes the following null pointer dereference:
BUG: unable
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 2aa958c99c7fd3162b089a1a56a34a0cdb778de1 ]
Kexec-ing a kernel with "efi=noruntime" on the first kernel's command
line causes the following null pointer dereference:
BUG: unable
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 2aa958c99c7fd3162b089a1a56a34a0cdb778de1 ]
Kexec-ing a kernel with "efi=noruntime" on the first kernel's command
line causes the following null pointer dereference:
BUG: unable
ha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/boot/compressed/mem_encrypt.S | 19 ---
1 file changed, 19 deletions(-)
--- a/arch/x86/boot/compressed/mem_encrypt.S
+++ b/arch/x86/boot/compressed/mem_encrypt.S
@@ -25,20 +25,6 @@ ENTRY(get_sev_encryption_bit)
push
ki
Signed-off-by: David Howells
Cc: kexec@lists.infradead.org
Cc: keyri...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kexec-bzimage64.c |2 +-
1 file changed, 1 inser
ki
Signed-off-by: David Howells
Cc: kexec@lists.infradead.org
Cc: keyri...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kexec-bzimage64.c |2 +-
1 file changed, 1 inser
ki
Signed-off-by: David Howells
Cc: kexec@lists.infradead.org
Cc: keyri...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kexec-bzimage64.c |2 +-
1 file changed, 1 inser
arf.suse.cz
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/kernel/aperture_64.c | 46 +-
arch/x86/xen/mmu_hvm.c|2 -
2 files changed, 46
arf.suse.cz
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/kernel/aperture_64.c | 46 +-
arch/x86/xen/mmu_hvm.c|2 -
2 files changed, 46
.de>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/include/asm/reboot.h|1 +
arch/x86/kernel/cpu/mcheck/mce.c | 18 --
arch/x86/kernel/reboot.c |5 +++--
3 files chang
<rui.zh...@intel.com>
Cc: Arjan van de Ven <ar...@linux.intel.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Dan Williams <dan.j.willi...@intel.com>
Link:
https://lkml.kernel.org/r/20180117234141.21184.44067.st...@tlendack-t1.amdoffice.net
Signed-off-by: Greg Kroah-Hart
.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: dyo...@redhat.com
Cc: Eric Biederman <ebied...@xmission.com>
Cc: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/1475514432-27682-1-git-send-email-pra...@redhat.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by:
.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: dyo...@redhat.com
Cc: Eric Biederman <ebied...@xmission.com>
Cc: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/1475514432-27682-1-git-send-email-pra...@redhat.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by:
: Takashi Iwai <ti...@suse.de>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Vivek Goyal <vgo...@redhat.com>
Cc: kexec@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Link: http://lkml.kernel.org/r/1443531537-29436-1-git-sen
: Takashi Iwai <ti...@suse.de>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Vivek Goyal <vgo...@redhat.com>
Cc: kexec@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Link: http://lkml.kernel.org/r/1443531537-29436-1-git-sen
80 matches
Mail list logo
