linux-kernel - RE: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.

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] [day] [month] [year] [list]

Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024CF13FC0@dbde02.ent.ti.com>
Date:	Tue, 17 May 2011 23:55:01 +0530
From:	"Nori, Sekhar" <nsekhar@...com>
To:	Ben Gardiner <bengardiner@...ometrics.ca>,
	Subhasish Ghosh <subhasish@...tralsolutions.com>
CC:	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"sachi@...tralsolutions.com" <sachi@...tralsolutions.com>,
	Russell King <linux@....linux.org.uk>,
	Kevin Hilman <khilman@...prootsystems.com>,
	open list <linux-kernel@...r.kernel.org>,
	"Watkins, Melissa" <m-watkins@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.

On Tue, May 17, 2011 at 00:38:21, Ben Gardiner wrote:
> Hi Subhasish and Sekhar,
> 
> Subhashish, I was testing your patch here while investigating
> davinci-pcm ping-pong buffers on da850.
> 
> On Fri, Feb 11, 2011 at 9:21 AM, Subhasish Ghosh
> <subhasish@...tralsolutions.com> wrote:
> > This patch modifies the sram allocator to allocate memory
> > from the DA8XX shared RAM.
> >
> > Signed-off-by: Subhasish Ghosh <subhasish@...tralsolutions.com>
> > ---
> >  arch/arm/mach-davinci/da850.c              |    6 +++---
> >  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
> 
> Since this changes only the da850 behaviour, a subject prefix of da850
> might be more appropriate than 'davinci'.

Please use "davinci: da850: ..."

> 
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> > index 3443d97..8a4de97 100644
> > --- a/arch/arm/mach-davinci/da850.c
> > +++ b/arch/arm/mach-davinci/da850.c
> > @@ -711,7 +711,7 @@ static struct map_desc da850_io_desc[] = {
> >        },
> >        {
> >                .virtual        = SRAM_VIRT,
> > -               .pfn            = __phys_to_pfn(DA8XX_ARM_RAM_BASE),
> > +               .pfn            = __phys_to_pfn(DA8XX_SHARED_RAM_BASE),
> >                .length         = SZ_8K,
> 
> Assigning only 8K to this iomap will result in a fault for the first
> victim to access SRAM_VIRT+0x2000. This will happen for example with
> mcasp ping-pong buffers totalling more than 8K on the da850.
> 
> Unfortunately SZ_128K cannot be used here since it will cause a panic

Okay, I am seeing this too. Kernel panics after freeing init memory.
No idea on this one, needs to be debugged.

Freeing init memory: 136K
Kernel panic - not syncing: Attempted to kill init!
[<c002f094>] (unwind_backtrace+0x0/0xec) from [<c024bf7c>] (panic+0x5c/0x184)
[<c024bf7c>] (panic+0x5c/0x184) from [<c00427dc>] (do_exit+0xb4/0x6c4)
[<c00427dc>] (do_exit+0xb4/0x6c4) from [<c0042ea4>] (do_group_exit+0xb8/0xe8)
[<c0042ea4>] (do_group_exit+0xb8/0xe8) from [<c004eaa4>] (get_signal_to_deliver+0x398/0x3f4)
[<c004eaa4>] (get_signal_to_deliver+0x398/0x3f4) from [<c002ca7c>] (do_notify_resume+0x60/0x610)
[<c002ca7c>] (do_notify_resume+0x60/0x610) from [<c002afd4>] (work_pending+0x24/0x28)

> on boot. SZ_64K works though.

Right.

> 
> >                .type           = MT_DEVICE
> >        },
> > @@ -1083,8 +1083,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
> >        .gpio_irq               = IRQ_DA8XX_GPIO0,
> >        .serial_dev             = &da8xx_serial_device,
> >        .emac_pdata             = &da8xx_emac_pdata,
> > -       .sram_dma               = DA8XX_ARM_RAM_BASE,
> > -       .sram_len               = SZ_8K,
> > +       .sram_dma               = DA8XX_SHARED_RAM_BASE,
> > +       .sram_len               = SZ_128K,
> 
> This should probably be set to match whatever is reported in the map

You are right, the two sizes should match.

> entry above -- or an ioremap could be issued later but before the sram
> init?

Yes, ioremap would be better. I am not sure why a fixed mapping
for SRAM is required.

Please base these patches on Russell's SRAM consolidation patch.

Thanks,
Sekhar

--
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/