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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171110001315.GA29669@js1304-P5Q-DELUXE>
Date:   Fri, 10 Nov 2017 09:13:16 +0900
From:   Joonsoo Kim <iamjoonsoo.kim@....com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Pavel Machek <pavel@....cz>, pali.rohar@...il.com, sre@...nel.org,
        kernel list <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-omap@...r.kernel.org, khilman@...nel.org,
        aaro.koskinen@....fi, ivo.g.dimitrov.75@...il.com,
        patrikbachan@...il.com, serge@...lyn.com, abcloriens@...il.com,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Russell King <linux@...linux.org.uk>
Subject: Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote:
> * Joonsoo Kim <iamjoonsoo.kim@....com> [171109 03:47]:
> > Could you test following two commits on my updated branch?
> > 
> > "arm/dma: vmalloc area allocation"
> 
> Won't boot at this commit:
> 
> [    6.747283] save_secure_sram() returns 0000ff02
> [    6.751983] save_secure_sram()'s param: 0: 0x4
> [    6.756561] save_secure_sram()'s param: 1: 0x8e700000
> [    6.761749] save_secure_sram()'s param: 2: 0x0
> [    6.766326] save_secure_sram()'s param: 3: 0x1
> [    6.770904] save_secure_sram()'s param: 4: 0x1
> 
> > "arm/dma: defer atomic pool initialization"
> 
> Boots at this commit.
> 
> > I suspect that changed virtual address of the sram due to early
> > __dma_alloc_remap() call causes the problem and above two commits test
> > this theory.
> 
> Hmm OK. Does your first patch above now have the initcall issue too?
> It boots if I make that also subsys_initcall and then I get:

> [    2.078094] vmalloc_pool_init: DMA: get vmalloc area: d0010000

Yes, first patch has the initcall issue and it's intentional in order
to check the theory. I checked following log for this.

- Boot failure
SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
SRAM_ADDR: omap_map_sram: V: 0xd0050000 - 0xd0057000

- Boot success
SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
SRAM_ADDR: omap_map_sram: V: 0xd0008000 - 0xd000f000

When failure, virtual address for sram is higher than normal one due
to vmalloc area allocation in __dma_alloc_remap(). If it is deferred,
virtual address is the same with success case and then the system work.

So, my next theory is that there is n900 specific assumption that sram
should have that address. Could you check if any working tree for n900
which doesn't have my CMA series work or not with adding
"arm/dma: vmalloc area allocation"?

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ