Re: [PATCH 3/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when unmapping
On 5/2/2022 10:02 PM, Gerald Schaefer wrote:
On Sat, 30 Apr 2022 11:22:33 +0800
Baolin Wang wrote:
On 4/30/2022 4:02 AM, Gerald Schaefer wrote:
On Fri, 29 Apr 2022 16:14:43 +0800
Baolin Wang wrote:
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
When unmapping a hugetlb page, we will get the relevant page table
entry by huge_pte_offset() only once to nuke it. This is correct
for PMD or PUD size hugetlb, since they always contain only one
pmd entry or pud entry in the page table.
However this is incorrect for CONT-PTE and CONT-PMD size hugetlb,
since they can contain several continuous pte or pmd entry with
same page table attributes, so we will nuke only one pte or pmd
entry for this CONT-PTE/PMD size hugetlb page.
And now we only use try_to_unmap() to unmap a poisoned hugetlb page,
which means now we will unmap only one pte entry for a CONT-PTE or
CONT-PMD size poisoned hugetlb page, and we can still access other
subpages of a CONT-PTE or CONT-PMD size poisoned hugetlb page,
which will cause serious issues possibly.
So we should change to use huge_ptep_clear_flush() to nuke the
hugetlb page table to fix this issue, which already considered
CONT-PTE and CONT-PMD size hugetlb.
Note we've already used set_huge_swap_pte_at() to set a poisoned
swap entry for a poisoned hugetlb page.
Signed-off-by: Baolin Wang
---
mm/rmap.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 7cf2408..1e168d7 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1564,28 +1564,28 @@ static bool try_to_unmap_one(struct folio *folio,
struct vm_area_struct *vma,
break;
}
}
+ pteval = huge_ptep_clear_flush(vma, address, pvmw.pte);
Unlike in your patch 2/3, I do not see that this (huge) pteval would later
be used again with set_huge_pte_at() instead of set_pte_at(). Not sure if
this (huge) pteval could end up at a set_pte_at() later, but if yes, then
this would be broken on s390, and you'd need to use set_huge_pte_at()
instead of set_pte_at() like in your patch 2/3.
IIUC, As I said in the commit message, we will only unmap a poisoned
hugetlb page by try_to_unmap(), and the poisoned hugetlb page will be
remapped with a poisoned entry by set_huge_swap_pte_at() in
try_to_unmap_one(). So I think no need change to use set_huge_pte_at()
instead of set_pte_at() for other cases, since the hugetlb page will not
hit other cases.
if (PageHWPoison(subpage) && !(flags & TTU_IGNORE_HWPOISON)) {
pteval = swp_entry_to_pte(make_hwpoison_entry(subpage));
if (folio_test_hugetlb(folio)) {
hugetlb_count_sub(folio_nr_pages(folio), mm);
set_huge_swap_pte_at(mm, address, pvmw.pte, pteval,
vma_mmu_pagesize(vma));
} else {
dec_mm_counter(mm, mm_counter(&folio->page));
set_pte_at(mm, address, pvmw.pte, pteval);
}
}
OK, but wouldn't the pteval be overwritten here with
pteval = swp_entry_to_pte(make_hwpoison_entry(subpage))?
IOW, what sense does it make to save the returned pteval from
huge_ptep_clear_flush(), when it is never being used anywhere?
Please see previous code, we'll use the original pte value to check if
it is uffd-wp armed, and if need to mark it dirty though the hugetlbfs
is set noop_dirty_folio().
pte_install_uffd_wp_if_needed(vma, address, pvmw.pte, pteval);
/* Set the dirty flag on the folio now the pte is gone. */
if (pte_dirty(pteval))
folio_mark_dirty(folio);
Re: [PATCH] kbuild: drop $(objtree)/ prefix support for clean-files
On Sun, May 1, 2022 at 8:57 PM Michael Ellerman wrote: > > Masahiro Yamada writes: > > I think this hack is a bad idea. arch/powerpc/boot/Makefile is the > > only user. Let's stop doing this. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > arch/powerpc/boot/Makefile | 4 ++-- > > Acked-by: Michael Ellerman (powerpc) > > cheers > Applied to linux-kbuild. > > scripts/Makefile.clean | 8 +--- > > 2 files changed, 3 insertions(+), 9 deletions(-) > > > > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile > > index 4b4827c475c6..008bf0bff186 100644 > > --- a/arch/powerpc/boot/Makefile > > +++ b/arch/powerpc/boot/Makefile > > @@ -453,8 +453,8 @@ clean-files += $(image-) $(initrd-) cuImage.* > > dtbImage.* treeImage.* \ > > clean-kernel-base := vmlinux.strip vmlinux.bin > > clean-kernel := $(addsuffix .gz,$(clean-kernel-base)) > > clean-kernel += $(addsuffix .xz,$(clean-kernel-base)) > > -# If not absolute clean-files are relative to $(obj). > > -clean-files += $(addprefix $(objtree)/, $(clean-kernel)) > > +# clean-files are relative to $(obj). > > +clean-files += $(addprefix ../../../, $(clean-kernel)) > > > > WRAPPER_OBJDIR := /usr/lib/kernel-wrapper > > WRAPPER_DTSDIR := /usr/lib/kernel-wrapper/dts > > diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean > > index 74cb1c5c3658..878cec648959 100644 > > --- a/scripts/Makefile.clean > > +++ b/scripts/Makefile.clean > > @@ -36,13 +36,7 @@ __clean-files := \ > > > > __clean-files := $(filter-out $(no-clean-files), $(__clean-files)) > > > > -# clean-files is given relative to the current directory, unless it > > -# starts with $(objtree)/ (which means "./", so do not add "./" unless > > -# you want to delete a file from the toplevel object directory). > > - > > -__clean-files := $(wildcard > > \ > > -$(addprefix $(obj)/, $(filter-out $(objtree)/%, > > $(__clean-files))) \ > > -$(filter $(objtree)/%, $(__clean-files))) > > +__clean-files := $(wildcard $(addprefix $(obj)/, $(__clean-files))) > > > > # > > == > > > > -- > > 2.32.0 -- Best Regards Masahiro Yamada
Re: [PATCH] POWERPC: idle: fix return value of __setup handler
Randy Dunlap writes:
> On 5/2/22 06:19, Michael Ellerman wrote:
>> Randy Dunlap writes:
>>> __setup() handlers should return 1 to obsolete_checksetup() in
>>> init/main.c to indicate that the boot option has been handled.
>>> A return of 0 causes the boot option/value to be listed as an Unknown
>>> kernel parameter and added to init's (limited) argument or environment
>>> strings. Also, error return codes don't mean anything to
>>> obsolete_checksetup() -- only non-zero (usually 1) or zero.
>>> So return 1 from powersave_off().
>>>
>>> Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of
>>> cbe_idle_loop")
>>> Signed-off-by: Randy Dunlap
>>> From: Igor Zhbanov
>>
>> What happened here? Is the patch actually from Igor? If so he should be
>> the author, and it should include his SoB shouldn't it?
>
> I don't know what happened. I did the patches.
> I'll resend them.
Thanks.
cheers
[PATCH for v5.10] perf symbol: Remove arch__symbols__fixup_end()
Now the generic code can handle kallsyms fixup properly so no need to
keep the arch-functions anymore.
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-4-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
The original commit id is a5d20d42a2f2dc2b2f9e9361912062732414090d
tools/perf/arch/arm64/util/Build | 1 -
tools/perf/arch/arm64/util/machine.c | 27 ---
tools/perf/arch/s390/util/machine.c | 16
tools/perf/util/symbol.c | 5 -
tools/perf/util/symbol.h | 1 -
5 files changed, 50 deletions(-)
delete mode 100644 tools/perf/arch/arm64/util/machine.c
diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index b53294d74b01..eddaf9bf5729 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -1,5 +1,4 @@
perf-y += header.o
-perf-y += machine.o
perf-y += perf_regs.o
perf-y += tsc.o
perf-$(CONFIG_DWARF) += dwarf-regs.o
diff --git a/tools/perf/arch/arm64/util/machine.c
b/tools/perf/arch/arm64/util/machine.c
deleted file mode 100644
index d41b27e781d3..
--- a/tools/perf/arch/arm64/util/machine.c
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-#include
-#include
-#include "debug.h"
-#include "symbol.h"
-
-/* On arm64, kernel text segment start at high memory address,
- * for example 0x 8xxx . Modules start at a low memory
- * address, like 0x 00ax . When only samll amount of
- * memory is used by modules, gap between end of module's text segment
- * and start of kernel text segment may be reach 2G.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-
-#define SYMBOL_LIMIT (1 << 12) /* 4K */
-
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if ((strchr(p->name, '[') && strchr(c->name, '[') == NULL) ||
- (strchr(p->name, '[') == NULL && strchr(c->name, '[')))
- /* Limit range of last symbol in module and kernel */
- p->end += SYMBOL_LIMIT;
- else
- p->end = c->start;
- pr_debug4("%s sym:%s end:%#lx\n", __func__, p->name, p->end);
-}
diff --git a/tools/perf/arch/s390/util/machine.c
b/tools/perf/arch/s390/util/machine.c
index 724efb2d842d..7219ecdb8423 100644
--- a/tools/perf/arch/s390/util/machine.c
+++ b/tools/perf/arch/s390/util/machine.c
@@ -34,19 +34,3 @@ int arch__fix_module_text_start(u64 *start, u64 *size, const
char *name)
return 0;
}
-
-/* On s390 kernel text segment start is located at very low memory addresses,
- * for example 0x1. Modules are located at very high memory addresses,
- * for example 0x3ff . The gap between end of kernel text segment
- * and beginning of first module's text segment is very big.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if (strchr(p->name, '[') == NULL && strchr(c->name, '['))
- /* Last kernel symbol mapped to end of page */
- p->end = roundup(p->end, page_size);
- else
- p->end = c->start;
- pr_debug4("%s sym:%s end:%#lx\n", __func__, p->name, p->end);
-}
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 8f63cf8d0669..33954835c823 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -101,11 +101,6 @@ static int prefix_underscores_count(const char *str)
return tail - str;
}
-void __weak arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- p->end = c->start;
-}
-
const char * __weak arch__normalize_symbol_name(const char *name)
{
return name;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 66d5b732bb7a..28721d761d91 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -230,7 +230,6 @@ const char *arch__normalize_symbol_name(const char *name);
#define SYMBOL_A 0
#define SYMBOL_B 1
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c);
int arch__compare_symbol_names(const char *namea, const char *nameb);
int arch__compare_symbol_names_n(const char *namea, const char *nameb,
unsigned int n);
--
2.36.0.464.gb9c8b46e94-goog
[PATCH for v5.15] perf symbol: Remove arch__symbols__fixup_end()
Now the generic code can handle kallsyms fixup properly so no need to
keep the arch-functions anymore.
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-4-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
The original commit id is a5d20d42a2f2dc2b2f9e9361912062732414090d
tools/perf/arch/arm64/util/Build | 1 -
tools/perf/arch/arm64/util/machine.c | 28 --
tools/perf/arch/powerpc/util/Build | 1 -
tools/perf/arch/powerpc/util/machine.c | 25 ---
tools/perf/arch/s390/util/machine.c| 16 ---
tools/perf/util/symbol.c | 5 -
tools/perf/util/symbol.h | 1 -
7 files changed, 77 deletions(-)
delete mode 100644 tools/perf/arch/arm64/util/machine.c
delete mode 100644 tools/perf/arch/powerpc/util/machine.c
diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index 9fcb4e68add9..78dfc282e5e2 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -1,5 +1,4 @@
perf-y += header.o
-perf-y += machine.o
perf-y += perf_regs.o
perf-y += tsc.o
perf-y += pmu.o
diff --git a/tools/perf/arch/arm64/util/machine.c
b/tools/perf/arch/arm64/util/machine.c
deleted file mode 100644
index 7e7714290a87..
--- a/tools/perf/arch/arm64/util/machine.c
+++ /dev/null
@@ -1,28 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-#include
-#include
-#include
-#include "debug.h"
-#include "symbol.h"
-
-/* On arm64, kernel text segment starts at high memory address,
- * for example 0x 8xxx . Modules start at a low memory
- * address, like 0x 00ax . When only small amount of
- * memory is used by modules, gap between end of module's text segment
- * and start of kernel text segment may reach 2G.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-
-#define SYMBOL_LIMIT (1 << 12) /* 4K */
-
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if ((strchr(p->name, '[') && strchr(c->name, '[') == NULL) ||
- (strchr(p->name, '[') == NULL && strchr(c->name, '[')))
- /* Limit range of last symbol in module and kernel */
- p->end += SYMBOL_LIMIT;
- else
- p->end = c->start;
- pr_debug4("%s sym:%s end:%#" PRIx64 "\n", __func__, p->name, p->end);
-}
diff --git a/tools/perf/arch/powerpc/util/Build
b/tools/perf/arch/powerpc/util/Build
index 8a79c4126e5b..0115f3166568 100644
--- a/tools/perf/arch/powerpc/util/Build
+++ b/tools/perf/arch/powerpc/util/Build
@@ -1,5 +1,4 @@
perf-y += header.o
-perf-y += machine.o
perf-y += kvm-stat.o
perf-y += perf_regs.o
perf-y += mem-events.o
diff --git a/tools/perf/arch/powerpc/util/machine.c
b/tools/perf/arch/powerpc/util/machine.c
deleted file mode 100644
index e652a1aa8132..
--- a/tools/perf/arch/powerpc/util/machine.c
+++ /dev/null
@@ -1,25 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-#include
-#include
-#include
-#include // page_size
-#include "debug.h"
-#include "symbol.h"
-
-/* On powerpc kernel text segment start at memory addresses, 0xc000
- * whereas the modules are located at very high memory addresses,
- * for example 0xc0080xxx. The gap between end of kernel text segment
- * and beginning of first module's text segment is very high.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if (strchr(p->name, '[') == NULL && strchr(c->name, '['))
- /* Limit the range of last kernel symbol */
- p->end += page_size;
- else
- p->end = c->start;
- pr_debug4("%s sym:%s end:%#" PRIx64 "\n", __func__, p->name, p->end);
-}
diff --git a/tools/perf/arch/s390/util/machine.c
b/tools/perf/arch/s390/util/machine.c
index 7644a4f6d4a4..98bc3f39d5f3 100644
--- a/tools/perf/arch/s390/util/machine.c
+++ b/tools/perf/arch/s390/util/machine.c
@@ -35,19 +35,3 @@ int arch__fix_module_text_start(u64 *start, u64 *size, const
char *name)
return 0;
}
-
-/* On s390 kernel text segment start is located at very low memory addresses,
- * for example 0x1. Modules are located at very high memory addresses,
- * for example 0x3ff . The gap between end of kernel text segment
- * and beginning of first module's text segment is very big.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if (strchr(p->name, '['
Re: [PATCH] powerpc/vdso: Fix incorrect CFI in gettimeofday.S
On Mon, May 02, 2022 at 09:27:05AM -0500, Segher Boessenkool wrote: > > 2) If a function changes LR or any non-volatile register, the save > > location for those regs must be given. The cfi can be at any > > instruction after the saves up to the point that the reg is > > changed. (Exception: LR save should be described before a bl.) > > That isn't an exception? bl changes the current LR after all :-) The point is that in other cases the cfi can be as late as the instruction that changes the reg. For calls it must be at least one instruction before the call. Also, I'll note for the wider audience that delaying cfi is slightly better than playing it safe as Michael has done in his patch in describing the saves right at the save instruction. Register save cfi can usually be grouped together, resulting in fewer CFI_advance codes in .eh_frame. > Alan proposed a larger patch that changed to a single stack frame, but it > needs changes to > take into account the red zone. Yes, now that you mention it, I see the obvious error in the patch I wrote. I did say it was untested! -- Alan Modra Australia Development Lab, IBM
Re: [PATCH 2/2] recordmcount: Handle sections with no non-weak symbols
On Mon, 2 May 2022 14:44:56 + Christophe Leroy wrote: > If we do that after the linking, won't it be a nightmare with the > trampolines installed by the linker when the destination is over the 24 > bits limit ? Not sure what you mean. The locations I'm talking about is the full address saved in the __mcount_loc table (data section). -- Steve
Patch "perf symbol: Update symbols__fixup_end()" has been added to the 5.17-stable tree
This is a note to let you know that I've just added the patch titled
perf symbol: Update symbols__fixup_end()
to the 5.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-symbol-update-symbols__fixup_end.patch
and it can be found in the queue-5.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8799ebce84d672aae1dc3170510f6a3e66f96b11 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 15 Apr 2022 17:40:47 -0700
Subject: perf symbol: Update symbols__fixup_end()
From: Namhyung Kim
commit 8799ebce84d672aae1dc3170510f6a3e66f96b11 upstream.
Now arch-specific functions all do the same thing. When it fixes the
symbol address it needs to check the boundary between the kernel image
and modules. For the last symbol in the previous region, it cannot
know the exact size as it's discarded already. Thus it just uses a
small page size (4096) and rounds it up like the last symbol.
Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition")
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-3-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/symbol.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -217,8 +217,8 @@ again:
}
}
-void symbols__fixup_end(struct rb_root_cached *symbols,
- bool is_kallsyms __maybe_unused)
+/* Update zero-sized symbols using the address of the next symbol */
+void symbols__fixup_end(struct rb_root_cached *symbols, bool is_kallsyms)
{
struct rb_node *nd, *prevnd = rb_first_cached(symbols);
struct symbol *curr, *prev;
@@ -232,8 +232,29 @@ void symbols__fixup_end(struct rb_root_c
prev = curr;
curr = rb_entry(nd, struct symbol, rb_node);
- if (prev->end == prev->start || prev->end != curr->start)
- arch__symbols__fixup_end(prev, curr);
+ /*
+* On some architecture kernel text segment start is located at
+* some low memory address, while modules are located at high
+* memory addresses (or vice versa). The gap between end of
+* kernel text segment and beginning of first module's text
+* segment is very big. Therefore do not fill this gap and do
+* not assign it to the kernel dso map (kallsyms).
+*
+* In kallsyms, it determines module symbols using '[' character
+* like in:
+* c1937000 T hdmi_driver_init [snd_hda_codec_hdmi]
+*/
+ if (prev->end == prev->start) {
+ /* Last kernel/module symbol mapped to end of page */
+ if (is_kallsyms && (!strchr(prev->name, '[') !=
+ !strchr(curr->name, '[')))
+ prev->end = roundup(prev->end + 4096, 4096);
+ else
+ prev->end = curr->start;
+
+ pr_debug4("%s sym:%s end:%#" PRIx64 "\n",
+ __func__, prev->name, prev->end);
+ }
}
/* Last entry */
Patches currently in stable-queue which might be from namhy...@kernel.org are
queue-5.17/perf-symbol-remove-arch__symbols__fixup_end.patch
queue-5.17/perf-arm-spe-fix-addresses-of-synthesized-spe-events.patch
queue-5.17/perf-symbol-update-symbols__fixup_end.patch
queue-5.17/perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
Patch "perf symbol: Remove arch__symbols__fixup_end()" has been added to the 5.17-stable tree
This is a note to let you know that I've just added the patch titled
perf symbol: Remove arch__symbols__fixup_end()
to the 5.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-symbol-remove-arch__symbols__fixup_end.patch
and it can be found in the queue-5.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From a5d20d42a2f2dc2b2f9e9361912062732414090d Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 15 Apr 2022 17:40:48 -0700
Subject: perf symbol: Remove arch__symbols__fixup_end()
From: Namhyung Kim
commit a5d20d42a2f2dc2b2f9e9361912062732414090d upstream.
Now the generic code can handle kallsyms fixup properly so no need to
keep the arch-functions anymore.
Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition")
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-4-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/arch/arm64/util/machine.c | 21 -
tools/perf/arch/powerpc/util/Build |1 -
tools/perf/arch/powerpc/util/machine.c | 25 -
tools/perf/arch/s390/util/machine.c| 16
tools/perf/util/symbol.c |5 -
tools/perf/util/symbol.h |1 -
6 files changed, 69 deletions(-)
delete mode 100644 tools/perf/arch/powerpc/util/machine.c
--- a/tools/perf/arch/arm64/util/machine.c
+++ b/tools/perf/arch/arm64/util/machine.c
@@ -8,27 +8,6 @@
#include "callchain.h"
#include "record.h"
-/* On arm64, kernel text segment starts at high memory address,
- * for example 0x 8xxx . Modules start at a low memory
- * address, like 0x 00ax . When only small amount of
- * memory is used by modules, gap between end of module's text segment
- * and start of kernel text segment may reach 2G.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-
-#define SYMBOL_LIMIT (1 << 12) /* 4K */
-
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if ((strchr(p->name, '[') && strchr(c->name, '[') == NULL) ||
- (strchr(p->name, '[') == NULL && strchr(c->name, '[')))
- /* Limit range of last symbol in module and kernel */
- p->end += SYMBOL_LIMIT;
- else
- p->end = c->start;
- pr_debug4("%s sym:%s end:%#" PRIx64 "\n", __func__, p->name, p->end);
-}
-
void arch__add_leaf_frame_record_opts(struct record_opts *opts)
{
opts->sample_user_regs |= sample_reg_masks[PERF_REG_ARM64_LR].mask;
--- a/tools/perf/arch/powerpc/util/Build
+++ b/tools/perf/arch/powerpc/util/Build
@@ -1,5 +1,4 @@
perf-y += header.o
-perf-y += machine.o
perf-y += kvm-stat.o
perf-y += perf_regs.o
perf-y += mem-events.o
--- a/tools/perf/arch/powerpc/util/machine.c
+++ /dev/null
@@ -1,25 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-#include
-#include
-#include
-#include // page_size
-#include "debug.h"
-#include "symbol.h"
-
-/* On powerpc kernel text segment start at memory addresses, 0xc000
- * whereas the modules are located at very high memory addresses,
- * for example 0xc0080xxx. The gap between end of kernel text segment
- * and beginning of first module's text segment is very high.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if (strchr(p->name, '[') == NULL && strchr(c->name, '['))
- /* Limit the range of last kernel symbol */
- p->end += page_size;
- else
- p->end = c->start;
- pr_debug4("%s sym:%s end:%#" PRIx64 "\n", __func__, p->name, p->end);
-}
--- a/tools/perf/arch/s390/util/machine.c
+++ b/tools/perf/arch/s390/util/machine.c
@@ -35,19 +35,3 @@ int arch__fix_module_text_start(u64 *sta
return 0;
}
-
-/* On s390 kernel text segment start is located at very low memory addresses,
- * for example 0x1. Modules are located at very high memory addresses,
- * for example 0x3ff . The gap between end of kernel text segment
- * and beginning of first module's text segment is very big.
- * Therefore do not fill this gap and do not assign it to the kernel dso map.
- */
-void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
-{
- if (strchr(p->name, '[') == NULL && strchr(c->name, '['))
- /* Last kernel symbol map
Patch "perf symbol: Pass is_kallsyms to symbols__fixup_end()" has been added to the 5.17-stable tree
This is a note to let you know that I've just added the patch titled
perf symbol: Pass is_kallsyms to symbols__fixup_end()
to the 5.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
and it can be found in the queue-5.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 838425f2defe5262906b698752d28fd2fca1aac2 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 15 Apr 2022 17:40:46 -0700
Subject: perf symbol: Pass is_kallsyms to symbols__fixup_end()
From: Namhyung Kim
commit 838425f2defe5262906b698752d28fd2fca1aac2 upstream.
The symbol fixup is necessary for symbols in kallsyms since they don't
have size info. So we use the next symbol's address to calculate the
size. Now it's also used for user binaries because sometimes they miss
size for hand-written asm functions.
There's a arch-specific function to handle kallsyms differently but
currently it cannot distinguish kallsyms from others. Pass this
information explicitly to handle it properly. Note that those arch
functions will be moved to the generic function so I didn't added it to
the arch-functions.
Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition")
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-2-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/symbol-elf.c |2 +-
tools/perf/util/symbol.c |7 ---
tools/perf/util/symbol.h |2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1290,7 +1290,7 @@ dso__load_sym_internal(struct dso *dso,
* For misannotated, zeroed, ASM function sizes.
*/
if (nr > 0) {
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, false);
symbols__fixup_duplicate(&dso->symbols);
if (kmap) {
/*
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -217,7 +217,8 @@ again:
}
}
-void symbols__fixup_end(struct rb_root_cached *symbols)
+void symbols__fixup_end(struct rb_root_cached *symbols,
+ bool is_kallsyms __maybe_unused)
{
struct rb_node *nd, *prevnd = rb_first_cached(symbols);
struct symbol *curr, *prev;
@@ -1467,7 +1468,7 @@ int __dso__load_kallsyms(struct dso *dso
if (kallsyms__delta(kmap, filename, &delta))
return -1;
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, true);
symbols__fixup_duplicate(&dso->symbols);
if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
@@ -1659,7 +1660,7 @@ int dso__load_bfd_symbols(struct dso *ds
#undef bfd_asymbol_section
#endif
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, false);
symbols__fixup_duplicate(&dso->symbols);
dso->adjust_symbols = 1;
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -203,7 +203,7 @@ void __symbols__insert(struct rb_root_ca
bool kernel);
void symbols__insert(struct rb_root_cached *symbols, struct symbol *sym);
void symbols__fixup_duplicate(struct rb_root_cached *symbols);
-void symbols__fixup_end(struct rb_root_cached *symbols);
+void symbols__fixup_end(struct rb_root_cached *symbols, bool is_kallsyms);
void maps__fixup_end(struct maps *maps);
typedef int (*mapfn_t)(u64 start, u64 len, u64 pgoff, void *data);
Patches currently in stable-queue which might be from namhy...@kernel.org are
queue-5.17/perf-symbol-remove-arch__symbols__fixup_end.patch
queue-5.17/perf-arm-spe-fix-addresses-of-synthesized-spe-events.patch
queue-5.17/perf-symbol-update-symbols__fixup_end.patch
queue-5.17/perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
Patch "perf symbol: Update symbols__fixup_end()" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
perf symbol: Update symbols__fixup_end()
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-symbol-update-symbols__fixup_end.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8799ebce84d672aae1dc3170510f6a3e66f96b11 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 15 Apr 2022 17:40:47 -0700
Subject: perf symbol: Update symbols__fixup_end()
From: Namhyung Kim
commit 8799ebce84d672aae1dc3170510f6a3e66f96b11 upstream.
Now arch-specific functions all do the same thing. When it fixes the
symbol address it needs to check the boundary between the kernel image
and modules. For the last symbol in the previous region, it cannot
know the exact size as it's discarded already. Thus it just uses a
small page size (4096) and rounds it up like the last symbol.
Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition")
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-3-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/symbol.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -217,8 +217,8 @@ again:
}
}
-void symbols__fixup_end(struct rb_root_cached *symbols,
- bool is_kallsyms __maybe_unused)
+/* Update zero-sized symbols using the address of the next symbol */
+void symbols__fixup_end(struct rb_root_cached *symbols, bool is_kallsyms)
{
struct rb_node *nd, *prevnd = rb_first_cached(symbols);
struct symbol *curr, *prev;
@@ -232,8 +232,29 @@ void symbols__fixup_end(struct rb_root_c
prev = curr;
curr = rb_entry(nd, struct symbol, rb_node);
- if (prev->end == prev->start || prev->end != curr->start)
- arch__symbols__fixup_end(prev, curr);
+ /*
+* On some architecture kernel text segment start is located at
+* some low memory address, while modules are located at high
+* memory addresses (or vice versa). The gap between end of
+* kernel text segment and beginning of first module's text
+* segment is very big. Therefore do not fill this gap and do
+* not assign it to the kernel dso map (kallsyms).
+*
+* In kallsyms, it determines module symbols using '[' character
+* like in:
+* c1937000 T hdmi_driver_init [snd_hda_codec_hdmi]
+*/
+ if (prev->end == prev->start) {
+ /* Last kernel/module symbol mapped to end of page */
+ if (is_kallsyms && (!strchr(prev->name, '[') !=
+ !strchr(curr->name, '[')))
+ prev->end = roundup(prev->end + 4096, 4096);
+ else
+ prev->end = curr->start;
+
+ pr_debug4("%s sym:%s end:%#" PRIx64 "\n",
+ __func__, prev->name, prev->end);
+ }
}
/* Last entry */
Patches currently in stable-queue which might be from namhy...@kernel.org are
queue-5.15/perf-arm-spe-fix-addresses-of-synthesized-spe-events.patch
queue-5.15/perf-symbol-update-symbols__fixup_end.patch
queue-5.15/perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
Patch "perf symbol: Update symbols__fixup_end()" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
perf symbol: Update symbols__fixup_end()
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-symbol-update-symbols__fixup_end.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8799ebce84d672aae1dc3170510f6a3e66f96b11 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 15 Apr 2022 17:40:47 -0700
Subject: perf symbol: Update symbols__fixup_end()
From: Namhyung Kim
commit 8799ebce84d672aae1dc3170510f6a3e66f96b11 upstream.
Now arch-specific functions all do the same thing. When it fixes the
symbol address it needs to check the boundary between the kernel image
and modules. For the last symbol in the previous region, it cannot
know the exact size as it's discarded already. Thus it just uses a
small page size (4096) and rounds it up like the last symbol.
Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition")
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-3-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/symbol.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -217,8 +217,8 @@ again:
}
}
-void symbols__fixup_end(struct rb_root_cached *symbols,
- bool is_kallsyms __maybe_unused)
+/* Update zero-sized symbols using the address of the next symbol */
+void symbols__fixup_end(struct rb_root_cached *symbols, bool is_kallsyms)
{
struct rb_node *nd, *prevnd = rb_first_cached(symbols);
struct symbol *curr, *prev;
@@ -232,8 +232,29 @@ void symbols__fixup_end(struct rb_root_c
prev = curr;
curr = rb_entry(nd, struct symbol, rb_node);
- if (prev->end == prev->start || prev->end != curr->start)
- arch__symbols__fixup_end(prev, curr);
+ /*
+* On some architecture kernel text segment start is located at
+* some low memory address, while modules are located at high
+* memory addresses (or vice versa). The gap between end of
+* kernel text segment and beginning of first module's text
+* segment is very big. Therefore do not fill this gap and do
+* not assign it to the kernel dso map (kallsyms).
+*
+* In kallsyms, it determines module symbols using '[' character
+* like in:
+* c1937000 T hdmi_driver_init [snd_hda_codec_hdmi]
+*/
+ if (prev->end == prev->start) {
+ /* Last kernel/module symbol mapped to end of page */
+ if (is_kallsyms && (!strchr(prev->name, '[') !=
+ !strchr(curr->name, '[')))
+ prev->end = roundup(prev->end + 4096, 4096);
+ else
+ prev->end = curr->start;
+
+ pr_debug4("%s sym:%s end:%#" PRIx64 "\n",
+ __func__, prev->name, prev->end);
+ }
}
/* Last entry */
Patches currently in stable-queue which might be from namhy...@kernel.org are
queue-5.10/perf-symbol-update-symbols__fixup_end.patch
queue-5.10/perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
Patch "perf symbol: Pass is_kallsyms to symbols__fixup_end()" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
perf symbol: Pass is_kallsyms to symbols__fixup_end()
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 838425f2defe5262906b698752d28fd2fca1aac2 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 15 Apr 2022 17:40:46 -0700
Subject: perf symbol: Pass is_kallsyms to symbols__fixup_end()
From: Namhyung Kim
commit 838425f2defe5262906b698752d28fd2fca1aac2 upstream.
The symbol fixup is necessary for symbols in kallsyms since they don't
have size info. So we use the next symbol's address to calculate the
size. Now it's also used for user binaries because sometimes they miss
size for hand-written asm functions.
There's a arch-specific function to handle kallsyms differently but
currently it cannot distinguish kallsyms from others. Pass this
information explicitly to handle it properly. Note that those arch
functions will be moved to the generic function so I didn't added it to
the arch-functions.
Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition")
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-2-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/symbol-elf.c |2 +-
tools/perf/util/symbol.c |7 ---
tools/perf/util/symbol.h |2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1290,7 +1290,7 @@ dso__load_sym_internal(struct dso *dso,
* For misannotated, zeroed, ASM function sizes.
*/
if (nr > 0) {
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, false);
symbols__fixup_duplicate(&dso->symbols);
if (kmap) {
/*
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -217,7 +217,8 @@ again:
}
}
-void symbols__fixup_end(struct rb_root_cached *symbols)
+void symbols__fixup_end(struct rb_root_cached *symbols,
+ bool is_kallsyms __maybe_unused)
{
struct rb_node *nd, *prevnd = rb_first_cached(symbols);
struct symbol *curr, *prev;
@@ -1456,7 +1457,7 @@ int __dso__load_kallsyms(struct dso *dso
if (kallsyms__delta(kmap, filename, &delta))
return -1;
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, true);
symbols__fixup_duplicate(&dso->symbols);
if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
@@ -1648,7 +1649,7 @@ int dso__load_bfd_symbols(struct dso *ds
#undef bfd_asymbol_section
#endif
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, false);
symbols__fixup_duplicate(&dso->symbols);
dso->adjust_symbols = 1;
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -192,7 +192,7 @@ void __symbols__insert(struct rb_root_ca
bool kernel);
void symbols__insert(struct rb_root_cached *symbols, struct symbol *sym);
void symbols__fixup_duplicate(struct rb_root_cached *symbols);
-void symbols__fixup_end(struct rb_root_cached *symbols);
+void symbols__fixup_end(struct rb_root_cached *symbols, bool is_kallsyms);
void maps__fixup_end(struct maps *maps);
typedef int (*mapfn_t)(u64 start, u64 len, u64 pgoff, void *data);
Patches currently in stable-queue which might be from namhy...@kernel.org are
queue-5.15/perf-arm-spe-fix-addresses-of-synthesized-spe-events.patch
queue-5.15/perf-symbol-update-symbols__fixup_end.patch
queue-5.15/perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
Patch "perf symbol: Pass is_kallsyms to symbols__fixup_end()" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
perf symbol: Pass is_kallsyms to symbols__fixup_end()
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 838425f2defe5262906b698752d28fd2fca1aac2 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Fri, 15 Apr 2022 17:40:46 -0700
Subject: perf symbol: Pass is_kallsyms to symbols__fixup_end()
From: Namhyung Kim
commit 838425f2defe5262906b698752d28fd2fca1aac2 upstream.
The symbol fixup is necessary for symbols in kallsyms since they don't
have size info. So we use the next symbol's address to calculate the
size. Now it's also used for user binaries because sometimes they miss
size for hand-written asm functions.
There's a arch-specific function to handle kallsyms differently but
currently it cannot distinguish kallsyms from others. Pass this
information explicitly to handle it properly. Note that those arch
functions will be moved to the generic function so I didn't added it to
the arch-functions.
Fixes: 3cf6a32f3f2a4594 ("perf symbols: Fix symbol size calculation condition")
Signed-off-by: Namhyung Kim
Acked-by: Ian Rogers
Cc: Heiko Carstens
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: John Garry
Cc: Leo Yan
Cc: Mark Rutland
Cc: Masami Hiramatsu
Cc: Mathieu Poirier
Cc: Michael Ellerman
Cc: Michael Petlan
Cc: Peter Zijlstra
Cc: Song Liu
Cc: Will Deacon
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lore.kernel.org/r/20220416004048.1514900-2-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/symbol-elf.c |2 +-
tools/perf/util/symbol.c |7 ---
tools/perf/util/symbol.h |2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1245,7 +1245,7 @@ int dso__load_sym(struct dso *dso, struc
* For misannotated, zeroed, ASM function sizes.
*/
if (nr > 0) {
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, false);
symbols__fixup_duplicate(&dso->symbols);
if (kmap) {
/*
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -217,7 +217,8 @@ again:
}
}
-void symbols__fixup_end(struct rb_root_cached *symbols)
+void symbols__fixup_end(struct rb_root_cached *symbols,
+ bool is_kallsyms __maybe_unused)
{
struct rb_node *nd, *prevnd = rb_first_cached(symbols);
struct symbol *curr, *prev;
@@ -1456,7 +1457,7 @@ int __dso__load_kallsyms(struct dso *dso
if (kallsyms__delta(kmap, filename, &delta))
return -1;
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, true);
symbols__fixup_duplicate(&dso->symbols);
if (dso->kernel == DSO_SPACE__KERNEL_GUEST)
@@ -1651,7 +1652,7 @@ int dso__load_bfd_symbols(struct dso *ds
#undef bfd_asymbol_section
#endif
- symbols__fixup_end(&dso->symbols);
+ symbols__fixup_end(&dso->symbols, false);
symbols__fixup_duplicate(&dso->symbols);
dso->adjust_symbols = 1;
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -192,7 +192,7 @@ void __symbols__insert(struct rb_root_ca
bool kernel);
void symbols__insert(struct rb_root_cached *symbols, struct symbol *sym);
void symbols__fixup_duplicate(struct rb_root_cached *symbols);
-void symbols__fixup_end(struct rb_root_cached *symbols);
+void symbols__fixup_end(struct rb_root_cached *symbols, bool is_kallsyms);
void maps__fixup_end(struct maps *maps);
typedef int (*mapfn_t)(u64 start, u64 len, u64 pgoff, void *data);
Patches currently in stable-queue which might be from namhy...@kernel.org are
queue-5.10/perf-symbol-update-symbols__fixup_end.patch
queue-5.10/perf-symbol-pass-is_kallsyms-to-symbols__fixup_end.patch
Re: [PATCH 06/30] soc: bcm: brcmstb: Document panic notifier action and remove useless header
On 02/05/2022 12:38, Florian Fainelli wrote: > [...] > Acked-by: Florian Fainelli > > Likewise, I am not sure if the Fixes tag is necessary here. Perfect Florian, thanks! I'll add your Acked-by tag and remove the fixes for V2 =) Cheers, Guilherme
Re: [PATCH 06/30] soc: bcm: brcmstb: Document panic notifier action and remove useless header
On 4/27/2022 3:49 PM, Guilherme G. Piccoli wrote:
The panic notifier of this driver is very simple code-wise, just a memory
write to a special position with some numeric code. But this is not clear
from the semantic point-of-view, and there is no public documentation
about that either.
After discussing this in the mailing-lists [0] and having Florian explained
it very well, this patch just document that in the code for the future
generations asking the same questions. Also, it removes a useless header.
[0] https://lore.kernel.org/lkml/781cafb0-8d06-8b56-907a-5175c2da1...@gmail.com
Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states
(ARM)")
Cc: Brian Norris
Cc: Doug Berger
Cc: Florian Fainelli
Cc: Justin Chen
Cc: Lee Jones
Cc: Markus Mayer
Signed-off-by: Guilherme G. Piccoli
Acked-by: Florian Fainelli
Likewise, I am not sure if the Fixes tag is necessary here.
--
Florian
Re: [PATCH 15/30] bus: brcmstb_gisb: Clean-up panic/die notifiers
On 4/27/2022 3:49 PM, Guilherme G. Piccoli wrote:
This patch improves the panic/die notifiers in this driver by
making use of a passed "id" instead of comparing pointer
address; also, it removes an useless prototype declaration
and unnecessary header inclusion.
This is part of a panic notifiers refactor - this notifier in
the future will be moved to a new list, that encompass the
information notifiers only.
Fixes: 9eb60880d9a9 ("bus: brcmstb_gisb: add notifier handling")
Cc: Brian Norris
Cc: Florian Fainelli
Signed-off-by: Guilherme G. Piccoli
Acked-by: Florian Fainelli
Not sure if the Fixes tag is warranted however as this is a clean up,
and not really fixing a bug.
--
Florian
[PATCH v2] powerpc/4xx: cpm: fix return value of __setup handler
__setup() handlers should return 1 to obsolete_checksetup() in
init/main.c to indicate that the boot option has been handled.
A return of 0 causes the boot option/value to be listed as an Unknown
kernel parameter and added to init's (limited) argument or environment
strings. Also, error return codes don't mean anything to
obsolete_checksetup() -- only non-zero (usually 1) or zero.
So return 1 from cpm_powersave_off().
Fixes: d164f6d4f910 ("powerpc/4xx: Add suspend and idle support")
Signed-off-by: Randy Dunlap
Reported-by: Igor Zhbanov
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0de...@omprussia.ru
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
v2: drop some email addresses that bounced;
change From: Igor to Reported-by: Igor
update Igor's email address
arch/powerpc/platforms/4xx/cpm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/4xx/cpm.c
+++ b/arch/powerpc/platforms/4xx/cpm.c
@@ -327,6 +327,6 @@ late_initcall(cpm_init);
static int __init cpm_powersave_off(char *arg)
{
cpm.powersave_off = 1;
- return 0;
+ return 1;
}
__setup("powersave=off", cpm_powersave_off);
[PATCH v2] POWERPC: idle: fix return value of __setup handler
__setup() handlers should return 1 to obsolete_checksetup() in
init/main.c to indicate that the boot option has been handled.
A return of 0 causes the boot option/value to be listed as an Unknown
kernel parameter and added to init's (limited) argument or environment
strings. Also, error return codes don't mean anything to
obsolete_checksetup() -- only non-zero (usually 1) or zero.
So return 1 from powersave_off().
Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of
cbe_idle_loop")
Signed-off-by: Randy Dunlap
Reported-by: Igor Zhbanov
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0de...@omprussia.ru
Cc: Arnd Bergmann
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
---
v2: change From: Igor to Reported-by: Igor
update Igor's email address
arch/powerpc/kernel/idle.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -37,7 +37,7 @@ static int __init powersave_off(char *ar
{
ppc_md.power_save = NULL;
cpuidle_disable = IDLE_POWERSAVE_OFF;
- return 0;
+ return 1;
}
__setup("powersave=off", powersave_off);
Re: [PATCH] POWERPC: idle: fix return value of __setup handler
On 5/2/22 11:45, Christophe Leroy wrote:
>
>
> Le 02/05/2022 à 17:50, Randy Dunlap a écrit :
>>
>>
>> On 5/2/22 06:19, Michael Ellerman wrote:
>>> Randy Dunlap writes:
__setup() handlers should return 1 to obsolete_checksetup() in
init/main.c to indicate that the boot option has been handled.
A return of 0 causes the boot option/value to be listed as an Unknown
kernel parameter and added to init's (limited) argument or environment
strings. Also, error return codes don't mean anything to
obsolete_checksetup() -- only non-zero (usually 1) or zero.
So return 1 from powersave_off().
Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of
cbe_idle_loop")
Signed-off-by: Randy Dunlap
From: Igor Zhbanov
>>>
>>> What happened here? Is the patch actually from Igor? If so he should be
>>> the author, and it should include his SoB shouldn't it?
>>
>> I don't know what happened. I did the patches.
>> I'll resend them.
>>
>
> Some erroneous copy/paste from
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220308024228.20477-1-rdun...@infradead.org/
>
> ?
Yes, it should have been Reported-by:
>
>> Thanks.
>>
>>> Same comment for "[PATCH] powerpc/4xx: cpm: fix return value of __setup
>>> handler".
>>>
>>> cheers
>>>
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0de...@omprussia.ru
Cc: Arnd Bergmann
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
---
arch/powerpc/kernel/idle.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20220310.orig/arch/powerpc/kernel/idle.c
+++ linux-next-20220310/arch/powerpc/kernel/idle.c
@@ -37,7 +37,7 @@ static int __init powersave_off(char *ar
{
ppc_md.power_save = NULL;
cpuidle_disable = IDLE_POWERSAVE_OFF;
- return 0;
+ return 1;
}
__setup("powersave=off", powersave_off);
--
~Randy
Re: [PATCH] POWERPC: idle: fix return value of __setup handler
Le 02/05/2022 à 17:50, Randy Dunlap a écrit :
>
>
> On 5/2/22 06:19, Michael Ellerman wrote:
>> Randy Dunlap writes:
>>> __setup() handlers should return 1 to obsolete_checksetup() in
>>> init/main.c to indicate that the boot option has been handled.
>>> A return of 0 causes the boot option/value to be listed as an Unknown
>>> kernel parameter and added to init's (limited) argument or environment
>>> strings. Also, error return codes don't mean anything to
>>> obsolete_checksetup() -- only non-zero (usually 1) or zero.
>>> So return 1 from powersave_off().
>>>
>>> Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of
>>> cbe_idle_loop")
>>> Signed-off-by: Randy Dunlap
>>> From: Igor Zhbanov
>>
>> What happened here? Is the patch actually from Igor? If so he should be
>> the author, and it should include his SoB shouldn't it?
>
> I don't know what happened. I did the patches.
> I'll resend them.
>
Some erroneous copy/paste from
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220308024228.20477-1-rdun...@infradead.org/
?
> Thanks.
>
>> Same comment for "[PATCH] powerpc/4xx: cpm: fix return value of __setup
>> handler".
>>
>> cheers
>>
>>> Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0de...@omprussia.ru
>>> Cc: Arnd Bergmann
>>> Cc: Paul Mackerras
>>> Cc: Michael Ellerman
>>> Cc: Benjamin Herrenschmidt
>>> ---
>>> arch/powerpc/kernel/idle.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> --- linux-next-20220310.orig/arch/powerpc/kernel/idle.c
>>> +++ linux-next-20220310/arch/powerpc/kernel/idle.c
>>> @@ -37,7 +37,7 @@ static int __init powersave_off(char *ar
>>> {
>>> ppc_md.power_save = NULL;
>>> cpuidle_disable = IDLE_POWERSAVE_OFF;
>>> - return 0;
>>> + return 1;
>>> }
>>> __setup("powersave=off", powersave_off);
>>>
>
Re: [PATCH kernel] KVM: PPC: Book3s: Retire H_PUT_TCE/etc real mode handlers
Alexey Kardashevskiy writes: > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > index d185dee26026..44d74bfe05df 100644 > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > @@ -1784,13 +1784,8 @@ hcall_real_table: > .long DOTSYM(kvmppc_h_clear_mod) - hcall_real_table > .long DOTSYM(kvmppc_h_clear_ref) - hcall_real_table > .long DOTSYM(kvmppc_h_protect) - hcall_real_table > -#ifdef CONFIG_SPAPR_TCE_IOMMU > - .long DOTSYM(kvmppc_h_get_tce) - hcall_real_table > - .long DOTSYM(kvmppc_rm_h_put_tce) - hcall_real_table > -#else > .long 0 /* 0x1c */ > .long 0 /* 0x20 */ > -#endif > .long 0 /* 0x24 - H_SET_SPRG0 */ > .long DOTSYM(kvmppc_h_set_dabr) - hcall_real_table > .long DOTSYM(kvmppc_rm_h_page_init) - hcall_real_table > @@ -1868,13 +1863,8 @@ hcall_real_table: > .long 0 /* 0x12c */ > .long 0 /* 0x130 */ > .long DOTSYM(kvmppc_h_set_xdabr) - hcall_real_table > -#ifdef CONFIG_SPAPR_TCE_IOMMU > - .long DOTSYM(kvmppc_rm_h_stuff_tce) - hcall_real_table > - .long DOTSYM(kvmppc_rm_h_put_tce_indirect) - hcall_real_table > -#else > .long 0 /* 0x138 */ > .long 0 /* 0x13c */ > -#endif > .long 0 /* 0x140 */ > .long 0 /* 0x144 */ > .long 0 /* 0x148 */ The ones you remove from here need to be added to kvmppc_hcall_impl_hv, otherwise we get the WARN at init_default_hcalls because kvmppc_hcall_impl_hv_realmode can't find them.
Re: [PATCH 15/30] bus: brcmstb_gisb: Clean-up panic/die notifiers
On 02/05/2022 12:38, Florian Fainelli wrote: > [...] > > Acked-by: Florian Fainelli > > Not sure if the Fixes tag is warranted however as this is a clean up, > and not really fixing a bug. Perfect, thanks Florian. I'll add your ACK and remove the fixes tag in V2. Cheers, Guilherme
Re: [PATCH] POWERPC: idle: fix return value of __setup handler
On 5/2/22 06:19, Michael Ellerman wrote:
> Randy Dunlap writes:
>> __setup() handlers should return 1 to obsolete_checksetup() in
>> init/main.c to indicate that the boot option has been handled.
>> A return of 0 causes the boot option/value to be listed as an Unknown
>> kernel parameter and added to init's (limited) argument or environment
>> strings. Also, error return codes don't mean anything to
>> obsolete_checksetup() -- only non-zero (usually 1) or zero.
>> So return 1 from powersave_off().
>>
>> Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of
>> cbe_idle_loop")
>> Signed-off-by: Randy Dunlap
>> From: Igor Zhbanov
>
> What happened here? Is the patch actually from Igor? If so he should be
> the author, and it should include his SoB shouldn't it?
I don't know what happened. I did the patches.
I'll resend them.
Thanks.
> Same comment for "[PATCH] powerpc/4xx: cpm: fix return value of __setup
> handler".
>
> cheers
>
>> Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0de...@omprussia.ru
>> Cc: Arnd Bergmann
>> Cc: Paul Mackerras
>> Cc: Michael Ellerman
>> Cc: Benjamin Herrenschmidt
>> ---
>> arch/powerpc/kernel/idle.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- linux-next-20220310.orig/arch/powerpc/kernel/idle.c
>> +++ linux-next-20220310/arch/powerpc/kernel/idle.c
>> @@ -37,7 +37,7 @@ static int __init powersave_off(char *ar
>> {
>> ppc_md.power_save = NULL;
>> cpuidle_disable = IDLE_POWERSAVE_OFF;
>> -return 0;
>> +return 1;
>> }
>> __setup("powersave=off", powersave_off);
>>
--
~Randy
Re: Any technical information for Wind River 7457 board?
Le 28/04/2022 à 19:33, Steven J. Hill a écrit : > Below is the serial output at power on. Does anyone have any information > at all? I know the processor is a single 7457 with Marvell/Galileo > GT64260A host bridge. I think the board was made by Motorola or NXP. It > has been difficult to track anything without Wind River support. > > -Steve > > > > VxWorks 653 System Boot > > > Copyright 1984-2006 Wind River Systems, Inc. > > > > > > CPU: wrSbc7457 Power PC > Version: 1.8 > BSP version: 1.3/9 > Creation date: Jun 9 2006, 11:38:14 Did you try to google it ? Christophe
Re: [PATCH 2/2] recordmcount: Handle sections with no non-weak symbols
Le 28/04/2022 à 16:06, Steven Rostedt a écrit : > On Thu, 28 Apr 2022 13:15:22 +0530 > "Naveen N. Rao" wrote: > >> Indeed, plain old -pg will be a problem. I'm not sure there is a generic >> way to address this. I suppose architectures will have to validate the >> mcount locations, something like this? > > Perhaps another solution is to make the mcount locations after the linking > is done. The main downside to that is that it takes time to go over the > entire vmlinux, and will slow down a compile that only modified a couple of > files. > If we do that after the linking, won't it be a nightmare with the trampolines installed by the linker when the destination is over the 24 bits limit ? Christophe
Re: [PATCH] tty: hvcs: simplify if-if to if-else
Le 24/04/2022 à 11:13, Wan Jiabing a écrit :
> Use if and else instead of if(A) and if (!A) and fix a coding style.
>
> Signed-off-by: Wan Jiabing
Did you run 'checkpatch' on your patch ?
Should be
if (something)
do_something();
else
do_something_else();
or
if (something) {
do_something();
} else {
do_something_else();
do_more();
}
However, are you sure that those two things are going together and are
worth an if/else ? Did you look at commit
33f0f88f1c51ae5c2d593d26960c760ea154c2e2 ?
> ---
> drivers/tty/hvc/hvcs.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
> index 245da1dfd818..9b7e8246a464 100644
> --- a/drivers/tty/hvc/hvcs.c
> +++ b/drivers/tty/hvc/hvcs.c
> @@ -581,10 +581,9 @@ static int hvcs_io(struct hvcs_struct *hvcsd)
>
> spin_unlock_irqrestore(&hvcsd->lock, flags);
> /* This is synch -- FIXME :js: it is not! */
> - if(got)
> + if (got)
> tty_flip_buffer_push(&hvcsd->port);
> -
> - if (!got) {
> + else {
> /* Do this _after_ the flip_buffer_push */
> spin_lock_irqsave(&hvcsd->lock, flags);
> vio_enable_interrupts(hvcsd->vdev);
Re: [PATCH] powerpc/vdso: Fix incorrect CFI in gettimeofday.S
Hi!
On Mon, May 02, 2022 at 10:50:10PM +1000, Michael Ellerman wrote:
> As reported by Alan, the CFI (Call Frame Information) in the VDSO time
> routines is incorrect since commit ce7d8056e38b ("powerpc/vdso: Prepare
> for switching VDSO to generic C implementation.").
>
> In particular the changes to the frame address register (r1) are not
> properly described, which prevents gdb from being able to generate a
> backtrace from inside VDSO functions, eg:
Note that r1 is not the same as the CFA: r1 is the stack pointer, while
the CFA is a DWARF concept. Often (but not always) they point to the
same thing, for us. "When we change the stack pointer we should change
the DWARF CFA as well"?
> Alan helpfully describes some rules for correctly maintaining the CFI
> information:
>
> 1) Every adjustment to the current frame address reg (ie. r1) must be
> described, and exactly at the instruction where r1 changes. Why?
> Because stack unwinding might want to access previous frames.
> 2) If a function changes LR or any non-volatile register, the save
> location for those regs must be given. The cfi can be at any
> instruction after the saves up to the point that the reg is
> changed. (Exception: LR save should be described before a bl.)
That isn't an exception? bl changes the current LR after all :-)
> 3) If asychronous unwind info is needed then restores of LR and
> non-volatile regs must also be described. The cfi can be at any
> instruction after the reg is restored up to the point where the
> save location is (potentially) trashed.
The general rule is that your CFI must enable a debugger to reconstruct
the state at function entry (or it can explicitly say something has been
clobbered), using only data available at any point in the program we are
at now. If something is available in multiple places (in some
registers, somewhere in memory) either place can be used; only one such
place is described in the CFI. A store or even a restore does not have
to be described at the exact spot it happens (but that is by far the
most readable / least confusing way to do it).
> --- a/arch/powerpc/kernel/vdso/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso/gettimeofday.S
> @@ -22,12 +22,15 @@
> .macro cvdso_call funct call_time=0
>.cfi_startproc
> PPC_STLUr1, -PPC_MIN_STKFRM(r1)
> + .cfi_adjust_cfa_offset PPC_MIN_STKFRM
> mflrr0
> - .cfi_register lr, r0
> PPC_STLUr1, -PPC_MIN_STKFRM(r1)
> + .cfi_adjust_cfa_offset PPC_MIN_STKFRM
> PPC_STL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> + .cfi_rel_offset lr, PPC_MIN_STKFRM + PPC_LR_STKOFF
So you don't need to describe lr being saved in r0, because at all times
it is available elsewhere, namely in the lr reg still, or on the stack.
If lr could be clobbered before r0 is saved to the stack slot you would
still need to describe r0 containing the value of lr at function entry,
because that value then isn't available elsewhere.
The patch looks good to me :-)
Reviewed-by: Segher Boessenkool
Segher
Re: [PATCH -next v4 1/7] x86, powerpc: fix function define in copy_mc_to_user
Le 20/04/2022 à 05:04, Tong Tiangen a écrit :
> x86/powerpc has it's implementation of copy_mc_to_user but not use #define
> to declare.
>
> This may cause problems, for example, if other architectures open
> CONFIG_ARCH_HAS_COPY_MC, but want to use copy_mc_to_user() outside the
> architecture, the code add to include/linux/uaddess.h is as follows:
>
> #ifndef copy_mc_to_user
> static inline unsigned long __must_check
> copy_mc_to_user(void *dst, const void *src, size_t cnt)
> {
> ...
> }
> #endif
>
> Then this definition will conflict with the implementation of x86/powerpc
> and cause compilation errors as follow:
>
> Fixes: ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to
> copy_mc_to_{user, kernel}()")
I don't understand, what does it fix really ? What was the
(existing/real) bug introduced by that patch and that your are fixing ?
If those defined had been expected and missing, we would have had a
build failure. If you have one, can you describe it ?
> Signed-off-by: Tong Tiangen
> ---
> arch/powerpc/include/asm/uaccess.h | 1 +
> arch/x86/include/asm/uaccess.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/uaccess.h
> b/arch/powerpc/include/asm/uaccess.h
> index 9b82b38ff867..58dbe8e2e318 100644
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -358,6 +358,7 @@ copy_mc_to_user(void __user *to, const void *from,
> unsigned long n)
>
> return n;
> }
> +#define copy_mc_to_user copy_mc_to_user
> #endif
>
> extern long __copy_from_user_flushcache(void *dst, const void __user *src,
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index f78e2b3501a1..e18c5f098025 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -415,6 +415,7 @@ copy_mc_to_kernel(void *to, const void *from, unsigned
> len);
>
> unsigned long __must_check
> copy_mc_to_user(void *to, const void *from, unsigned len);
> +#define copy_mc_to_user copy_mc_to_user
> #endif
>
> /*
Re: [PATCH 3/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when unmapping
On Sat, 30 Apr 2022 11:22:33 +0800
Baolin Wang wrote:
>
>
> On 4/30/2022 4:02 AM, Gerald Schaefer wrote:
> > On Fri, 29 Apr 2022 16:14:43 +0800
> > Baolin Wang wrote:
> >
> >> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> >> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> >> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> >> size specified.
> >>
> >> When unmapping a hugetlb page, we will get the relevant page table
> >> entry by huge_pte_offset() only once to nuke it. This is correct
> >> for PMD or PUD size hugetlb, since they always contain only one
> >> pmd entry or pud entry in the page table.
> >>
> >> However this is incorrect for CONT-PTE and CONT-PMD size hugetlb,
> >> since they can contain several continuous pte or pmd entry with
> >> same page table attributes, so we will nuke only one pte or pmd
> >> entry for this CONT-PTE/PMD size hugetlb page.
> >>
> >> And now we only use try_to_unmap() to unmap a poisoned hugetlb page,
> >> which means now we will unmap only one pte entry for a CONT-PTE or
> >> CONT-PMD size poisoned hugetlb page, and we can still access other
> >> subpages of a CONT-PTE or CONT-PMD size poisoned hugetlb page,
> >> which will cause serious issues possibly.
> >>
> >> So we should change to use huge_ptep_clear_flush() to nuke the
> >> hugetlb page table to fix this issue, which already considered
> >> CONT-PTE and CONT-PMD size hugetlb.
> >>
> >> Note we've already used set_huge_swap_pte_at() to set a poisoned
> >> swap entry for a poisoned hugetlb page.
> >>
> >> Signed-off-by: Baolin Wang
> >> ---
> >> mm/rmap.c | 34 +-
> >> 1 file changed, 17 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/mm/rmap.c b/mm/rmap.c
> >> index 7cf2408..1e168d7 100644
> >> --- a/mm/rmap.c
> >> +++ b/mm/rmap.c
> >> @@ -1564,28 +1564,28 @@ static bool try_to_unmap_one(struct folio *folio,
> >> struct vm_area_struct *vma,
> >>break;
> >>}
> >>}
> >> + pteval = huge_ptep_clear_flush(vma, address, pvmw.pte);
> >
> > Unlike in your patch 2/3, I do not see that this (huge) pteval would later
> > be used again with set_huge_pte_at() instead of set_pte_at(). Not sure if
> > this (huge) pteval could end up at a set_pte_at() later, but if yes, then
> > this would be broken on s390, and you'd need to use set_huge_pte_at()
> > instead of set_pte_at() like in your patch 2/3.
>
> IIUC, As I said in the commit message, we will only unmap a poisoned
> hugetlb page by try_to_unmap(), and the poisoned hugetlb page will be
> remapped with a poisoned entry by set_huge_swap_pte_at() in
> try_to_unmap_one(). So I think no need change to use set_huge_pte_at()
> instead of set_pte_at() for other cases, since the hugetlb page will not
> hit other cases.
>
> if (PageHWPoison(subpage) && !(flags & TTU_IGNORE_HWPOISON)) {
> pteval = swp_entry_to_pte(make_hwpoison_entry(subpage));
> if (folio_test_hugetlb(folio)) {
> hugetlb_count_sub(folio_nr_pages(folio), mm);
> set_huge_swap_pte_at(mm, address, pvmw.pte, pteval,
>vma_mmu_pagesize(vma));
> } else {
> dec_mm_counter(mm, mm_counter(&folio->page));
> set_pte_at(mm, address, pvmw.pte, pteval);
> }
>
> }
OK, but wouldn't the pteval be overwritten here with
pteval = swp_entry_to_pte(make_hwpoison_entry(subpage))?
IOW, what sense does it make to save the returned pteval from
huge_ptep_clear_flush(), when it is never being used anywhere?
Re: [PATCH linux-next] power:pkeys: fix bugon.cocci warnings
CGEL writes:
> From: Jing Yangyang
>
> Use BUG_ON instead of a if condition followed by BUG.
>
> ./arch/powerpc/include/asm/book3s/64/pkeys.h:21:2-5:WARNING
> Use BUG_ON instead of if condition followed by BUG.
> ./arch/powerpc/include/asm/book3s/64/pkeys.h:14:2-5:WARNING
> Use BUG_ON instead of if condition followed by BUG.
>
> Generated by: scripts/coccinelle/misc/bugon.cocci
>
> Reported-by: Zeal Robot
> Signed-off-by: Jing Yangyang
> ---
> arch/powerpc/include/asm/book3s/64/pkeys.h | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pkeys.h
> b/arch/powerpc/include/asm/book3s/64/pkeys.h
> index 5b17813..5f74f0c 100644
> --- a/arch/powerpc/include/asm/book3s/64/pkeys.h
> +++ b/arch/powerpc/include/asm/book3s/64/pkeys.h
> @@ -10,15 +10,13 @@ static inline u64 vmflag_to_pte_pkey_bits(u64 vm_flags)
> if (!mmu_has_feature(MMU_FTR_PKEY))
> return 0x0UL;
>
> - if (radix_enabled())
> - BUG();
> + BUG_ON(radix_enabled());
> return hash__vmflag_to_pte_pkey_bits(vm_flags);
> }
>
> static inline u16 pte_to_pkey_bits(u64 pteflags)
> {
> - if (radix_enabled())
> - BUG();
> + BUG_ON(radix_enabled());
> return hash__pte_to_pkey_bits(pteflags);
> }
Have you checked how this changes the generated code?
radix_enabled() is a jump label, via mmu_feature().
Possibly the compiler just works it all out and generates the same code,
but I'd want some evidence of that before merging this.
cheers
Re: [PATCH] POWERPC: idle: fix return value of __setup handler
Randy Dunlap writes:
> __setup() handlers should return 1 to obsolete_checksetup() in
> init/main.c to indicate that the boot option has been handled.
> A return of 0 causes the boot option/value to be listed as an Unknown
> kernel parameter and added to init's (limited) argument or environment
> strings. Also, error return codes don't mean anything to
> obsolete_checksetup() -- only non-zero (usually 1) or zero.
> So return 1 from powersave_off().
>
> Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of
> cbe_idle_loop")
> Signed-off-by: Randy Dunlap
> From: Igor Zhbanov
What happened here? Is the patch actually from Igor? If so he should be
the author, and it should include his SoB shouldn't it?
Same comment for "[PATCH] powerpc/4xx: cpm: fix return value of __setup
handler".
cheers
> Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0de...@omprussia.ru
> Cc: Arnd Bergmann
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/idle.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20220310.orig/arch/powerpc/kernel/idle.c
> +++ linux-next-20220310/arch/powerpc/kernel/idle.c
> @@ -37,7 +37,7 @@ static int __init powersave_off(char *ar
> {
> ppc_md.power_save = NULL;
> cpuidle_disable = IDLE_POWERSAVE_OFF;
> - return 0;
> + return 1;
> }
> __setup("powersave=off", powersave_off);
>
[PATCH] powerpc/vdso: Fix incorrect CFI in gettimeofday.S
As reported by Alan, the CFI (Call Frame Information) in the VDSO time
routines is incorrect since commit ce7d8056e38b ("powerpc/vdso: Prepare
for switching VDSO to generic C implementation.").
In particular the changes to the frame address register (r1) are not
properly described, which prevents gdb from being able to generate a
backtrace from inside VDSO functions, eg:
Breakpoint 1, 0x77f804dc in __kernel_clock_gettime ()
(gdb) bt
#0 0x77f804dc in __kernel_clock_gettime ()
#1 0x77d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
#2 0x7fffd960 in ?? ()
#3 0x77d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
Backtrace stopped: frame did not save the PC
Alan helpfully describes some rules for correctly maintaining the CFI
information:
1) Every adjustment to the current frame address reg (ie. r1) must be
described, and exactly at the instruction where r1 changes. Why?
Because stack unwinding might want to access previous frames.
2) If a function changes LR or any non-volatile register, the save
location for those regs must be given. The cfi can be at any
instruction after the saves up to the point that the reg is
changed. (Exception: LR save should be described before a bl.)
3) If asychronous unwind info is needed then restores of LR and
non-volatile regs must also be described. The cfi can be at any
instruction after the reg is restored up to the point where the
save location is (potentially) trashed.
Fix the inability to backtrace by adding CFI directives describing the
changes to r1, ie. satisfying rule 1.
Also change the information for LR to point to the copy saved on the
stack, not the value in r0 that will be overwritten by the function
call.
Finally, add CFI directives describing the save/restore of r2.
With the fix gdb can correctly back trace and navigate up and down the stack:
Breakpoint 1, 0x77f804dc in __kernel_clock_gettime ()
(gdb) bt
#0 0x77f804dc in __kernel_clock_gettime ()
#1 0x77d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
#2 0x000100015b60 in gettime ()
#3 0x0001c8bc in print_long_format ()
#4 0x0001d180 in print_current_files ()
#5 0x000154ac in main ()
(gdb) up
#1 0x77d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
(gdb)
#2 0x000100015b60 in gettime ()
(gdb)
#3 0x0001c8bc in print_long_format ()
(gdb)
#4 0x0001d180 in print_current_files ()
(gdb)
#5 0x000154ac in main ()
(gdb)
Initial frame selected; you cannot go up.
(gdb) down
#4 0x0001d180 in print_current_files ()
(gdb)
#3 0x0001c8bc in print_long_format ()
(gdb)
#2 0x000100015b60 in gettime ()
(gdb)
#1 0x77d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
(gdb)
#0 0x77f804dc in __kernel_clock_gettime ()
(gdb)
Fixes: ce7d8056e38b ("powerpc/vdso: Prepare for switching VDSO to generic C
implementation.")
Cc: sta...@vger.kernel.org # v5.11+
Reported-by: Alan Modra
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/vdso/gettimeofday.S | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Alan proposed a larger patch that changed to a single stack frame, but it needs
changes to
take into account the red zone.
Anyway for stable I'd prefer to just fix the CFI, we can rework the stack frame
in a
subsequent patch.
diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S
b/arch/powerpc/kernel/vdso/gettimeofday.S
index eb9c81e1c218..0aee255e9cbb 100644
--- a/arch/powerpc/kernel/vdso/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso/gettimeofday.S
@@ -22,12 +22,15 @@
.macro cvdso_call funct call_time=0
.cfi_startproc
PPC_STLUr1, -PPC_MIN_STKFRM(r1)
+ .cfi_adjust_cfa_offset PPC_MIN_STKFRM
mflrr0
- .cfi_register lr, r0
PPC_STLUr1, -PPC_MIN_STKFRM(r1)
+ .cfi_adjust_cfa_offset PPC_MIN_STKFRM
PPC_STL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
+ .cfi_rel_offset lr, PPC_MIN_STKFRM + PPC_LR_STKOFF
#ifdef __powerpc64__
PPC_STL r2, PPC_MIN_STKFRM + STK_GOT(r1)
+ .cfi_rel_offset r2, PPC_MIN_STKFRM + STK_GOT
#endif
get_datapager5
.ifeq \call_time
@@ -39,6 +42,7 @@
PPC_LL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
#ifdef __powerpc64__
PPC_LL r2, PPC_MIN_STKFRM + STK_GOT(r1)
+ .cfi_restore r2
#endif
.ifeq \call_time
cmpwi r3, 0
@@ -46,6 +50,7 @@
mtlrr0
.cfi_restore lr
addir1, r1, 2 * PPC_MIN_STKFRM
+ .cfi_def_cfa_offset 0
crclr so
.ifeq \call_time
beqlr+
--
2.35.1
[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
https://bugzilla.kernel.org/show_bug.cgi?id=215389 --- Comment #15 from Erhard F. (erhar...@mailbox.org) --- It definitively still happens with the default values. Can test with the reduced CONFIG_LOWMEM_SIZE next week and report back. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
https://bugzilla.kernel.org/show_bug.cgi?id=215389 --- Comment #14 from Christophe Leroy (christophe.le...@csgroup.eu) --- Do you mean it still happens with the default values, or it also happens with the reduced CONFIG_LOWMEM_SIZE ? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
