From: Alexander Potapenko <glider@google.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: Calling vmalloc_to_page() on ioremap memory?
Date: Mon, 25 Jun 2018 18:24:57 +0200 [thread overview]
Message-ID: <CAG_fn=XKo6nDphugt6wJSfA3qXGDkGDzd302kRSW6jdD4XNMvQ@mail.gmail.com> (raw)
In-Reply-To: <20180625160040.di75264empbcf6xz@lakrids.cambridge.arm.com>
On Mon, Jun 25, 2018 at 6:00 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Mon, Jun 25, 2018 at 04:59:23PM +0200, Alexander Potapenko wrote:
> > Hi Ard, Mark, Andrew and others,
> >
> > AFAIU, commit 029c54b09599573015a5c18dbe59cbdf42742237 ("mm/vmalloc.c:
> > huge-vmap: fail gracefully on unexpected huge vmap mappings") was
> > supposed to make vmalloc_to_page() return NULL for pointers not
> > returned by vmalloc().
>
> It's a little more subtle than that -- avoiding an edge case where we
> unexpectedly hit huge mappings, rather than determining whether an
> address same from vmalloc().
Ok, but anyway, acpi_os_ioremap() creates a huge page mapping via
__ioremap_caller() (see
https://elixir.bootlin.com/linux/latest/source/arch/x86/mm/ioremap.c#L133)
Shouldn't these checks detect that as well?
> > For memory error detection purposes I'm trying to map the addresses
> > from the vmalloc range to valid struct pages, or at least make sure
> > there's no struct page for a given address.
> > Looking up the vmap_area_root rbtree isn't an option, as this must be
> > done from instrumented code, including interrupt handlers.
>
> I'm not sure how you can do this without looking at VMAs.
>
> In general, the vmalloc area can contain addresses which are not memory,
> and this cannot be detremined from the address alone.
I thought this was exactly what vmalloc_to_page() did, but apparently no.
> You *might* be able to get away with pfn_valid(vmalloc_to_pfn(x)), but
> IIRC there's some disagreement on the precise meaning of pfn_valid(), so
> that might just tell you that the address happens to fall close to some
> valid memory.
This appears to work, at least for ACPI mappings. I'll check other cases though.
Thank you!
> Thanks,
> Mark.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
next prev parent reply other threads:[~2018-06-25 16:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-25 14:59 Alexander Potapenko
2018-06-25 15:37 ` Ard Biesheuvel
2018-06-25 16:07 ` Alexander Potapenko
2018-06-25 16:18 ` Ard Biesheuvel
2018-06-25 16:00 ` Mark Rutland
2018-06-25 16:24 ` Alexander Potapenko [this message]
2018-06-25 16:27 ` Mark Rutland
2018-06-26 10:00 ` Alexander Potapenko
2018-06-26 12:10 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAG_fn=XKo6nDphugt6wJSfA3qXGDkGDzd302kRSW6jdD4XNMvQ@mail.gmail.com' \
--to=glider@google.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox