Hari Bathini writes:
> Though kdump kernel boots from loaded address, the first 64KB of it is
> copied down to real 0. So, setup a backup region and let purgatory
> copy the first 64KB of crashed kernel into this backup region before
> booting into kdump kernel. Update reserve map with backup
On 07/27/2020 03:36 AM, Hari Bathini wrote:
> Sorry! There was a gateway issue on my system while posting v5, due to
> which some patches did not make it through. Resending...
>
> This patch series enables kdump support for kexec_file_load system
> call (kexec -s -p) on PPC64. The changes are
On (20/07/21 08:40), Linus Torvalds wrote:
> On Tue, Jul 21, 2020 at 7:42 AM Sergey Senozhatsky
> wrote:
> >
> > OK, so basically, extending printk_caller_id() so that for IRQ/NMI
> > we will have more info than just "0x8000 + raw_smp_processor_id()".
>
> I think it's really preempt_count()
Hari Bathini writes:
> Kernel built with CONFIG_PPC_EARLY_DEBUG_OPAL enabled expects r8 & r9
> to be filled with OPAL base & entry addresses respectively. Setting
> these registers allows the kernel to perform OPAL calls before the
> device tree is parsed.
>
> Signed-off-by: Hari Bathini
Hari Bathini writes:
> Kdump kernel, used for capturing the kernel core image, is supposed
> to use only specific memory regions to avoid corrupting the image to
> be captured. The regions are crashkernel range - the memory reserved
> explicitly for kdump kernel, memory used for the tce-table,
On Fri, Jul 03, 2020 at 11:58:15AM +0800, Chen Zhou wrote:
> commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
> broken the arm64 kdump. If the memory reserved for crash dump kernel
> falled in ZONE_DMA32, the devices in crash dump kernel need to use
> ZONE_DMA will alloc fail.
>
>
Patch 11-14 work for me but I have little knowledge to comment on these
patches.
On 2020-07-22 12:30 p.m., Kees Cook wrote:
There are a few places in the kernel where LSMs would like to have
visibility into the contents of a kernel buffer that has been loaded or
read. While
On Wed, Jul 22, 2020 at 03:29:26PM -0700, Scott Branden wrote:
> These changes don't pass the kernel-selftest for partial reads I added
> (which are at the end of this patch v2 series).
Oh, interesting. Is there any feedback in dmesg? I wonder if I have the
LSMs configured differently than you?
On 2020-07-23 12:17 p.m., Kees Cook wrote:
On Wed, Jul 22, 2020 at 11:23:43PM -0700, Scott Branden wrote:
I made an adjustment in the logic of the driver with use of
request_partial_firmware_into_buf and now everything is working.
Excellent! Was there something wrong with how I ported the
On 2020-07-22 3:29 p.m., Scott Branden wrote:
Hi Kees,
These changes don't pass the kernel-selftest for partial reads I added
(which are at the end of this patch v2 series).
See change below added for temp workaround for issue.
Even with such change real request_partial_firmware_into_buf
works.
On 2020-07-22 12:30 p.m., Kees Cook wrote:
In preparation for adding partial read support, add an optional output
argument to kernel_read_file*() that reports the file size so callers
can reason more easily about their reading progress.
Signed-off-by: Kees Cook
Acked-by: Scott Branden
On Thu, Jul 23, 2020 at 10:41:07PM -0700, Scott Branden wrote:
>
>
> On 2020-07-23 12:15 p.m., Kees Cook wrote:
> > On Wed, Jul 22, 2020 at 03:29:26PM -0700, Scott Branden wrote:
> > > These changes don't pass the kernel-selftest for partial reads I added
> > > (which are at the end of this
On Fri, Jul 24, 2020 at 11:23:37AM -0700, Kees Cook wrote:
> On Thu, Jul 23, 2020 at 10:41:07PM -0700, Scott Branden wrote:
> >
> >
> > On 2020-07-23 12:15 p.m., Kees Cook wrote:
> > > On Wed, Jul 22, 2020 at 03:29:26PM -0700, Scott Branden wrote:
> > > > These changes don't pass the
works
On 2020-07-22 12:30 p.m., Kees Cook wrote:
In preparation for refactoring kernel_read_file*(), remove the redundant
"size" argument which is not needed: it can be included in the return
code, with callers adjusted. (VFS reads already cannot be larger than
INT_MAX.)
Signed-off-by: Kees
Hi Kees,
These changes don't pass the kernel-selftest for partial reads I added
(which are at the end of this patch v2 series).
See change below added for temp workaround for issue.
Even with such change real request_partial_firmware_into_buf doesn't
work fully with my bcm-vk driver. I'm trying
On Wed, 22 Jul 2020 12:30:04 -0700 Kees Cook wrote:
> The firmware tests would always time out for me. Add a correct timeout,
> including details on how the value was reached. Additionally allow the
> test harness to skip comments in settings files and report how long a
> given timeout was.
>
>
works.
On 2020-07-22 12:30 p.m., Kees Cook wrote:
The firmware tests would always time out for me. Add a correct timeout,
including details on how the value was reached. Additionally allow the
test harness to skip comments in settings files and report how long a
given timeout was.
Looks good.
On 2020-07-22 12:30 p.m., Kees Cook wrote:
On non-EFI systems, it wasn't possible to test the platform firmware
loader because it will have never set "checked_fw" during __init.
Instead, allow the test code to override this check. Additionally split
the declarations into a private
On Wed, Jul 22, 2020 at 11:23:43PM -0700, Scott Branden wrote:
> I made an adjustment in the logic of the driver with use of
> request_partial_firmware_into_buf and now everything is working.
Excellent! Was there something wrong with how I ported the
request_partial_firmware_into_buf() changes?
On Fri, Jul 24, 2020 at 12:03:36PM -0700, Scott Branden wrote:
> Now I'm confused. The original patch series I made with IMA additions under
> Mimi's direction
> passed the kernel selftests with partial read. And
> request_partial_firmware_into_buf therefore worked.
> Your changes don't work
Hi Kees,
On 2020-07-24 11:39 a.m., Kees Cook wrote:
On Fri, Jul 24, 2020 at 11:23:37AM -0700, Kees Cook wrote:
On Thu, Jul 23, 2020 at 10:41:07PM -0700, Scott Branden wrote:
On 2020-07-23 12:15 p.m., Kees Cook wrote:
On Wed, Jul 22, 2020 at 03:29:26PM -0700, Scott Branden wrote:
These
works.
On 2020-07-22 12:30 p.m., Kees Cook wrote:
In preparation for further refactoring of kernel_read_file*(), rename
the "max_size" argument to the more accurate "buf_size", and correct
its type to size_t. Add kerndoc to explain the specifics of how the
arguments will be used. Note that with
On 7/3/20 3:38 AM, chenzhou wrote:
Hi Bhupesh,
On 2020/7/3 15:26, Bhupesh Sharma wrote:
Hi Chen,
On Fri, Jul 3, 2020 at 9:24 AM Chen Zhou wrote:
This patch series enable reserving crashkernel above 4G in arm64.
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve
On (20/07/21 15:31), John Ogness wrote:
> With commit ("printk: use the lockless ringbuffer"), printk()
> started silently dropping messages without text because such
> records are not supported by the new printk ringbuffer.
>
> Add support for such records.
>
> Currently dataless records are
24 matches
Mail list logo
