On Wed, Mar 18, 2020 at 2:35 AM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > On Wed, Mar 18, 2020 at 01:49:05AM +0530, Bhupesh Sharma wrote: > > On Wed, Mar 18, 2020 at 1:05 AM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > > > > > On Tue, Mar 17, 2020 at 02:14:22PM +0000, HAGIO KAZUHITO(萩尾 一仁) wrote: > > > > Hi Michal, > > > > > > > > Thank you for the patch. > > > > > > > > > -----Original Message----- > > > > > Reportedly on some arm64 systems makedumpfile loops forever exhausting > > > > > all memory when filtering kernel core. It turns out the reason is it > > > > > cannot resolve some addresses because the PMD mask is wrong. When > > > > > physical address mask allows up to 48bits pmd mask should allow the > > > > > same. > > > > > I suppose you would need a system that needs physical addresses over 1TB > > > > > to be able to reproduce this. This may be either because you have a lot > > > > > of memory or because the firmware mapped some memory above 1TB for some > > > > > reason. > > > > > > > > > > Signed-off-by: Michal Suchanek <msuchanek@xxxxxxx> > > > > > --- > > > > > arch/arm64.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/arm64.c b/arch/arm64.c > > > > > index 43164ccc32d4..54d60b440850 100644 > > > > > --- a/arch/arm64.c > > > > > +++ b/arch/arm64.c > > > > > @@ -81,7 +81,7 @@ static unsigned long kimage_voffset; > > > > > * Remove the highest order bits that are not a part of the > > > > > * physical address in a section > > > > > */ > > > > > -#define PMD_SECTION_MASK ((1UL << 40) - 1) > > > > > +#define PMD_SECTION_MASK ((1UL << PHYS_MASK_SHIFT) - 1) > > > > > > > > > > #define PMD_TYPE_MASK 3 > > > > > #define PMD_TYPE_SECT 1 > > > > > -- > > > > > 2.23.0 > > > > > > > > > > > > > Then I'd prefer to remove PMD_SECTION_MASK and use PHYS_MASK instead. > > > > Is it OK? Keeping PMD_SECTION_MASK looks a little confusing to me. > > > > > > This code will need to be changed for 52bit support. It remains to be > > > seen if the mask will be still the same after that. I would go with just > > > the minimal fix for now to not complicate things. > > > > Exactly. I am planning to send out the latest refresh of the kernel > > and makedumpfile changes for 52-bit makedumpfile/crash support this > > week. > > > > If we can wait for the same, I think it would be better as the code > > changes/names would be more streamlined and similar to Linux > > conventions. > > > > Please let me know if that makes sense. > > I think both is useful. This is a minimal patch that can be applied to > historical versions of makedumpfile in distributions. This seems to have > been broken for quite a while already. > > And while 52bit support is nice I don't have the hardware to test it so > it is obviously not that useful for me and many other makedumpfile > users. Well the 52-bit changes will still support older CPUs which don't support the 52-bit ARMv8.2 extensions. Also as we discussed in the review of the last version, they will support older kernel + makedumpfile combinations as we need to support them as well. In-fact that would be one of the major changes in the latest respin. However if Kazu is Ok with taking this fix, I have no issues with the same as well. Thanks, Bhupesh _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
