From: aryabinin@virtuozzo.com (Andrey Ryabinin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area
Date: Mon, 15 Feb 2016 17:28:02 +0300 [thread overview]
Message-ID: <56C1E072.2090909@virtuozzo.com> (raw)
In-Reply-To: <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
On 02/12/2016 07:06 PM, Catalin Marinas wrote:
> On Fri, Feb 12, 2016 at 03:38:46PM +0000, Sudeep Holla wrote:
>>
>> On 12/02/16 15:26, Catalin Marinas wrote:
>>> On Fri, Feb 12, 2016 at 04:17:09PM +0100, Ard Biesheuvel wrote:
>>>> On 12 February 2016 at 16:10, Catalin Marinas <catalin.marinas@arm.com> wrote:
>>>>> On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
>>>>>> On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
>>>>>>> On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
>>>>>>>> This moves the module area to right before the vmalloc area, and
>>>>>>>> moves the kernel image to the base of the vmalloc area. This is
>>>>>>>> an intermediate step towards implementing KASLR, which allows the
>>>>>>>> kernel image to be located anywhere in the vmalloc area.
>>>>>>>>
>>>>>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>>>>>>
>>>>>>> This patch is causing lots of KASAN warnings on Juno (interestingly, it
>>>>>>> doesn't seem to trigger on Seattle, though we only tried for-next/core).
>>>>>>> I pushed the branch that I'm currently using here:
>>>>>>>
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
>>>>>>>
>>>>>>>
>>>>>>> A typical error (though its place varies based on the config options,
>>>>>>> kernel layout):
>>>>>>>
>>>>>>> BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
>>>>>>
>>>>>> Can you confirm that these are stack accesses? I was having similar
>>>>>> errors before, and I ended up creating the kasan zero page patch
>>>>>> because it turned out the kasan shadow page in question was aliased
>>>>>> and the stack writes were occurring elsewhere.
>>>>>
>>>>> It's possible, we are looking into this. Is there any other patch I miss on
>>>>> the above branch?
>>>>
>>>> I don't think so but I will check
>>>
>>> Commit 7b1af9795773 ("arm64: kasan: ensure that the KASAN zero page is
>>> mapped read-only") was merged in -rc2 while the branch above is based on
>>> -rc1. Anyway, I merged it into -rc2 and the errors are similar.
>>>
>>
>> Sorry to add more confusion, but I observed similar KASAN warning
>> with latest mainline(v4.5-rc3+, commit c05235d50f68) with below diff.
>
> I can reproduce this with UBSAN enabled (log below for the record).
>
> So far, we have:
>
> KASAN+for-next/kernmap goes wrong
> KASAN+UBSAN goes wrong
>
> Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
> have to trim for-next/core down until we figure out where the problem
> is.
>
>
> BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
Can it be related to TLB conflicts, which supposed to be fixed in "arm64: kasan: avoid TLB conflicts" patch
from "arm64: mm: rework page table creation" series ?
next prev parent reply other threads:[~2016-02-15 14:28 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 10:54 [PATCH v5sub1 0/8] arm64: split linear and kernel mappings Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 1/8] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 2/8] arm64: add support for ioremap() block mappings Ard Biesheuvel
2016-02-01 14:10 ` Mark Rutland
2016-02-01 14:56 ` Catalin Marinas
2016-02-01 10:54 ` [PATCH v5sub1 3/8] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 4/8] arm64: pgtable: implement static [pte|pmd|pud]_offset variants Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 5/8] arm64: decouple early fixmap init from linear mapping Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 6/8] arm64: kvm: deal with kernel symbols outside of " Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area Ard Biesheuvel
2016-02-01 12:24 ` Catalin Marinas
2016-02-01 12:27 ` Ard Biesheuvel
2016-02-01 13:41 ` Catalin Marinas
2016-02-01 14:32 ` Mark Rutland
2016-02-12 14:58 ` Catalin Marinas
2016-02-12 15:02 ` Ard Biesheuvel
2016-02-12 15:10 ` Catalin Marinas
2016-02-12 15:17 ` Ard Biesheuvel
2016-02-12 15:26 ` Catalin Marinas
2016-02-12 15:38 ` Sudeep Holla
2016-02-12 16:06 ` Catalin Marinas
2016-02-12 16:44 ` Ard Biesheuvel
2016-02-15 14:28 ` Andrey Ryabinin [this message]
2016-02-15 14:35 ` Mark Rutland
2016-02-15 18:59 ` Catalin Marinas
2016-02-16 12:59 ` Andrey Ryabinin
2016-02-16 14:12 ` Mark Rutland
2016-02-16 14:29 ` Mark Rutland
2016-02-16 15:17 ` Ard Biesheuvel
2016-02-16 15:36 ` Andrey Ryabinin
2016-02-16 16:42 ` Mark Rutland
2016-02-17 9:15 ` Andrey Ryabinin
2016-02-17 10:10 ` James Morse
2016-02-17 10:19 ` Catalin Marinas
2016-02-17 10:36 ` Catalin Marinas
2016-02-17 10:18 ` Catalin Marinas
2016-02-17 10:48 ` Mark Rutland
2016-02-17 14:39 ` Mark Rutland
2016-02-17 16:31 ` Andrey Ryabinin
2016-02-17 19:35 ` Mark Rutland
2016-02-17 17:01 ` KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area) Mark Rutland
2016-02-17 17:56 ` Mark Rutland
2016-02-17 19:16 ` Mark Rutland
2016-02-18 8:06 ` Ard Biesheuvel
2016-02-18 8:22 ` KASAN issues with idle / hotplug area Andrey Ryabinin
2016-02-18 8:42 ` Andrey Ryabinin
2016-02-18 9:38 ` Andrey Ryabinin
2016-02-18 11:34 ` Mark Rutland
2016-02-18 9:39 ` Lorenzo Pieralisi
2016-02-18 11:38 ` Mark Rutland
2016-02-18 11:45 ` Andrey Ryabinin
2016-02-18 11:15 ` Mark Rutland
2016-02-18 11:46 ` Andrey Ryabinin
2016-02-18 12:08 ` Mark Rutland
2016-02-12 17:47 ` [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area James Morse
2016-02-12 18:01 ` Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2016-02-01 14:50 ` Mark Rutland
2016-02-01 16:28 ` Fu Wei
2016-02-16 8:55 ` Fu Wei
2016-02-01 15:06 ` Catalin Marinas
2016-02-01 15:13 ` Ard Biesheuvel
2016-02-01 16:31 ` Ard Biesheuvel
2016-02-01 17:31 ` Catalin Marinas
2016-02-01 17:57 ` Ard Biesheuvel
2016-02-01 18:02 ` Catalin Marinas
2016-02-01 18:30 ` [PATCH] arm64: move back to generic memblock_enforce_memory_limit() Ard Biesheuvel
2016-02-02 10:19 ` Catalin Marinas
2016-02-02 10:28 ` Ard Biesheuvel
2016-02-02 10:44 ` Catalin Marinas
2016-02-12 19:45 ` [PATCH v5sub1 0/8] arm64: split linear and kernel mappings Matthias Brugger
2016-02-12 19:47 ` Ard Biesheuvel
2016-02-12 20:10 ` Matthias Brugger
2016-02-12 20:37 ` Ard Biesheuvel
2016-02-13 14:28 ` Ard Biesheuvel
2016-02-15 13:29 ` Matthias Brugger
2016-02-15 13:40 ` Will Deacon
2016-02-15 14:58 ` Ard Biesheuvel
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=56C1E072.2090909@virtuozzo.com \
--to=aryabinin@virtuozzo.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.