Re: [PATCH 1/3] memblock: define functions to set the usable memory range

2022-01-14 Thread Frank van der Linden
On Thu, Jan 13, 2022 at 07:33:11PM +0200, Mike Rapoport wrote: > On Tue, Jan 11, 2022 at 08:44:41PM +, Frank van der Linden wrote: > > On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote: > > > > --- a/include/linux/memblock.h > > > > +++ b/include/linux/memblock.h > > > > @@ -481,6

Re: [PATCH V4] notifier/panic: Introduce panic_notifier_filter

2022-01-14 Thread Guilherme G. Piccoli
Hey folks, sorry for the ping. But is there any extra reviews? All comments are much appreciated! Dave, what do you think about the patch? I remember we talked about it in [0], seems you considered that a good idea right? Thanks in advance, Guilherme [0]

[PATCH V3] panic: Move panic_print before kmsg dumpers

2022-01-14 Thread Guilherme G. Piccoli
The panic_print setting allows users to collect more information in a panic event, like memory stats, tasks, CPUs backtraces, etc. This is a pretty interesting debug mechanism, but currently the print event happens *after* kmsg_dump(), meaning that pstore, for example, cannot collect a dmesg with

Re: [PATCH v3 0/5] s390: add support for extended cmdline length

2022-01-14 Thread Simon Horman
On Thu, Dec 16, 2021 at 12:43:51PM +0100, Sven Schnelle wrote: > Hi, > > this patchset adds support for extended command line lengths on s390. > The former limit of 896 has been too short in a some configurations. The > linux kernel now provides an additional field in the parameter area > which

Re: [PATCH 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()

2022-01-14 Thread Simon Horman
On Mon, Jan 10, 2022 at 06:26:54PM +0100, Heiko Carstens wrote: > On Mon, Jan 10, 2022 at 04:23:05PM +0100, Alexander Egorenkov wrote: > > Heiko Carstens writes: > > > Given that Alexander is currently not available, I will resend his > > > patch with an updated commit message. > > > > Many

Re: [PATCH v5] arm64: support more than one crash kernel regions

2022-01-14 Thread Simon Horman
On Mon, Jan 10, 2022 at 06:20:08PM +0800, Zhen Lei wrote: > From: Chen Zhou > > When crashkernel is reserved above 4G in memory, kernel should > reserve some amount of low memory for swiotlb and some DMA buffers. > So there may be two crash kernel regions, one is below 4G, the other > is above

Re: [PATCHv2 1/1] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()

2022-01-14 Thread Simon Horman
On Wed, Dec 15, 2021 at 06:48:53PM +0100, Heiko Carstens wrote: > From: Alexander Egorenkov > > Starting with gcc 11.3, the C compiler will generate PLT-relative function > calls even if they are local and do not require it. Later on during linking, > the linker will replace all PLT-relative

Re: [PATCHv3 0/4] arm64: make phys_to_virt() correct

2022-01-14 Thread Simon Horman
Hi Pingfan, On Tue, Dec 28, 2021 at 09:26:55PM +0800, Pingfan Liu wrote: > Currently phys_to_virt() does not work well on 52-bits VA arm64 kernel. > One issue is contributed by phys_offset not signed. > The other is contributed by wrong page_offset. > > v2 -> v3: > Discussed with Kairui

Re: [PATCHv3 2/4] arm64/crashdump: unify routine to get page_offset

2022-01-14 Thread Simon Horman
On Tue, Dec 28, 2021 at 09:26:57PM +0800, Pingfan Liu wrote: > There are two funcs to get page_offset: > get_kernel_page_offset() > get_page_offset() > > Since get_kernel_page_offset() does not observe the kernel formula, and > remove it. Unify them in order to introduce 52-bits VA kernel

Re: [PATCHv3 1/4] arm64: make phys_offset signed

2022-01-14 Thread Simon Horman
On Tue, Dec 28, 2021 at 09:26:56PM +0800, Pingfan Liu wrote: > After kernel commit 7bc1a0f9e176 ("arm64: mm: use single quantity to > represent the PA to VA translation"), phys_offset can be negative if > running 52-bits kernel on 48-bits hardware. > > So changing phys_offset from unsigned to

Re: [PATCH V2] panic: Move panic_print before kmsg dumpers

2022-01-14 Thread Guilherme G. Piccoli
On 14/01/2022 09:26, Petr Mladek wrote: > [...] > I see. OK, it makes sense to call it after the panic notifiers when > they are used. It would be nice to mention the above in the commit > message and explain why the 2nd call is there. > > Just an idea. It might be better to move the 1st call

Re: [PATCH V2] panic: Move panic_print before kmsg dumpers

2022-01-14 Thread Petr Mladek
On Thu 2022-01-13 12:15:08, Guilherme G. Piccoli wrote: > On 13/01/2022 11:22, Petr Mladek wrote: > > [...] > > OK, do we have any specific reason why panic_print_sys_info() > > should get called right before kmsg_dump() when this code patch > > is used? > > > > Alternative solution would be to