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]
Date:   Tue, 16 Mar 2021 22:10:09 -0700
From:   Ilya Lipnitskiy <ilya.lipnitskiy@...il.com>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc:     Tiezhu Yang <yangtiezhu@...ngson.cn>,
        Jinyang He <hejinyang@...ngson.cn>,
        Mike Rapoport <rppt@...nel.org>,
        Youling Tang <tangyouling@...ngson.cn>,
        Tobias Wolf <dev-NTEO@...ace.de>,
        Marcin Nowakowski <marcin.nowakowski@...s.com>,
        linux-mips@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org
Subject: Re: [PATCH] MIPS: fix memory reservation for non-usermem setups

Hi Thomas,

On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer
<tsbogend@...ha.franken.de> wrote:
>
> On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > From: Tobias Wolf <dev-NTEO@...ace.de>
> >
> > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new
> > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is
> > not. As the prerequisite of custom memory map has been removed, this results
> > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this
> > platform.
>
> and where is the problem here ?
Turns out this was already attempted to be upstreamed - not clear why
it wasn't merged. Context:
https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/

I hope the thread above helps you understand the problem.

>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]
Ilya

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ