Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread Christoph Hellwig
On Tue, Dec 14, 2021 at 11:07:34AM -0600, john.p.donne...@oracle.com wrote: > Is CONFIG_ZONE_DMA even needed anymore in x86_64 ? Yes. There are still plenty of addressing challenged devices, mostly ISA-like but also a few PCI/PCIe ones. ___ kexec mail

Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread Christoph Hellwig
On Wed, Dec 15, 2021 at 07:03:35AM +, Hyeonggon Yoo wrote: > I'm not sure that allocating from ZONE_DMA32 instead of ZONE_DMA > for kdump kernel is nice way to solve this problem. What is the problem with zones in kdump kernels? > Devices that requires ZONE_DMA memory is rare but we still sup

Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread Hyeonggon Yoo
On Wed, Dec 15, 2021 at 04:48:26AM +, Hyeonggon Yoo wrote: > > Hello Baoquan and Vlastimil. > > I'm not sure allowing ZONE_DMA32 for kdump kernel is nice way to solve > this problem. Devices that requires ZONE_DMA is rare but we still > support them. > > If we allow ZONE_DMA32 for ZONE_DMA i

Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()

2021-12-14 Thread Baoquan He
On 12/14/21 at 03:24pm, Borislav Petkov wrote: > On Tue, Dec 14, 2021 at 05:56:57PM +0800, Baoquan He wrote: > > Ah, OK, I see the new paragraph from you added in below commit. > > That is supposed to make it absolutely clear and explicit. There are > other hints as to what a subsequent SOB means

[PATCH kernel-next] kernel: remove redundant result variable

2021-12-14 Thread cgel . zte
From: Minghao Chi Return value from kimage_add_entry() directly instead of taking this in another redundant variable. Reported-by: Zeal Robot Signed-off-by: Minghao Chi --- kernel/kexec_core.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/kernel/kexec_core.c b

Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread Hyeonggon Yoo
On Tue, Dec 14, 2021 at 11:09:23AM +0100, Vlastimil Babka wrote: > On 12/14/21 06:32, Baoquan He wrote: > > On 12/13/21 at 01:43pm, Hyeonggon Yoo wrote: > >> Hello Baoquan. I have a question on your code. > >> > >> On Mon, Dec 13, 2021 at 08:27:12PM +0800, Baoquan He wrote: > >> > Dma-kmalloc will

Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent

2021-12-14 Thread Baoquan He
On 12/14/21 at 07:24pm, Catalin Marinas wrote: > On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote: > > On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: > > > From: Chen Zhou > > > > > > The lower bounds of crash kernel reservation and crash kernel low > > > reservation are

Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent

2021-12-14 Thread Leizhen (ThunderTown)
On 2021/12/15 3:24, Catalin Marinas wrote: > On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote: >> On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: >>> From: Chen Zhou >>> >>> The lower bounds of crash kernel reservation and crash kernel low >>> reservation are different,

Re: [PATCH 0/3] arm64: make phys_to_virt() correct

2021-12-14 Thread Pingfan Liu
+ AKASHI Takahiro + Simon Horman Thank you guys for any suggestions. And vmcore-dmesg just can not work for 52-bits VA arm64 now. Thanks, Pingfan On Fri, Dec 10, 2021 at 11:07 AM Pingfan Liu wrote: > > Currently phys_to_virt() does not work well on 52-bits VA arm64 kernel. > One issue is contri

RE: [RFC PATCH] makedumpfile: add userinfo elf section 0/4]

2021-12-14 Thread 萩尾 一仁
Hi Ivan, sorry for the delay. -Original Message- > These patchset suggests feature to add user specific information along > with dumpfile. One of usecases could be a platform build information > containing dubug file addresses, sources of daily build, some > platform related information a

Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent

2021-12-14 Thread Catalin Marinas
On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote: > On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: > > From: Chen Zhou > > > > The lower bounds of crash kernel reservation and crash kernel low > > reservation are different, use the consistent value CRASH_ALIGN. > > A bi

Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent

2021-12-14 Thread Borislav Petkov
On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: > From: Chen Zhou > > The lower bounds of crash kernel reservation and crash kernel low > reservation are different, use the consistent value CRASH_ALIGN. A big WHY is missing here to explain why the lower bound of the allocation range ne

Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread john . p . donnelly
On 12/14/21 10:31 AM, Christoph Hellwig wrote: On Mon, Dec 13, 2021 at 08:27:12PM +0800, Baoquan He wrote: Dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled. However, it will fail if DMA zone has no managed pages. The failure can be seen in kdump kernel of x86_64 as below: Plea

Re: [PATCH] kernel/crash_core.c: No judgment required

2021-12-14 Thread Philipp Rudo
Hi lizhe, On Thu, 9 Dec 2021 19:20:03 -0800 lizhe wrote: > No judgment required ck_cmdline is NULL > its caller has alreadly judged, see __parse_crashkernel > function > > Signed-off-by: lizhe > --- > kernel/crash_core.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/kernel/cras

Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread Christoph Hellwig
On Mon, Dec 13, 2021 at 08:27:12PM +0800, Baoquan He wrote: > Dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled. > However, it will fail if DMA zone has no managed pages. The failure > can be seen in kdump kernel of x86_64 as below: Please just switch the sr allocation to use GFP_K

Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()

2021-12-14 Thread Borislav Petkov
On Tue, Dec 14, 2021 at 05:56:57PM +0800, Baoquan He wrote: > Ah, OK, I see the new paragraph from you added in below commit. That is supposed to make it absolutely clear and explicit. There are other hints as to what a subsequent SOB means in that document already. Just the next section says: "

Re: [PATCH v2 0/2] kdump: simplify code

2021-12-14 Thread Matthew Wilcox
On Tue, Dec 14, 2021 at 06:03:11PM +0800, Tiezhu Yang wrote: > On 12/13/2021 10:43 PM, Matthew Wilcox wrote: > > On Mon, Dec 13, 2021 at 08:30:33AM +, David Laight wrote: > > > From: Matthew Wilcox > > > > Sent: 12 December 2021 11:48 > > > > > > > > On Sat, Dec 11, 2021 at 05:53:46PM +, D

Re: [PATCH v17 05/10] x86: kdump: move reserve_crashkernel[_low]() into crash_core.c

2021-12-14 Thread Leizhen (ThunderTown)
On 2021/12/14 18:45, Baoquan He wrote: >> +/* User specifies base address explicitly. */ > If you plan to repost, please take above sentence off either. Then we > can say this patch is only doing code moving. > >> +unsigned long long start; >> + > OK, I can see that this

Re: [PATCH v17 04/10] x86: kdump: move xen_pv_domain() check and insert_resource() to setup_arch()

2021-12-14 Thread Leizhen (ThunderTown)
On 2021/12/10 14:55, Zhen Lei wrote: > From: Chen Zhou > > We will make the functions reserve_crashkernel() as generic, the > xen_pv_domain() check in reserve_crashkernel() is relevant only to > x86, the same as insert_resource() in reserve_crashkernel[_low](). > So move xen_pv_domain() check

Re: [PATCH v17 05/10] x86: kdump: move reserve_crashkernel[_low]() into crash_core.c

2021-12-14 Thread Baoquan He
On 12/10/21 at 02:55pm, Zhen Lei wrote: > From: Chen Zhou > > Make the functions reserve_crashkernel[_low]() as generic. Since > reserve_crashkernel[_low]() implementations are quite similar on other > architectures as well, we can have more users of this later. > > So have CONFIG_ARCH_WANT_RESE

Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread Christoph Lameter
On Tue, 14 Dec 2021, Vlastimil Babka wrote: > If doesn't feel right to me to fix (or rather workaround) this on the level > of kmalloc caches just because the current reports come from there. If we > decide it's acceptable for kdump kernel to return !ZONE_DMA memory for > GFP_DMA requests, then it

Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

2021-12-14 Thread Vlastimil Babka
On 12/14/21 06:32, Baoquan He wrote: > On 12/13/21 at 01:43pm, Hyeonggon Yoo wrote: >> Hello Baoquan. I have a question on your code. >> >> On Mon, Dec 13, 2021 at 08:27:12PM +0800, Baoquan He wrote: >> > Dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled. >> > However, it will fail

Re: [PATCH v2 0/2] kdump: simplify code

2021-12-14 Thread Tiezhu Yang
On 12/13/2021 10:43 PM, Matthew Wilcox wrote: On Mon, Dec 13, 2021 at 08:30:33AM +, David Laight wrote: From: Matthew Wilcox Sent: 12 December 2021 11:48 On Sat, Dec 11, 2021 at 05:53:46PM +, David Laight wrote: From: Tiezhu Yang Sent: 11 December 2021 03:33 v2: -- add copy_to_use

Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()

2021-12-14 Thread Baoquan He
On 12/14/21 at 10:38am, Borislav Petkov wrote: > On Tue, Dec 14, 2021 at 04:54:40PM +0800, Baoquan He wrote: > > If you didn't contribute change, Signed-off-by should be taken off. > > The second SOB is correct here. I'll let you figure it out what it > means. > > Hint: Documentation/process/subm

Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()

2021-12-14 Thread Borislav Petkov
On Tue, Dec 14, 2021 at 04:54:40PM +0800, Baoquan He wrote: > If you didn't contribute change, Signed-off-by should be taken off. The second SOB is correct here. I'll let you figure it out what it means. Hint: Documentation/process/submitting-patches.rst -- Regards/Gruss, Boris. https://pe

Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN

2021-12-14 Thread Leizhen (ThunderTown)
On 2021/12/14 3:54, Borislav Petkov wrote: >> Subject: Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment >> with macro CRASH_ALIGN > >>From Documentation/process/maintainer-tip.rst: > > "Patch subject > ^ > > The tip tree preferred format for patch subject prefi

Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()

2021-12-14 Thread Baoquan He
On 12/10/21 at 02:55pm, Zhen Lei wrote: > From: Chen Zhou > > To make the functions reserve_crashkernel() as generic, > replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX. > > Signed-off-by: Chen Zhou > Signed-off-by: Zhen Lei If you made change to this patch, please remove the old

Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent

2021-12-14 Thread Leizhen (ThunderTown)
On 2021/12/13 21:37, Baoquan He wrote: > On 12/10/21 at 02:55pm, Zhen Lei wrote: >> From: Chen Zhou >> >> The lower bounds of crash kernel reservation and crash kernel low >> reservation are different, use the consistent value CRASH_ALIGN. >> >> Suggested-by: Dave Young >> Signed-off-by: Chen

Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN

2021-12-14 Thread Leizhen (ThunderTown)
On 2021/12/13 21:17, Baoquan He wrote: > On 12/10/21 at 02:55pm, Zhen Lei wrote: >> From: Chen Zhou >> >> Move CRASH_ALIGN to header asm/kexec.h for later use. >> >> Suggested-by: Dave Young >> Suggested-by: Baoquan He > > I remember Dave and I discussed and suggested this when reviewing. >