Re: [PATCH bpf-next v2] bpf: fix warning for crash_kexec

2024-03-21 Thread Hari Bathini
On 20/03/24 4:26 am, Andrii Nakryiko wrote: On Tue, Mar 19, 2024 at 1:02 AM Hari Bathini wrote: With [1], crash dump specific code is moved out of CONFIG_KEXEC_CORE and placed under CONFIG_CRASH_DUMP, where it is more appropriate. And since CONFIG_KEXEC & !CONFIG_CRASH_DUMP build option is

Re: [PATCH V2] x86/kexec: do not update E820 kexec table for setup_data

2024-03-21 Thread Dave Young
> > Your tree is missing this recent commit: > > 7fd817c906503b6813ea3b41f5fdf4192449a707 ("x86/e820: Don't > > reserve SETUP_RNG_SEED in e820"). > > > > Wouldn't this fix [/paper over] your problem as well? I.e., isn't > > SETUP_RNG_SEED the setup_data item that's causing your problem? > > Thanks

[PATCH V3] x86/kexec: do not update E820 kexec table for setup_data

2024-03-21 Thread Dave Young
crashkernel reservation failed on a Thinkpad t440s laptop recently. Actually the memblock reservation succeeded, but later insert_resource() failed. Test steps: kexec load -> /* make sure add crashkernel param eg. crashkernel=160M */ kexec reboot -> dmesg|grep "crashkernel

Re: [PATCH V2] x86/kexec: do not update E820 kexec table for setup_data

2024-03-21 Thread Dave Young
Hi Jiri, On Thu, 21 Mar 2024 at 18:32, Jiri Bohac wrote: > > Hi, > > On Thu, Mar 21, 2024 at 05:23:20PM +0800, Dave Young wrote: > > crashkernel reservation failed on a Thinkpad t440s laptop recently. > > Actually the memblock reservation succeeded, but later insert_resource() > > failed. > > >

Re: Question about Address Range Validation in Crash Kernel Allocation

2024-03-21 Thread Baoquan He
On 03/21/24 at 08:37pm, Li Huafei wrote: > > > On 2024/3/21 18:06, Dave Young wrote: > > Hi, > > > > On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: > >> > >> Hi Baoquan, > >> > >> On 2024/3/21 17:17, chenhaixiang (A) wrote: > >>> > > I'm sorry for the delay. Here are some details from the

Re: [PATCH bpf-next v2] bpf: fix warning for crash_kexec

2024-03-21 Thread Yonghong Song
On 3/19/24 3:56 PM, Andrii Nakryiko wrote: On Tue, Mar 19, 2024 at 1:02 AM Hari Bathini wrote: With [1], crash dump specific code is moved out of CONFIG_KEXEC_CORE and placed under CONFIG_CRASH_DUMP, where it is more appropriate. And since CONFIG_KEXEC & !CONFIG_CRASH_DUMP build option is

Re: [PATCH v2 2/3] x86/mm: Do not zap page table entries mapping unaccepted memory table during kdump.

2024-03-21 Thread Kirill A. Shutemov
On Mon, Mar 18, 2024 at 07:02:45AM +, Ashish Kalra wrote: > From: Ashish Kalra > > During crashkernel boot only pre-allocated crash memory is presented as > E820_TYPE_RAM. This can cause page table entries mapping unaccepted memory > table to be zapped during phys_pte_init(),

Re: [PATCH v8 14/15] x86: Secure Launch late initcall platform module

2024-03-21 Thread Daniel P. Smith
Hi Ard, On 2/23/24 04:36, Ard Biesheuvel wrote: On Thu, 22 Feb 2024 at 14:58, Daniel P. Smith wrote: On 2/15/24 03:40, Ard Biesheuvel wrote: On Wed, 14 Feb 2024 at 23:32, Ross Philipson wrote: From: "Daniel P. Smith" The Secure Launch platform module is a late init module. During the

Re: [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset

2024-03-21 Thread Daniel P. Smith
Hi Ard! On 2/15/24 02:56, Ard Biesheuvel wrote: On Wed, 14 Feb 2024 at 23:31, Ross Philipson wrote: From: Arvind Sankar There are use cases for storing the offset of a symbol in kernel_info. For example, the trenchboot series [0] needs to store the offset of the Measured Launch Environment

Re: Question about Address Range Validation in Crash Kernel Allocation

2024-03-21 Thread Li Huafei
On 2024/3/21 18:06, Dave Young wrote: > Hi, > > On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: >> >> Hi Baoquan, >> >> On 2024/3/21 17:17, chenhaixiang (A) wrote: >>> > I'm sorry for the delay. Here are some details from the boot log and /proc/iomem: > The Boot log: > [

[PATCH] crashdump-x86.c:Add a check for the crash kernel range in exclude_region()

2024-03-21 Thread chenhaixiang
In some cases, such as start < mstart < mend < end when exclude_region(), this results in crash_memory_range[i].end becoming less than crash_memory_range[i].start, leading to incorrect address ranges. Adding a range check should be necessary. Signed-off-by: chenhaixiang chenhaixia...@huawei.com

Re: [PATCH V2] x86/kexec: do not update E820 kexec table for setup_data

2024-03-21 Thread Jiri Bohac
Hi, On Thu, Mar 21, 2024 at 05:23:20PM +0800, Dave Young wrote: > crashkernel reservation failed on a Thinkpad t440s laptop recently. > Actually the memblock reservation succeeded, but later insert_resource() > failed. > > Test steps: > kexec load -> /* make sure add crashkernel param eg.

Re: Question about Address Range Validation in Crash Kernel Allocation

2024-03-21 Thread Dave Young
Hi, On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: > > Hi Baoquan, > > On 2024/3/21 17:17, chenhaixiang (A) wrote: > > > >>> I'm sorry for the delay. Here are some details from the boot log and > >> /proc/iomem: > >>> The Boot log: > >>> [0.00] Linux version 6.8.0

Re: Question about Address Range Validation in Crash Kernel Allocation

2024-03-21 Thread Li Huafei
Hi Baoquan, On 2024/3/21 17:17, chenhaixiang (A) wrote: > >>> I'm sorry for the delay. Here are some details from the boot log and >> /proc/iomem: >>> The Boot log: >>> [0.00] Linux version 6.8.0 (root@localhost.localdomain) (gcc (GCC) >> 10.3.1, GNU ld (GNU Binutils) 2.37) #3 SMP

[PATCH V2] x86/kexec: do not update E820 kexec table for setup_data

2024-03-21 Thread Dave Young
crashkernel reservation failed on a Thinkpad t440s laptop recently. Actually the memblock reservation succeeded, but later insert_resource() failed. Test steps: kexec load -> /* make sure add crashkernel param eg. crashkernel=160M */ kexec reboot -> dmesg|grep "crashkernel

Re: Question about Address Range Validation in Crash Kernel Allocation

2024-03-21 Thread chenhaixiang (A)
> > I'm sorry for the delay. Here are some details from the boot log and > /proc/iomem: > > The Boot log: > > [0.00] Linux version 6.8.0 (root@localhost.localdomain) (gcc (GCC) > 10.3.1, GNU ld (GNU Binutils) 2.37) #3 SMP PREEMPT_DYNAMIC Wed Mar 20 > 11:46:11 UTC 2024 > > [0.00]

[PATCH] util_lib/elf_info.c: fix a warning

2024-03-21 Thread Baoquan He
There's a incorrect array operation in function scan_vmcoreinfo(), it will cause below warning message. --- util_lib/elf_info.c: In function ‘scan_vmcoreinfo’: util_lib/elf_info.c:360:43: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 360 |

Re: Question about Address Range Validation in Crash Kernel Allocation

2024-03-21 Thread Baoquan He
On 03/21/24 at 03:22am, chenhaixiang (A) wrote: > I'm sorry for the delay. Here are some details from the boot log and > /proc/iomem: > The Boot log: > [0.00] Linux version 6.8.0 (root@localhost.localdomain) (gcc (GCC) > 10.3.1, GNU ld (GNU Binutils) 2.37) #3 SMP PREEMPT_DYNAMIC Wed Mar

Re: [RFC PATCH v3 0/7] device backed vmemmap crash dump support

2024-03-21 Thread Zhijian Li (Fujitsu)
Baoquan, On 21/03/2024 14:17, Baoquan He wrote: > On 03/21/24 at 05:40am, Zhijian Li (Fujitsu) wrote: >> ping >> >> >> Any comment is welcome. > > I will have a look at this from kdump side. How do you test your code? Thanks for your support. - nothing change is required for makedumpfile and

Re: [RFC PATCH v3 0/7] device backed vmemmap crash dump support

2024-03-21 Thread Baoquan He
On 03/21/24 at 05:40am, Zhijian Li (Fujitsu) wrote: > ping > > > Any comment is welcome. I will have a look at this from kdump side. How do you test your code? By the way, there's issue reported by test robot. Thanks Baoquan > > > On 06/03/2024 18:28, Li Zhijian wrote: > > Hello folks, > >