On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
>
[...]
> > This is passed to iotable_init(), then to create_mapping(). There you
> > have:
> >
> > if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
> > md->virtual >= PAGE_OFFSET &&
> > (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
> > pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of
> > vmalloc space\n",
> > (long long)__pfn_to_phys((u64)md->pfn),
> > md->virtual);
> > }
> >
> > So you must have hit the above warning somehow. Incidentally, this
> > IRQ_STAT entry is the only one that happened to be outside the vmalloc
> > area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning
> > will be gone.
>
> No, there are other legacy platforms which have mappings above that.
... for that particular map_desc array instance I mean.
WRT other legacy platforms: if the above warning didn't bother anyone
for the last 4 years, then it won't be such an issue either if the
current proposal doesn't solve them all. That's not the primary purpose
of this change anyway. In those cases, the appropriate fix, like it is
today, should consist in some adjustment of those virtual addresses to
bring them inside the vmalloc area.
Your original concern was whether extending the vmalloc area upward
would clash with something else, and the short answer is no.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
