[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ab0541ca-a036-34ca-ed1b-937c470cc9da@redhat.com>
Date: Wed, 27 Jun 2018 16:28:04 -0700
From: Laura Abbott <labbott@...hat.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Mark Rutland <mark.rutland@....com>, Kees Cook <keescook@...omium.org>,
Will Deacon <will.deacon@....com>, Catalin Marinas
<catalin.marinas@....com>, James Morse <james.morse@....com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
YaoJun <yaojun8558363@...il.com>
Subject: Re: [RFC PATCH] arm64/mm: unmap the linear alias of module
allocations
On 06/26/2018 06:15 PM, Laura Abbott wrote:
> +static void remap_linear_module_alias(void *module_region, int enable)
> +{
> + struct vm_struct *vm = find_vm_area(module_region);
> + struct page **p;
> + unsigned long size;
> +
> + WARN_ON(!vm || !vm->pages);
> +
> + for (p = vm->pages, size = vm->size; size > 0; size -= PAGE_SIZE)
> + set_memory_valid((u64)page_address(*p++), 1, enable);
> +}
So I think the weirdness is caused by using vm->size here. The size of
the array is actually tracked by vm->nr_pages since vm->size may vary
depending on the guard page. I think this ended being an off by one
error with setting a non-existent page valid, hence the oddness in
the entry. If I switch to using vm->nr_pages, I don't see the entry
anymore.
Thanks,
Laura
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
