ned-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/smpboot.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1406,9 +1406,21 @@ __init void prefill_possibl
ned-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/smpboot.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1393,9 +1393,21 @@ __init void prefill_possibl
/r/1477102684-5092-1-git-send-email-ville.syrj...@linux.intel.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/smpboot.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
av Petkov
Cc: Rui Zhang
Cc: Arjan van de Ven
Cc: Boris Ostrovsky
Cc: Dan Williams
Link:
https://lkml.kernel.org/r/20180117234141.21184.44067.st...@tlendack-t1.amdoffice.net
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/process.c | 25 +++--
1 file changed, 15 in
http://lkml.kernel.org/r/20170313095019.19351-1...@alien8.de
Signed-off-by: Thomas Gleixner
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/reboot.h|1 +
arch/x86/kernel/cpu/mcheck/mce.c | 18 --
arch/x86/kernel/reboot.c |
al
Link: https://lkml.kernel.org/r/20180106010013.73suskgxm7lox...@dwarf.suse.cz
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/aperture_64.c | 46 +-
arch/x86/xen/mmu_hvm.c|2 -
2 files changed, 46 insertions
al
Link: https://lkml.kernel.org/r/20180106010013.73suskgxm7lox...@dwarf.suse.cz
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/aperture_64.c | 46 +-
arch/x86/xen/mmu_hvm.c|2 -
2 files changed, 46 insertions
britzki
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
britzki
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
britzki
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
asha 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)
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 to
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 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 to
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
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 to
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
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 sec
[ 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
[ 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
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
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 enabled.
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 enabled.
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 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 file
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 file
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 file
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 file
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 file
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 efi_me
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 efi_me
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 efi_me
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
http://lists.i
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.
>
> Suggested-
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 consumin
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 consumin
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 consumin
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 consumin
>
> 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
Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Stephen Rothwell
Cc: Takashi Iwai
Cc: Thomas Gleixner
Cc: Viresh Kumar
Cc: Vivek Goyal
Cc: kexec@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-j...@suse.com
Signed-o
Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Stephen Rothwell
Cc: Takashi Iwai
Cc: Thomas Gleixner
Cc: Viresh Kumar
Cc: Vivek Goyal
Cc: kexec@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-j...@suse.com
Signed-o
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 callbacks
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, l
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 supp
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 supp
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 supp
ned-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
ned-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
off-by: Michal 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/kerne
ned-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
off-by: Michal 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/kerne
off-by: Michal 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/kerne
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 supp
el.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: 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.
.secondary_trusted_key
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 f
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 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:
&
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
appropri
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
appropri
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
appropri
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
appropri
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
appropri
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
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 men
liams
> 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
> --
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 canno
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
> --wrapper=
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 Linux 5.
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.
> There
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 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?
One quick review note:
On Fri, Mar 07, 2025 at 12:57:35AM +, Pratyush Yadav wrote:
> +/**
> + * struct fdbox - A box of FDs.
> + * @name: Name of the box. Must be unique.
> + * @rwsem: Used to ensure exclusive access to the box during SEAL/UNSEAL
> + * operations.
> + * @dev: Backing d
82 matches
Mail list logo
