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
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
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
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
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
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.
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
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_
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
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/
>
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
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo
