Re: [PATCH] ppc64/kdump: Limit kdump base to 512MB

2022-09-11 Thread Hari Bathini
On 12/09/22 10:54 am, Christophe Leroy wrote: Le 09/09/2022 à 19:40, Hari Bathini a écrit : Since commit e641eb03ab2b0 ("powerpc: Fix up the kdump base cap to 128M") memory for kdump kernel has been reserved at an offset of 128MB. This held up well for a long time before running into boot f

[PATCH v2] ppc64/kdump: Limit kdump base to 512MB

2022-09-11 Thread Hari Bathini
Since commit e641eb03ab2b0 ("powerpc: Fix up the kdump base cap to 128M") memory for kdump kernel has been reserved at an offset of 128MB. This held up well for a long time before running into boot failure on LPARs having a lot of cores. Commit 7c5ed82b800d8 ("powerpc: Set crashkernel offset to mid

Re: [PATCH 3/3] powerpc: mm: support page table check

2022-09-11 Thread Christophe Leroy
Le 12/09/2022 à 03:47, Rohan McLure a écrit : > On creation and clearing of a page table mapping, instrument such calls > by invoking page_table_check_pte_set and page_table_check_pte_clear > respectively. These calls serve as a sanity check against illegal > mappings. > > Enable ARCH_SUPPORTS_P

Re: [PATCH 2/3] powerpc: mm: add p{te,md,ud}_user_accessible_page helpers

2022-09-11 Thread Christophe Leroy
Le 12/09/2022 à 03:47, Rohan McLure a écrit : > Add the following helpers for detecting whether a page table entry > is a leaf and is accessible to user space. > > * pte_user_accessible_page > * pmd_user_accessible_page > * pud_user_accessible_page > > The heavy lifting is done by pte_use

Re: [PATCH 1/3] powerpc: mm: move pud_pfn stub to common pgtable header

2022-09-11 Thread Christophe Leroy
Le 12/09/2022 à 03:47, Rohan McLure a écrit : > The pud_pfn inline call is only referenced on 64-bit Book3S systems, > but its invocations are gated by pud_devmap() invocations, rendering the > body of this function as dead code. > > As such, this function is readily exportable to all platforms

Re: [PATCH] ppc64/kdump: Limit kdump base to 512MB

2022-09-11 Thread Christophe Leroy
Le 09/09/2022 à 19:40, Hari Bathini a écrit : > Since commit e641eb03ab2b0 ("powerpc: Fix up the kdump base cap to > 128M") memory for kdump kernel has been reserved at an offset of > 128MB. This held up well for a long time before running into boot > failure on LPARs having a lot of cores. Commi

Re: [PATCH 1/3] powerpc: mm: move pud_pfn stub to common pgtable header

2022-09-11 Thread Rohan McLure
This patch and its successor would be avoidable if architectures could specify that they wish to use page_table_check_p{ud,md}_{clear,set}. > On 12 Sep 2022, at 11:47 am, Rohan McLure wrote: > > The pud_pfn inline call is only referenced on 64-bit Book3S systems, > but its invocations are gated

[PATCH 3/3] powerpc: mm: support page table check

2022-09-11 Thread Rohan McLure
On creation and clearing of a page table mapping, instrument such calls by invoking page_table_check_pte_set and page_table_check_pte_clear respectively. These calls serve as a sanity check against illegal mappings. Enable ARCH_SUPPORTS_PAGE_TABLE_CHECK for all ppc64, and 32-bit platforms implemen

[PATCH 2/3] powerpc: mm: add p{te,md,ud}_user_accessible_page helpers

2022-09-11 Thread Rohan McLure
Add the following helpers for detecting whether a page table entry is a leaf and is accessible to user space. * pte_user_accessible_page * pmd_user_accessible_page * pud_user_accessible_page The heavy lifting is done by pte_user, which checks user accessibility on a per-mmu level, provided pri

[PATCH 1/3] powerpc: mm: move pud_pfn stub to common pgtable header

2022-09-11 Thread Rohan McLure
The pud_pfn inline call is only referenced on 64-bit Book3S systems, but its invocations are gated by pud_devmap() invocations, rendering the body of this function as dead code. As such, this function is readily exportable to all platforms in the instance where kernel features depend on it at leas

Re: [PATCH v4 00/20] powerpc: Syscall wrapper and register clearing

2022-09-11 Thread Rohan McLure
Any comments for this revision? Hopefully these revisions address 32-bit and embedded systems appropriately. Thanks, Rohan > On 24 Aug 2022, at 12:05 pm, Rohan McLure wrote: > > V3 available here: > > Link: > https://lore.kernel.org/all/4c3a8815-67ff-41eb-a703-981920ca1...@linux.ibm.com/T/ >

Re: [External] Re: [PATCH 1/3] PCI/AER: Use pci_aer_clear_uncorrect_error_status() to clear uncorrectable error status

2022-09-11 Thread Serge Semin
On Mon, Sep 12, 2022 at 01:09:05AM +0800, Zhuo Chen wrote: > > > On 9/12/22 12:22 AM, Serge Semin wrote: > > Hi Zhuo > > > > On Fri, Sep 02, 2022 at 02:16:32AM +0800, Zhuo Chen wrote: > > > Status bits for ERR_NONFATAL errors only are cleared in > > > pci_aer_clear_nonfatal_status(), but we want

Re: [External] Re: [PATCH 1/3] PCI/AER: Use pci_aer_clear_uncorrect_error_status() to clear uncorrectable error status

2022-09-11 Thread Zhuo Chen
On 9/12/22 12:22 AM, Serge Semin wrote: Hi Zhuo On Fri, Sep 02, 2022 at 02:16:32AM +0800, Zhuo Chen wrote: Status bits for ERR_NONFATAL errors only are cleared in pci_aer_clear_nonfatal_status(), but we want clear uncorrectable error status in ntb_hw_idt.c and lpfc_attr.c. So we add pci_aer_

Re: [PATCH 1/3] PCI/AER: Use pci_aer_clear_uncorrect_error_status() to clear uncorrectable error status

2022-09-11 Thread Serge Semin
Hi Zhuo On Fri, Sep 02, 2022 at 02:16:32AM +0800, Zhuo Chen wrote: > Status bits for ERR_NONFATAL errors only are cleared in > pci_aer_clear_nonfatal_status(), but we want clear uncorrectable > error status in ntb_hw_idt.c and lpfc_attr.c. So we add > pci_aer_clear_uncorrect_error_status() and cha

Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn}

2022-09-11 Thread Ard Biesheuvel
On Sun, 11 Sept 2022 at 16:26, Peter Zijlstra wrote: > > On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote: > > Alternatives > > > > > > Another idea which has been floated in the past is for objtool to read > > DWARF (or .eh_frame) to help it figure out the control flow.

Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn}

2022-09-11 Thread Peter Zijlstra
On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote: > Alternatives > > > Another idea which has been floated in the past is for objtool to read > DWARF (or .eh_frame) to help it figure out the control flow. That > hasn't been tried yet, but would be considerably more diff

Re: [PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency

2022-09-11 Thread Damien Le Moal
On 2022/09/11 21:41, Arnd Bergmann wrote: > On Sun, Sep 11, 2022, at 1:54 PM, Damien Le Moal wrote: >> On 2022/09/09 20:31, Arnd Bergmann wrote: >>> >>> config PATA_PLATFORM >>> - tristate "Generic platform device PATA support" >>> - depends on EXPERT || PPC || HAVE_PATA_PLATFORM >>> + tri

Re: [PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency

2022-09-11 Thread Arnd Bergmann
On Sun, Sep 11, 2022, at 1:54 PM, Damien Le Moal wrote: > On 2022/09/09 20:31, Arnd Bergmann wrote: >> >> config PATA_PLATFORM >> -tristate "Generic platform device PATA support" >> -depends on EXPERT || PPC || HAVE_PATA_PLATFORM >> +tristate "Generic platform device PATA support" if

Re: [PATCH v2] powerpc: select HAVE_PATA_PLATFORM in PPC instead of creating a PPC dependency

2022-09-11 Thread Damien Le Moal
On 2022/09/09 20:31, Arnd Bergmann wrote: > On Fri, Sep 9, 2022, at 1:19 PM, Christophe Leroy wrote: >> Le 09/09/2022 à 13:09, Arnd Bergmann a écrit : >>> On Fri, Sep 9, 2022, at 11:03 AM, Lukas Bulwahn wrote: >>> >>> I don't see a single powerpc machine that creates a >>> name="pata_platform" pl

Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal

2022-09-11 Thread Vlastimil Babka
On 9/2/22 01:26, Suren Baghdasaryan wrote: > On Thu, Sep 1, 2022 at 1:58 PM Kent Overstreet > wrote: >> >> On Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote: >> > Resending to fix the issue with the In-Reply-To tag in the original >> > submission at [4]. >> > >> > This is a proof