linux-kernel - Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150311124730.GZ8656@n2100.arm.linux.org.uk>
Date:	Wed, 11 Mar 2015 12:47:30 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash
 on armada-xp

On Wed, Mar 11, 2015 at 03:30:33PM +0300, Stas Sergeev wrote:
> OK, here we go.
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.0.0-rc2-00137-gb672c98-dirty
> (root@...t-010-117) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) )
> #60 SMP5
> [    0.000000] CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7),
> cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
> cache
> [    0.000000] Machine model: Marvell Armada XP Development Board
> DB-MV784MP-GP
> [    0.000000] Ignoring memory block 0x100000000 - 0x200000000
...
> [    0.000000] MEMBLOCK configuration:
> [    0.000000]  memory size = 0xf0000000 reserved size = 0xa32442
> [    0.000000]  memory.cnt  = 0x1
> [    0.000000]  memory[0x0]     [0x00000000000000-0x000000efffffff],
> 0xf0000000 bytes flags: 0x0

So this says you have memory covering that entire range, and actually
beyond to 8GB.

> [    6.772534] vmalloc: mapping page ef7f13c0 (0x000efc1e000) at 0xf00ca000
> [    6.772537] vmalloc: mapping page ef7f13a0 (0x000efc1d000) at 0xf00cb000
> [    6.772540] vmalloc: mapping page ef7f1380 (0x000efc1c000) at 0xf00cc000
> [    6.772542] vmalloc: mapping page ef7f1360 (0x000efc1b000) at 0xf00cd000
> [    6.772544] vmalloc: mapping page ef7f1340 (0x000efc1a000) at 0xf00ce000
> [    6.772546] vmalloc: mapping page ef7f1320 (0x000efc19000) at 0xf00cf000
> [    6.772548] vmalloc: mapping page ef7f1300 (0x000efc18000) at 0xf00d0000
> [    6.772551] vmalloc: mapping page ef7f12e0 (0x000efc17000) at 0xf00d1000
> [    6.822102] ata2: SATA link down (SStatus 0 SControl F300)
> [    6.850381] vmalloc: mapping page ef7f0420 (0x000efba1000) at 0xf00d3000

Here, we set up the mapping, which looks fine - it's apparently in the
range of physical addresses we expect for system memory.

> [    6.857113] vmalloc: mapping page ef7f12c0 (0x000efc16000) at 0xf00d4000
> [    6.863845] vmalloc: mapping page ef7f12a0 (0x000efc15000) at 0xf00d5000
> [    6.870567] Unhandled fault: external abort on non-linefetch (0x808)
> at 0xf00d3018

Yet it causes this.  I wonder if there's a conflict between DRAM and
some other devices causing this, or maybe a stale TLB entry.

The thing which makes me consider a stale TLB entry is that the mapping
we're adding is for a WBWA cacheable mapping, which should cause line
fetches.  The abort which is being raised is for a non-linefetch, a
type of access which a WBWA cacheable mapping should never create.

We can check whether it's a stale TLB entry - if you add a call to
flush_tlb_all() after the call to vmalloc() in n_tty_open().  You
may need to include <asm/tlbflush.h> to make that work - can you try
that please.

Sorry it's needing soo much back-n-forth between us, I don't have 
any Armada platforms which approach the size you have there. :(

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/