On Wed, Apr 11, 2018 at 07:29:40PM -0500, Kim Phillips wrote:
> On Thu, 12 Apr 2018 08:31:09 +0900
> Namhyung Kim <namhy...@kernel.org> wrote:
> 
> > Hello,
> 
> Hi,
> 
> > On Wed, Apr 11, 2018 at 06:07:52PM -0500, Kim Phillips wrote:
> > > ---
> > > It's not clear to me what the specific intent of the original commit
> > > was, thus the revert.
> > 
> > Hmm.. maybe your kernel map has non-zero start and zero end.  I
> 
> On x86, the first line in /proc/kallsyms is:
> 
> 0000000000000000 A irq_stack_union
> 
> On arm64, it's:
> 
> ffff200008080000 t _head
> 
> Another arm64 box has:
> 
> ffff000008080000 t _head
> 
> (neither have RANDOMIZE_BASE set FWIW)
> 
> > thought it was just from an old or invalid data.  But now I think that
> 
> It would be good to know what that was, yes.
> 
> > overflow can create it..  could you please show me the mmap event?
> > 
> >   $ perf script --show-mmap-events
> 
> Here you go:
> 
>          swapper     0 [000]     0.000000: PERF_RECORD_MMAP -1/0: 
> [0xffff200008080000(0xdffff7f7ffff) @ 0xffff200008080000]: x 
> [kernel.kallsyms]_text

   0xffff200008080000
 +     0xdffff7f7ffff
 --------------------
   0xffffffffffffffff

So it should have ~0ULL of the 'end' already.  I don't know why it
caused the problem..  Was it from the `perf.good`?


>          swapper     0 [000]     0.000000: PERF_RECORD_MMAP -1/0: 
> [0xffff2000021e0000(0x18000) @ 0]: x 
> /lib/modules/4.16.0+/kernel/drivers/bus/arm-ccn.ko

Hmm.. also it seems arm64 loads modules under the kernel.  Then the
fixup logic in machine__create_kernel_maps() won't work.  Also as we
don't use the map_groups__fixup_end() anymore I think it's ok just
checking the end address.

Thanks,
Namhyung

Reply via email to