x86 removed -pipe in commit 437e88ab8f9e2 ("x86/build: Remove -pipe from
KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it,
so that seems to be the way the world's going.
Compile performance building defconfig on a POWER10 PowerNV system
was in the noise after 10 builds each
Tidy pass over boot Makefile. Move variables together where possible.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/Makefile | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 9cdc
BOOTCFLAGS no longer contains anything that BOOTASFLAGS needs (except
-pipe). Separate them to avoid fragility with cross-contamination of
flags which has caused several build problems.
Suggested-by: Linus Torvalds
Link:
https://lore.kernel.org/lkml/CAHk-=whywudjdeobn1hrwyskqkvzyiq5rbsw5rjjexgnb
Add BOOTCPPFLAGS variable for the CPP options required by C and AS.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/Makefile | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ae80f7f1774e..9445ec4
Add BOOTTARGETFLAGS variable with target / ABI options common to
CFLAGS and AFLAGS.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/Makefile | 41 --
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc
This is a rebase of the series here. It's no longer a fix because
the clang build issue got a minimal fix. A couple were merged, and
I pulled the rest of the boot specific ones into this series.
https://lore.kernel.org/linuxppc-dev/20230426055848.402993-1-npig...@gmail.com/
Thanks,
Nick
Nicholas
On Fri, 2 Jun 2023, Jann Horn wrote:
> On Fri, Jun 2, 2023 at 6:37 AM Hugh Dickins wrote:
>
> > The most obvious vital thing (in the split ptlock case) is that it
> > remains a struct page with a usable ptl spinlock embedded in it.
> >
> > The question becomes more urgent when/if extending to rep
On Wed, 31 May 2023, Jann Horn wrote:
> On Mon, May 29, 2023 at 8:25 AM Hugh Dickins wrote:
> > +static void retract_page_tables(struct address_space *mapping, pgoff_t
> > pgoff)
...
> > +* Note that vma->anon_vma check is racy: it can be set
> > after
> > +* the
On Sun, 28 May 2023, Hugh Dickins wrote:
> Add s390-specific pte_free_defer(), to call pte_free() via call_rcu().
> pte_free_defer() will be called inside khugepaged's retract_page_tables()
> loop, where allocating extra memory cannot be relied upon. This precedes
> the generic version to avoid b
This is not used by radix anymore.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 10 --
arch/powerpc/mm/init_64.c| 21 ++---
2 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pg
With 2M PMD-level mapping, we require 32 struct pages and a single vmemmap page
can contain 1024 struct pages (PAGE_SIZE/sizeof(struct page)). Hence with 64K
page size, we don't use vmemmap deduplication for PMD-level mapping.
Signed-off-by: Aneesh Kumar K.V
---
Documentation/mm/vmemmap_dedup.rs
This is in preparation to update radix to implement vmemmap optimization for
devdax. Below are the rules w.r.t radix vmemmap mapping
1. First try to map things using PMD (2M)
2. With altmap if altmap cross-boundary check returns true, fall back to
PAGE_SIZE
3. IF we can't allocate PMD_SIZE backin
This is enabled only with radix translation and 1G hugepage size. This will be
used with devdax device memory with a namespace alignment of 1G.
Anon transparent hugepage is not supported even though we do have helpers
checking pud_trans_huge(). We should never find that return true. The only
expec
Arm disabled hugetlb vmemmap optimization [1] because hugetlb vmemmap
optimization includes an update of both the permissions (writeable to read-only)
and the output address (pfn) of the vmemmap ptes. That is not supported without
unmapping of pte(marking it invalid) by some architectures.
With DA
pudp_set_wrprotect and move_huge_pud helpers are only used when
CONFIG_TRANSPARENT_HUGEPAGE is enabled. Similar to pmdp_set_wrprotect and
move_huge_pmd_helpers use architecture override only if
CONFIG_TRANSPARENT_HUGEPAGE is set
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 2 ++
This helps architectures to override pmd_same and pud_same
independently.
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 2fe19720075e..8c5174d1f9db 100644
--- a/include/linu
Architectures like powerpc will like to use different page table allocators and
mapping mechanisms to implement vmemmap optimization. Similar to
vmemmap_populate allow architectures to implement vmemap_populate_compound_pages
Signed-off-by: Aneesh Kumar K.V
---
mm/sparse-vmemmap.c | 3 +++
1 fil
dax vmemmap optimization requires a minimum of 2 PAGE_SIZE area within vmemmap
such that tail page mapping can point to the second PAGE_SIZE area. Enforce that
in vmemmap_can_optimize() function.
Architectures like powerpc also want to enable vmemmap optimization
conditionally (only with radix MMU
We will use this in a later patch to do tlb flush when clearing pud entries on
powerpc. This is similar to
commit 93a98695f2f9 ("mm: change pmdp_huge_get_and_clear_full take
vm_area_struct as arg")
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 4 ++--
mm/debug_vm_pgtable.c | 2
Architectures like powerpc would like to enable transparent huge page pud
support only with radix translation. To support that add
has_transparent_pud_hugepage() helper that architectures can override.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/pfn_devs.c | 2 +-
include/linux/pgtable.h
Without this fix, the last subsection vmemmap can end up in memory even if the
namespace is created with -M mem and has sufficient space in the altmap area.
Fixes: cf387d9644d8 ("libnvdimm/altmap: Track namespace boundaries in altmap")
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/init_64.
No functional change in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 15a099e53cde..76f6a1f3
On memory unplug reduce DirectMap page count correctly.
root@ubuntu-guest:# grep Direct /proc/meminfo
DirectMap4k: 0 kB
DirectMap64k: 0 kB
DirectMap2M:115343360 kB
DirectMap1G: 0 kB
Before fix:
root@ubuntu-guest:# ndctl disable-namespace all
disabled 1 namespace
r
This should not be within CONFIG_PPC_64S_HASHS_MMU. We use mmu_vmemmap_psize
on radix while mapping the vmemmap area.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch
No functional change in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 2297aa764ecd..5f8c6fbe8a
This patch series implements changes required to support DAX vmemmap
optimization for ppc64. The vmemmap optimization is only enabled with radix MMU
translation and 1GB PUD mapping with 64K page size. The patch series also split
hugetlb vmemmap optimization as a separate Kconfig variable so that
ar
On Wed, May 17, 2023 at 11:11 PM Grant Grundler
wrote:
> On Fri, Apr 7, 2023 at 12:46 PM Bjorn Helgaas wrote:
> ...
> > But I don't think we need output in a single step; we just need a
> > single instance of ratelimit_state (or one for CPER path and another
> > for native AER path), and that ca
From: Rajat Khandelwal
There are many instances where correctable errors tend to inundate
the message buffer. We observe such instances during thunderbolt PCIe
tunneling.
It's true that they are mitigated by the hardware and are non-fatal
but we shouldn't be spamming the logs with such correctab
Since correctable errors have been corrected (and counted), the dmesg output
should not be reported as a warning, but rather as "informational".
Otherwise, using a certain well known vendor's PCIe parts in a USB4 docking
station, the dmesg buffer can be spammed with correctable errors, 717 bytes
p
From: Rajat Khandelwal
There are many instances where correctable errors tend to inundate
the message buffer. We observe such instances during thunderbolt PCIe
tunneling.
It's true that they are mitigated by the hardware and are non-fatal
but we shouldn't be spamming the logs with such correctab
Since correctable errors have been corrected (and counted), the dmesg output
should not be reported as a warning, but rather as "informational".
Otherwise, using a certain well known vendor's PCIe parts in a USB4 docking
station, the dmesg buffer can be spammed with correctable errors, 717 bytes
p
On Sun, 28 May 2023, Hugh Dickins wrote:
> Add sparc-specific pte_free_defer(), to call pte_free() via call_rcu().
> pte_free_defer() will be called inside khugepaged's retract_page_tables()
> loop, where allocating extra memory cannot be relied upon. This precedes
> the generic version to avoid
[plain text only this time...]
On Wed, May 17, 2023 at 11:11 PM Grant Grundler wrote:
>
> On Fri, Apr 7, 2023 at 12:46 PM Bjorn Helgaas wrote:
> ...
> > But I don't think we need output in a single step; we just need a
> > single instance of ratelimit_state (or one for CPER path and another
> >
On Fri, 2 Jun 2023, Jason Gunthorpe wrote:
> On Mon, May 29, 2023 at 03:02:02PM +0100, Matthew Wilcox wrote:
> > On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote:
> > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > > +{
> > > + struct page *page;
> > > +
> > > + page
On Thu, Jun 01, 2023 at 03:54:50PM +0200, Wolfram Sang wrote:
>
> > I wonder how this series will go in. My expectation was that Wolfram
> > picks up the whole series via his tree?!
>
> Will do. I am currently super-busy, though.
Whole series applied to for-next. I squashed all the commits into
On 6/1/23 4:37 PM, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> This patchset has gone through numerous rounds of review and
> all comments/suggetions have been addressed. I believe that
> this patchset is ready for inclusion.
>
> TCG SED Opal is a specification from The Trusted Compu
On Mon, Jun 05, 2023 at 12:20:40PM +0300, Mike Rapoport wrote:
> On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote:
> > On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote:
> > > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote:
> > > > For a while I have wanted t
> On Jun 5, 2023, at 9:10 AM, Edgecombe, Rick P
> wrote:
>
> On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote:
>> On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
>>> On Thu, 1 Jun 2023 16:54:36 -0700
>>> Nadav Amit wrote:
>>>
> The way text_poke() is used here, it
On Mon, 2023-06-05 at 23:42 +0300, Mike Rapoport wrote:
> > I tried this technique previously [0], and I thought it was not too
> > bad. In most of the callers it looks similar to what you have in
> > do_text_poke(). Sometimes less, sometimes more. It might need
> > enlightening of some of the stuf
On Mon, Jun 05, 2023 at 04:10:21PM +, Edgecombe, Rick P wrote:
> On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote:
> > On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
> > > On Thu, 1 Jun 2023 16:54:36 -0700
> > > Nadav Amit wrote:
> > >
> > > > > The way text_poke() is u
and PowerNV
A build failure with CONFIG_HAVE_PCI=y set without PSERIES or POWERNV
set was caught by the random configuration checker. Guard the sPAPR
specific IOMMU functions on CONFIG_PPC_PSERIES || CONFIG_PPC_POWERNV.
Signed-off-by: Timothy Pearson
---
arch/powerpc/kernel/iommu.c | 4
On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote:
> On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
> > On Thu, 1 Jun 2023 16:54:36 -0700
> > Nadav Amit wrote:
> >
> > > > The way text_poke() is used here, it is creating a new writable
> > > > alias
> > > > and flushing it f
On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> Hello Ilpo,
>
> On Mon, Jun 05, 2023 at 04:44:08PM +0300, Ilpo Järvinen wrote:
> > On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> > > On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote:
> > > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> >
Hello Ilpo,
On Mon, Jun 05, 2023 at 04:44:08PM +0300, Ilpo Järvinen wrote:
> On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> > On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote:
> > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> > >
> > > > The need to handle the FSL variant of 8250 in
On Wed, May 31, 2023 at 04:30:28PM -0500, Bjorn Helgaas wrote:
> On Wed, May 31, 2023 at 08:48:35PM +0200, Jonas Gorski wrote:
...
> > Looking at the code I understand where coverity is coming from:
> >
> > #define __pci_dev_for_each_res0(dev, res, ...) \
> >for (
On Mon, Jun 05, 2023 at 04:44:08PM +0300, Ilpo Järvinen wrote:
> On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> > On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote:
> > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> > > > The need to handle the FSL variant of 8250 in a special way is al
On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote:
> > On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> >
> > > The need to handle the FSL variant of 8250 in a special way is also
> > > present without console support. So soften the dependenc
On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote:
> On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
>
> > The need to handle the FSL variant of 8250 in a special way is also
> > present without console support. So soften the dependency for
> > SERIAL_8250_FSL accordingly. Note that with t
On Mon, 5 Jun 2023, Uwe Kleine-König wrote:
> The need to handle the FSL variant of 8250 in a special way is also
> present without console support. So soften the dependency for
> SERIAL_8250_FSL accordingly. Note that with the 8250 driver compiled as
> a module, some devices still might not make
The need to handle the FSL variant of 8250 in a special way is also
present without console support. So soften the dependency for
SERIAL_8250_FSL accordingly. Note that with the 8250 driver compiled as
a module, some devices still might not make use of the needed
workarounds. That affects the ports
Hello,
this is v3 of the series that now also copes for
arch/powerpc/kernel/legacy_serial.c using fsl8250_handle_irq().
For kernel configurations that already before were correctly using the
Freescale workarounds, this is the case with this series applied, too.
So in all cases the situation doesn
If the 8250 driver is built as a module (or built-in without console
support) the Freescale specific workaround were silently not activated.
Add a warning in this case.
Currently CONFIG_SERIAL_8250_FSL=y implies that the function
fsl8250_handle_irq() is built-in and can be used. However with the
c
It is possible to disable KUAP at boottime with 'nosmap' parameter.
That is implemented with jump_label hence adds a 'nop' in front
of each open/close of userspace access.
>From a security point of view it makes sence to disallow disabling
KUAP. And on processors like the 8xx where 'nop' is not s
All but book3s/64 use a static branch key for disabling kuap.
book3s/64 uses a memory feature.
Refactor all targets except book3s/64.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/kup.h | 7 ---
arch/powerpc/include/asm/book3s/64/kup.h | 1 +
arch/powerpc/
Disassembly of interrupt_enter_prepare() shows a pointless nop before the mftb
c000abf0 :
c000abf0: 81 23 00 84 lwz r9,132(r3)
c000abf4: 71 29 40 00 andi. r9,r9,16384
c000abf8: 41 82 00 28 beq-c000ac20
c000abfc: ===> 60 00 00 00 nop <
A disassembly of interrupt_exit_kernel_prepare() shows a useless read
of MD_AP register. This is shown by r9 being re-used immediately without
doing anything with the value read.
c000e0e0: 60 00 00 00 nop
c000e0e4: ===> 7d 3a c2 a6 mfmd_ap r9<
c000e0e8: 7d 20 00
On Mon, Jun 05, 2023 at 12:20:40PM +0300, Mike Rapoport wrote:
> On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote:
> > On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote:
> > > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote:
> > > > For a while I have wanted t
On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote:
> On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote:
> > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote:
> > > For a while I have wanted to give kprobes its own allocator so that it
> > > can work
> > > even
A disassembly of interrupt_exit_kernel_prepare() shows a useless read
of MSR register. This is shown by r9 being re-used immediately without
doing anything with the value read.
c000e0e0: 60 00 00 00 nop
c000e0e4: 7d 3a c2 a6 mfmd_ap r9
c000e0e8: 7d 20 00 a6 mfms
Looking at generated code for handle_signal32() shows calls to a
function called __unsafe_save_user_regs.constprop.0 while user access
is open.
And that __unsafe_save_user_regs.constprop.0 function has two nops at
the begining, allowing it to be traced, which is unexpected during
user access open
On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
> On Thu, 1 Jun 2023 16:54:36 -0700
> Nadav Amit wrote:
>
> > > The way text_poke() is used here, it is creating a new writable alias
> > > and flushing it for *each* write to the module (like for each write of
> > > an individual re
On 2023-05-16 15:36, Vincent Guittot wrote:
On Mon, 15 May 2023 at 13:46, Tobias Huschle
wrote:
The current load balancer implementation implies that scheduler
groups,
within the same domain, all host the same number of CPUs. This is
reflected in the condition, that a scheduler group, which
On Thu, 25 May 2023 22:36:40 +0200,
Uwe Kleine-König wrote:
>
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> back to (the new)
63 matches
Mail list logo
