Re: [Crash-utility] arm64: Get CPU registers without crash_notes symbol
by lijiang
> On Fri, 2021-08-20 at 01:26 +0000, HAGIO KAZUHITO(萩尾 一仁) wrote:
> > -----Original Message-----
> > > Dear Kazu,
> > >
> > > Sorry for late reply
> > > Thanks for your suggestion and I have prepared a V2 patch, please
> > > help
> > > to review.
> >
> > ok, I've modified your v2 patch to fix the following compilation
> > warning
> > and rewrite the commit log, and attached it.
> >
> > arm64.c: In function ‘arm64_init’:
> > arm64.c:3728:35: warning: ‘note’ may be used uninitialized in this
> > function [-Wmaybe-uninitialized]
>
This warning can be eliminated as follows:
--- a/arm64.c
+++ b/arm64.c
@@ -3698,14 +3698,48 @@ arm64_get_crash_notes(void)
{
struct machine_specific *ms = machdep->machspec;
ulong crash_notes;
- Elf64_Nhdr *note;
+ Elf64_Nhdr *note = NULL;
ulong offset;
But I didn't see this correction in V2. Can you help to add the
initialization of the note variable Kazu. Otherwise:
Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
BTW: the patch format is still unfriendly to me.
Thanks
Lianbo
> offset = roundup(offset + note->n_namesz, 4);
> > ^~
> > Kazu, thanks for your kind help.
>
> > Lianbo, could you review the attached patch?
> >
> > Thanks,
> > Kazu
>
3 years, 2 months
- 2
- 1
Re: [Crash-utility] [PATCH 1/1] fix left bit-shift overflow in __exclude_unnecessary_pages()
by HAGIO KAZUHITO(萩尾 一仁)
Hi Alex,
+cc kexec list (the right one for makedumpfile patch)
-----Original Message-----
> Whenever the variables compound_order or private become greater than
> 31, left bit-shift of 1 overflows, and nr_pages becomes zero. If nr_pages
> becomes 0 and pages are being excluded at the end of the PFN loop, the
> else branch of the last if statement is entered and pfn is decremented by
> 1 because nr_pages is 0. Finally, this causes the loop variable pfn to
> be assigned the same value as before when the next loop iteration begins
> which results in an infinite loop.
>
> This issue appeared on s390 64bit architecture with a dump of 16GB RAM.
The patch looks good to me, but just out of curiosity, when do the
compound_order or private become greater than 31 on s390?
Thanks,
Kazu
>
> This is a simple program to demonstrate the primary issue:
>
> void main(void)
> {
> unsigned long long n;
> unsigned long m;
>
> m = 32;
> n = 1 << m;
> fprintf(stderr, "%llx\n", n);
> n = 1UL << m;
> fprintf(stderr, "%llx\n", n);
> }
>
> Signed-off-by: Alexander Egorenkov <egorenar(a)linux.ibm.com>
> ---
> makedumpfile.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/makedumpfile.c b/makedumpfile.c
> index c063267f15bb..863840b13608 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -6210,7 +6210,7 @@ __exclude_unnecessary_pages(unsigned long mem_map,
> if (OFFSET(page.private) != NOT_FOUND_STRUCTURE)
> private = ULONG(pcache + OFFSET(page.private));
>
> - nr_pages = 1 << compound_order;
> + nr_pages = 1UL << compound_order;
> pfn_counter = NULL;
>
> /*
> @@ -6227,7 +6227,7 @@ __exclude_unnecessary_pages(unsigned long mem_map,
> else if ((info->dump_level & DL_EXCLUDE_FREE)
> && info->page_is_buddy
> && info->page_is_buddy(flags, _mapcount, private, _count)) {
> - nr_pages = 1 << private;
> + nr_pages = 1UL << private;
> pfn_counter = &pfn_free;
> }
> /*
> --
> 2.31.1
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://listman.redhat.com/mailman/listinfo/crash-utility
3 years, 2 months
- 2
- 3