Ard Biesheuvel writes:
> From: Ard Biesheuvel
>
> The kexec purgatory is built like a kernel module, i.e., a partially
> linked ELF object where each section is allocated and placed
> individually, and all relocations need to be fixed up, even place
> relative ones.
>
> This makes sense for
Steve Wahl writes:
> [*really* added kexec maintainers this time.]
>
> Full thread starts here:
> https://lore.kernel.org/all/3a1b9909-45ac-4f97-ad68-d16ef1ce9...@pavinjoseph.com/
>
> On Wed, Mar 13, 2024 at 12:12:31AM +0530, Pavin Joseph wrote:
>> On 3/12/24 20:43, Steve Wahl wrote:
>> > But I
Baoquan He writes:
> On 01/30/24 at 06:18pm, yang.zhang wrote:
>> From: "yang.zhang"
>>
>> Because of alignment requirement in kexec-tools, there is
>> no problem for user buffer increasing when loading segments.
>> But when coping, the step is uchunk, so we should use uchunk
>> not mchunk.
>
Yuntao Wang writes:
> The end parameter received by kimage_is_destination_range() should be the
> last valid byte address of the target memory segment plus 1. However, in
> the locate_mem_hole_bottom_up() and locate_mem_hole_top_down() functions,
> the corresponding value passed to
Alexander Graf writes:
> Kexec today considers itself purely a boot loader: When we enter the new
> kernel, any state the previous kernel left behind is irrelevant and the
> new kernel reinitializes the system.
>
> However, there are use cases where this mode of operation is not what we
>
= irq_gc_shutdown,
> virt/kvm/kvm_main.c .shutdown = kvm_shutdown,
>
> This has been tested by doing a kexec on x86_64 and aarch64.
>From the 10,000 foot perspective:
Acked-by: "Eric W. Biederman"
Eric
> Fixes: 6735150b6997 ("KVM: Use syscore_ops i
"Gowans, James" writes:
> On Mon, 2023-12-11 at 09:54 +0200, James Gowans wrote:
>> >
>> > What problem are you running into with your rebase that worked with
>> > reboot notifiers that is not working with syscore_shutdown?
>>
>> Prior to this commit [1] which changed KVM from reboot notifiers
"Gowans, James" writes:
> Hi Sean,
>
> Blast from the past but I've just been bitten by this patch when
> rebasing across v6.4.
>
> On Fri, 2023-05-12 at 16:31 -0700, Sean Christopherson wrote:
>> Use syscore_ops.shutdown to disable hardware virtualization during a
>> reboot instead of using the
Joel Fernandes writes:
> On Mon, Oct 9, 2023 at 11:30 AM Eric W. Biederman
> wrote:
>>
>> Joel Fernandes writes:
>>
>> > On Mon, Oct 2, 2023 at 2:18 PM Joel Fernandes
>> > wrote:
>> > [..]
>> >> > > Such freezing is alrea
Joel Fernandes writes:
> On Mon, Oct 2, 2023 at 2:18 PM Joel Fernandes wrote:
> [..]
>> > > Such freezing is already being done if kernel supports KEXEC_JUMP and
>> > > kexec_image->preserve_context is true. However, doing it if either of
>> > > these are
>> > > not true prevents
"Joel Fernandes (Google)" writes:
> During kexec reboot, it is possible for a race to occur between
> device_shutdown() and userspace. This causes accesses to GPU after pm_runtime
> suspend has already happened. Fix this by calling freeze_processes() before
> device_shutdown().
Is there any
Albert Huang writes:
> From: "huangjie.albert"
>
> In many time-sensitive scenarios, we need a shorter time to restart
> the kernel. However, in the current kexec fast restart code, there
> are many places in the memory copy operation, verification operation
> and decompression operation,
Albert Huang writes:
> From: "huangjie.albert"
>
> Although the compressed kernel can save the time of loading the
> kernel into the memory and save the disk space for storing the kernel,
> but in some time-sensitive scenarios, the time for decompressing the
> kernel is intolerable. Therefore,
Valentin Schneider writes:
> Attempting to get a crash dump out of a debug PREEMPT_RT kernel via an NMI
> panic() doesn't work. The cause of that lies in the PREEMPT_RT definition
> of mutex_trylock():
>
> if (IS_ENABLED(CONFIG_DEBUG_RT_MUTEXES) && WARN_ON_ONCE(!in_task()))
>
Dave Hansen writes:
> ... adding kexec folks
>
> On 6/14/22 05:02, Kirill A. Shutemov wrote:
>> On kexec, the target kernel has to know what memory has been accepted.
>> Information in EFI map is out of date and cannot be used.
>>
>> boot_params.unaccepted_memory can be used to pass the bitmap
"Guilherme G. Piccoli" writes:
> The panic() function is somewhat convoluted - a lot of changes were
> made over the years, adding comments that might be misleading/outdated
> now, it has a code structure that is a bit complex to follow, with
> lots of conditionals, for example. The panic
Baoquan He writes:
> On 05/19/22 at 12:59pm, Eric W. Biederman wrote:
>> Baoquan He writes:
>>
>> > Hi Eric,
>> >
>> > On 05/18/22 at 04:59pm, Eric W. Biederman wrote:
>> >> "Naveen N. Rao" writes:
>> >>
>> >
Baoquan He writes:
> Hi Eric,
>
> On 05/18/22 at 04:59pm, Eric W. Biederman wrote:
>> "Naveen N. Rao" writes:
>>
>> > Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
>> > symbols") [1], binutils (v2.36+) starte
"Naveen N. Rao" writes:
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This isn't an issue in general, but with
> kexec_file.c, gcc is placing
Michael Ellerman writes:
> "Eric W. Biederman" writes:
>> Looking at this the pr_err is absolutely needed. If an unsupported case
>> winds up in the purgatory blob and the code can't handle it things
>> will fail silently much worse later.
>
> It won't
Looking at this the pr_err is absolutely needed. If an unsupported case
winds up in the purgatory blob and the code can't handle it things
will fail silently much worse later. So the proposed patch is
unfortunately the wrong direction.
"Naveen N. Rao" writes:
> Baoquan He wrote:
>> On
Joerg Roedel writes:
> Hi again,
>
> On Mon, Nov 01, 2021 at 04:11:42PM -0500, Eric W. Biederman wrote:
>> I seem to remember the consensus when this was reviewed that it was
>> unnecessary and there is already support for doing something like
>> this at a more fin
Björn Töpel writes:
> On Sat, 30 Oct 2021 at 05:51, Eric W. Biederman wrote:
>>
>> Liao Chang writes:
>>
>> > The pointer to buffer loading kernel binaries is in kernel space for
>> > kexec_fil mode, When copy_from_user copies data from pointe
Borislav Petkov writes:
> On Mon, Sep 13, 2021 at 05:55:52PM +0200, Joerg Roedel wrote:
>> From: Joerg Roedel
>>
>> Allow a runtime opt-out of kexec support for architecture code in case
>> the kernel is running in an environment where kexec is not properly
>> supported yet.
>>
>> This will
Liao Chang writes:
> The pointer to buffer loading kernel binaries is in kernel space for
> kexec_fil mode, When copy_from_user copies data from pointer to a block
> of memory, it checkes that the pointer is in the user space range, on
> RISCV-V that is:
>
> static inline bool
Coiby Xu writes:
> The code in bzImage64_verify_sig could make use of system keyrings including
> .buitin_trusted_keys, .secondary_trusted_keys and .platform keyring to verify
> signed kernel image as PE file. Make it generic so both x86_64 and arm64 can
> use it.
The naming is problematic.
Arnd Bergmann writes:
> On Tue, May 18, 2021 at 4:05 PM Arnd Bergmann wrote:
>>
>> On Tue, May 18, 2021 at 3:41 PM Eric W. Biederman
>> wrote:
>> >
>> > Arnd Bergmann writes:
>> >
>> > > From: Arnd Bergmann KEXEC_ARCH_DEFAU
Arnd Bergmann writes:
> On Tue, May 18, 2021 at 4:05 PM Arnd Bergmann wrote:
>>
>> On Tue, May 18, 2021 at 3:41 PM Eric W. Biederman
>> wrote:
>> >
>> > Arnd Bergmann writes:
>> >
>> > > From: Arnd Bergmann KEXEC_ARCH_DEFAU
l() check to simplify it and avoid the
> compat_alloc_user_space() call.
>
> compat_sys_kexec_load() now behaves the same as sys_kexec_load().
Nacked-by: "Eric W. Biederman"
The patch is wrong.
The logic between the compat entry point and the ordinary entry point
are by necessity differ
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> The compat version of sys_kexec_load() uses compat_alloc_user_space to
> convert the user-provided arguments into the native format.
>
> Move the conversion into the regular implementation with
> an in_compat_syscall() check to simplify it and
Joerg Roedel writes:
> On Thu, May 06, 2021 at 12:42:03PM -0500, Eric W. Biederman wrote:
>> I don't understand this.
>>
>> Fundamentally kexec is about doing things more or less inspite of
>> what the firmware is doing.
>>
>> I don't have any idea wha
Joerg Roedel writes:
> From: Joerg Roedel
>
> For now, kexec is not supported when running as an SEV-ES guest. Doing
> so requires additional hypervisor support and special code to hand
> over the CPUs to the new kernel in a safe way.
>
> Until this is implemented, do not support kexec in
as recent
stable kernels have seen the minor version to > 255. Just removing
kernel_version() looks like the best option.
Signed-off-by: "Eric W. Biederman"
---
Can folks please test this patch and verify that it works. I really
think simply removing the problem code is going to b
Liu Tao writes:
> Hello Eric,
>
> Please correct me if I'm wrong. After my research, I found that the
> KERNEL_VERSION
> check cannot be removed.
>
> In x86_64 case, function get_kernel_page_offset set different hard coded
> values into
> elf_info->page_offset according to KERNEL_VERSION, then
Liu Tao writes:
> Hello Eric,
>
> I'd like to have a try on this issue.
> Since I'm not very familiar with the related code, maybe I need to spend a
> little more time on it.
Please give it a shot.
Getting rid of explicit kernel version checks would be wonderful and
prevent future problems as
Greg KH writes:
> On Wed, Mar 31, 2021 at 04:03:24PM +0800, Baoquan He wrote:
>> Add Sasha and Greg to the CC list.
>>
>> On 03/31/21 at 11:48am, Baoquan He wrote:
>> > On 03/31/21 at 11:04am, Patrick Sung wrote:
>> > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote:
>> > > >
>> > > > On
chenzhou writes:
> On 2021/2/25 15:25, Baoquan He wrote:
>> On 02/24/21 at 02:19pm, Catalin Marinas wrote:
>>> On Sat, Jan 30, 2021 at 03:10:15PM +0800, Chen Zhou wrote:
Move CRASH_ALIGN to header asm/kexec.h for later use. Besides, the
alignment of crash kernel regions in x86 is
Will Deacon writes:
> On Fri, 19 Feb 2021 14:51:42 -0500, Pavel Tatashin wrote:
>> machine_kexec_post_load() is called after kexec load is finished. It must
>> declared in public header not in kexec_internal.h
>>
>> Fixes the following compiler warning:
>>
>>
Pavel Tatashin writes:
>> > I understand that having an extra set of page tables could potentially
>> > waste memory, especially if VAs are sparse, but in this case we use
>> > page tables exclusively for contiguous VA space (copy [src, src +
>> > size]). Therefore, the extra memory usage is
Pavel Tatashin writes:
> Hi James,
>
>> The problem I see with this is rewriting the relocation code. It needs to
>> work whether the
>> machine has enough memory to enable the MMU during kexec, or not.
>>
>> In off-list mail to Pavel I proposed an alternative implementation here:
>>
Alex Deucher writes:
> On Wed, Feb 3, 2021 at 3:36 AM Dave Young wrote:
>>
>> Hi Baoquan,
>>
>> Thanks for ccing.
>> On 01/28/21 at 01:29pm, Baoquan He wrote:
>> > On 01/11/21 at 01:17pm, Alexander E. Patrakov wrote:
>> > > Hello,
>> > >
>> > > I was trying out kexec on my new laptop, which is
Pavel Tatashin writes:
> kmsg_dump(KMSG_DUMP_SHUTDOWN) is called before
> machine_restart(), machine_halt(), machine_power_off(), the only one that
> is missing is machine_kexec().
>
> The dmesg output that it contains can be used to study the shutdown
> performance of both kernel and systemd
Thomas Gleixner writes:
> On Tue, Nov 17 2020 at 12:19, David Woodhouse wrote:
>> On Tue, 2020-11-17 at 10:53 +0100, Thomas Gleixner wrote:
>>> But that does not solve the problem either simply because then the IOMMU
>>> will catch the rogue MSIs and you get an interrupt storm on the IOMMU
>>>
Bjorn Helgaas writes:
> I don't think passing the device information to the kdump kernel is
> really practical. The kdump kernel would use it to do PCI config
> writes to disable MSIs before enabling IRQs, and it doesn't know how
> to access config space that early.
I don't think it is
ed
> callbacks in the PCI hotplug add/del path to update this information).
>
> [a]
> https://lore.kernel.org/lkml/1588812129-8596-1-git-send-email-anthony.yzn...@oracle.com/
>
> Below, inline reply to Eric's last message.
>
>
> On 15/11/2020 17:46, Eric W. Bi
Thomas Gleixner writes:
> On Sun, Nov 15 2020 at 08:29, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>> For ordinary irqs you can have this with level triggered irqs
>> and the kernel has code that will shutdown the irq at the ioapic
>&
ebied...@xmission.com (Eric W. Biederman) writes:
> Bjorn Helgaas writes:
>
>> [+cc Rafael for question about ACPI method for PCI host bridge reset]
>>
>> On Sat, Nov 14, 2020 at 09:58:08PM +0100, Thomas Gleixner wrote:
>>> On Sat, Nov 14 2020 at 14:39, Bjorn He
Bjorn Helgaas writes:
> [+cc Rafael for question about ACPI method for PCI host bridge reset]
>
> On Sat, Nov 14, 2020 at 09:58:08PM +0100, Thomas Gleixner wrote:
>> On Sat, Nov 14 2020 at 14:39, Bjorn Helgaas wrote:
>> > On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote:
>> >> On
ira.we...@intel.com writes:
> From: Ira Weiny
>
> This kmap() call is localized to a single thread. To avoid the over
> head of global PKRS updates use the new kmap_thread() call.
Acked-by: "Eric W. Biederman"
>
> Cc: Eric Biederman
> Signed-off-by: Ira Wein
(See below, didn't snip any comments)
>> > On 09/21/20 at 08:45pm, Eric W. Biederman wrote:
>> > > Konrad Rzeszutek Wilk writes:
>> > >
>> > > > On Fri, Sep 18, 2020 at 05:47:43PM -0700, Andrew Morton wrote:
>> > > >> On Fri, 18 S
Konrad Rzeszutek Wilk writes:
> On Fri, Sep 18, 2020 at 05:47:43PM -0700, Andrew Morton wrote:
>> On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote:
>>
>> > crash_kexec_post_notifiers enables running various panic notifier
>> > before kdump kernel booting. This increases risks of kdump
Adding the kexec list as well.
Joerg Vehlow writes:
> Hi Eric,
>> What is this patch supposed to be doing?
>>
>> What bug is it fixing?
> This information is part in the first message of this mail thread.
> The patch was intendedfor the active discussion in this thread,
> not for a broad
Kairui Song writes:
> Currently vmcore only supports reading, this patch series is an RFC
> to add writing support to vmcore. It's x86_64 only yet, I'll add other
> architecture later if there is no problem with this idea.
>
> My purpose of adding writing support is to reuse the crashed kernel's
Youling Tang writes:
> Add missing fclose()/close() call.
The program exits immediately and that exit closes all of the files.
What is the point of adding an explicit close?
>
> Signed-off-by: Youling Tang
> ---
> kexec/kexec.c | 28 ++--
> 1 file changed, 22
Alexander Popov writes:
> Add a simple test for CONFIG_SLAB_QUARANTINE.
>
> It performs heap spraying that aims to reallocate the recently freed heap
> object. This technique is used for exploiting use-after-free
> vulnerabilities in the kernel code.
>
> This test shows that
Sang Yan writes:
> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> copy all segments from vmalloced memory to kernel boot memory,
> because of disabled mmu.
I haven't seen kexec that slow since I tested on my 16Mhz 386.
That machine has an excuse it really is slow. Anything
Luis Chamberlain writes:
> Certain symbols are not meant to be used by everybody, the security
> helpers for reading files directly is one such case. Use a symbol
> namespace for them.
>
> This will prevent abuse of use of these symbols in places they were
> not inteded to be used, and provides
David Hildenbrand writes:
>>
>> Maybe we have enough information to fixup the loaded kexec image
>> in the kexec_file_load case, we certainly don't in the ordinary
>> kexec_load case.
>
> Yes, that's also what I mentioned in my reply to Baoquan.
>
>>
>> For now I want to stick to the simplest
David Hildenbrand writes:
> On 09.05.20 17:14, Eric W. Biederman wrote:
>> David Hildenbrand writes:
>>
>>> On 01.05.20 18:57, James Morse wrote:
>>>> On x86, the kexec payload contains a copy of the current memory map.
>>>> If memory is added
David Hildenbrand writes:
> On 01.05.20 18:57, James Morse wrote:
>> On x86, the kexec payload contains a copy of the current memory map.
>> If memory is added or removed, this copy of the memory map becomes
>> stale. Getting this wrong may prevent the next kernel from booting.
>> The first
Hari Bathini writes:
> On 05/05/20 3:29 am, Eric W. Biederman wrote:
>>
>> Recently a patch was proposed to kimage_alloc_page to slightly alter
>> the logic of how pages allocated with incompatible flags were
>> detected. The logic was being altered because t
, and handling of pages with different
gfp flags has been removed.
Signed-off-by: "Eric W. Biederman"
---
I have not done more than compile test this but I think this will remove
that tricky case in the kexec highmem support.
Any comments? Does anyone have a 32bit highmem system where the
I have added in the kexec mailling list.
Looking at the patch we are discussing it appears that the kexec code
could be doing much better in highmem situations today but is not.
Joonsoo Kim writes:
> 2020년 5월 1일 (금) 오후 11:06, Eric W. Biederman 님이 작성:
>>
>> js1...@g
David Hildenbrand writes:
>> The confusing part was talking about memory being still in use,
>> that is actually scheduled for use in the future.
>
> +1
>
>>
Usually somewhere in the loaded image
is a copy of the memory map at the time the kexec kernel was loaded.
That will
James Morse writes:
> Hi Eric,
>
> On 15/04/2020 21:33, Eric W. Biederman wrote:
>> James Morse writes:
>>
>>> An image loaded for kexec is not stored in place, instead its segments
>>> are scattered through memory, and are re-assembled when needed. In
James Morse writes:
> Hi Eric,
>
> On 15/04/2020 21:29, Eric W. Biederman wrote:
>> James Morse writes:
>>
>>> Hello!
>>>
>>> arm64 recently queued support for memory hotremove, which led to some
>>> new corner cases for kexec.
>&g
David Hildenbrand writes:
>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>>> pass the efi, it won't get the SRAT table correctly, if I remember
>>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>>> ACPI only, this won't happen on bare metal
James Morse writes:
> If kexec chooses to place the kernel in a memory region that was
> added after boot, we fail to boot as the kernel is running from a
> location that is not described as memory by the UEFI memory map or
> the original DT.
>
> To prevent unaware user-space kexec from doing
James Morse writes:
> Memory added to the system by hotplug has a 'System RAM' resource created
> for it. This is exposed to user-space via /proc/iomem.
>
> This poses problems for kexec on arm64. If kexec decides to place the
> kernel in one of these newly onlined regions, the new kernel will
James Morse writes:
> An image loaded for kexec is not stored in place, instead its segments
> are scattered through memory, and are re-assembled when needed. In the
> meantime, the target memory may have been removed.
>
> Because mm is not aware that this memory is still in use, it allows it
>
James Morse writes:
> Hello!
>
> arm64 recently queued support for memory hotremove, which led to some
> new corner cases for kexec.
>
> If the kexec segments are loaded for a removable region, that region may
> be removed before kexec actually occurs. This causes the first kernel to
> lockup
Andrew Morton writes:
> On Mon, 13 Apr 2020 08:15:23 -0500 ebied...@xmission.com (Eric W. Biederman)
> wrote:
>
>> > For 3), people can still use kexec_load and develop/fix for it, if no
>> > kexec_file_load supported. But 32-bit arm should be a different one,
>>
Baoquan He writes:
> On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
>>
>> The only benefit of kexec_file_load is that it is simple enough from a
>> kernel perspective that signatures can be checked.
>
> We don't have this restriction any more with below comm
The only benefit of kexec_file_load is that it is simple enough from a
kernel perspective that signatures can be checked.
kexec_load in every other respect is the more capable and functional
interface. It makes no sense to get rid of it.
It does make sense to reload with a loaded kernel on
cently in commit 90dc392fc445 ("x86: Remove
> the calgary IOMMU driver"), Calary IOMMU is removed and this variable
> no longer have any user.
>
> So just remove it.
>
> Signed-off-by: Kairui Song
Acked-by: "Eric W. Biederman"
Can we merge this through the tip tr
Andy Shevchenko writes:
> On Tue, Jan 21, 2020 at 12:18:03AM +0100, Ard Biesheuvel wrote:
>> On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko
>> wrote:
>> > On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman
>> > wrote:
>> > > Andy Shevchenko writes
Jean Delvare writes:
> On Mon, 20 Jan 2020 23:55:43 +0200, Andy Shevchenko wrote:
>> On Mon, Jan 20, 2020 at 11:44 PM Jean Delvare wrote:
>> >
>> > On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote:
>> > > Second. I looked at your te
Andy Shevchenko writes:
> On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
>> Ccing efi people.
>>
>> On 12/16/16 at 02:33pm, Jean Delvare wrote:
>> > On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote:
>> > > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
>> > > > On
Michael Weiser writes:
> Hello Eric,
> Hello Ard,
>
> on my machine, kexec_file loads the normal (not crash) kernel image
> right across the EFI ESRT reserved memory range:
>
> esrt: Reserving ESRT space from 0x74dd6f98 to 0x74dd6fd0.
> [...]
> kexec_file: kernel signature
lijiang writes:
> * Returns the length of the argument (regardless of if it was
> * truncated to fit in the buffer), or -1 on not found.
> */
> static int
> __cmdline_find_option(const char *cmdline, int max_cmdline_size,
> const char *option, char *buffer, int bufsize)
lijiang writes:
> 在 2019年10月15日 19:04, Eric W. Biederman 写道:
>> lijiang writes:
>>
>>> 在 2019年10月13日 11:54, Eric W. Biederman 写道:
>>>> Dave Young writes:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> On 1
lijiang writes:
> 在 2019年10月12日 20:16, Dave Young 写道:
>> Hi Eric,
>>
>> On 10/12/19 at 06:26am, Eric W. Biederman wrote:
>>> Lianbo Jiang writes:
>>>
>>>> When the crashkernel kernel command line option is specified, the
>>>> low 1
lijiang writes:
> 在 2019年10月13日 11:54, Eric W. Biederman 写道:
>> Dave Young writes:
>>
>>> Hi Eric,
>>>
>>> On 10/12/19 at 06:26am, Eric W. Biederman wrote:
>>>> Lianbo Jiang writes:
>>>>
>>>>> When the crashkern
Dave Young writes:
> Hi Eric,
>
> On 10/12/19 at 06:26am, Eric W. Biederman wrote:
>> Lianbo Jiang writes:
>>
>> > When the crashkernel kernel command line option is specified, the
>> > low 1MiB memory will always be reserved, which makes that the
Lianbo Jiang writes:
> When the crashkernel kernel command line option is specified, the
> low 1MiB memory will always be reserved, which makes that the memory
> allocated later won't fall into the low 1MiB area, thereby, it's not
> necessary to create a backup region and also no need to copy
p;& strstr(boot_command_line, "crashkernel="))
>>> + memblock_reserve(0, 640*1024);
>>> +
>>
>> Seems you missed the comment about "unconditionally do it", only check
>> crashkernel param looks better.
>>
> If so, it mea
Baoquan He writes:
> On 09/27/19 at 09:32pm, Eric W. Biederman wrote:
>> Baoquan He writes:
>>
>> > On 09/27/19 at 03:49pm, Eric W. Biederman wrote:
>> >> Dave Young writes:
>> >> >> In order to avoid such problem, lets occupy th
Baoquan He writes:
> On 09/27/19 at 03:49pm, Eric W. Biederman wrote:
>> Dave Young writes:
>> >> In order to avoid such problem, lets occupy the first 640k region when
>> >> SME is active, which will ensure that the allocated memory does not fall
>> &
Dave Young writes:
> Hi Lianbo,
>
> For kexec/kdump patches, please remember to cc kexec list next time.
> Also it is definitely kdump specific issue, I added Vivek and Eric in
> cc.
>
> On 09/20/19 at 11:53am, Lianbo Jiang wrote:
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204793
Pavel Tatashin writes:
> Currently, it is only allowed to reserve memory for crash kernel, because
> it is a requirement in order to be able to boot into crash kernel without
> touching memory of crashed kernel is to have memory reserved.
>
> The second benefit for having memory reserved for
Linus Torvalds writes:
> On Mon, Aug 20, 2018 at 10:58 AM Nick Desaulniers
> wrote:
>>
>> + akpm, Linus
>>
>> Bumping for review.
>
> Ugh. I am not personally a huge fan of this endless "fix up one at a time".
>
> Just do a patch that removes current_text_addr() entirely and be done
> with it,
Tetsuo Handa writes:
> I'm waiting for response from makedumpfile developers.
>
> But makedumpfile is a tool for saving kernel crash dump.
> If makedumpfile cannot work, we cannot use kernel crash dump.
I suspect the version string is comparable in size to the pointer to the
version string and
ew
> seconds.
>
> To increase system responsiveness to other tasks at that time,
> call cond_resched() in both the crash kernel and normal kernel
> segment loading loops.
>
> Signed-off-by: Jarrett Farnitano
Reviewed-by: "Eric W. Biederman"
> ---
> kernel/kexe
"Farnitano, Jarrett" writes:
>> On 6/11/18, 4:00 PM, "Eric W. Biederman" wrote:
>>
>> Is there a practical problem with unresponsiveness? You are talking
>> an embedded machine and rarely are there people in front of embedde
Jarrett Farnitano writes:
> Without yielding while loading kimage segments, a large initrd
> will block all other work on the CPU performing the load until
> it is completed. For example loading an initrd of 200MB on a
> low power single core system will lock up the system for a few
> seconds.
>
Paul Moore writes:
> On Tue, May 29, 2018 at 2:02 PM, Mimi Zohar wrote:
>> Both the init_module and finit_module syscalls call either directly
>> or indirectly the security_kernel_read_file LSM hook. This patch
>> replaces the direct call in init_module with a call to the new
>>
James Morris writes:
> On Fri, 25 May 2018, Eric W. Biederman wrote:
>
>> James Morris writes:
>>
>> > On Thu, 24 May 2018, Eric W. Biederman wrote:
>> >
>> >> Below is where I suggest you start on sorting out these security hooks.
>> &g
Petr Tesarik writes:
> On Fri, 25 May 2018 15:00:13 -0500
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
>>[...]
>> The ultimate point is that the absolute best we can do is to run a
>> kernel in memory that we never use for anything else and then we have a
&g
Petr Tesarik <ptesa...@suse.cz> writes:
> V Thu, 24 May 2018 11:34:05 -0500
> ebied...@xmission.com (Eric W. Biederman) napsáno:
>
>> Petr Tesarik <ptesa...@suse.cz> writes:
>>
>> 2> On Thu, 24 May 2018 09:49:05 +0800
>> > Dave Yo
James Morris <jmor...@namei.org> writes:
> On Thu, 24 May 2018, Eric W. Biederman wrote:
>
>> Below is where I suggest you start on sorting out these security hooks.
>> - Adding a security_kernel_arg to catch when you want to allow/deny the
>> use of a
1 - 100 of 534 matches
Mail list logo
