[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2203041634040.47558@angie.orcam.me.uk>
Date: Fri, 4 Mar 2022 17:11:44 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
cc: Tiezhu Yang <yangtiezhu@...ngson.cn>,
Mike Rapoport <rppt@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Xuefeng Li <lixuefeng@...ngson.cn>, linux-mips@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem=
parameter
On Fri, 4 Mar 2022, Thomas Bogendoerfer wrote:
> > > With this patch, when add "mem=3G" to the command-line, the
> > > kernel boots successfully, we can see the following messages:
> >
> > unfortunately this patch would break platforms without memory detection,
> > which simply use mem=32M for memory configuration. Not sure how many
> > rely on this mechanism. If we can make sure nobody uses it, I'm fine
> > with your patch.
>
> maybe we could add a CONFIG option, which will be selected by
> platforms, which don't need/want this usermem thing.
FWIW I don't understand what the issue is here beyond that we have a bug
that causes a system to hang when "mem=3G" is passed on the kernel command
line. That is assuming that system does have contiguous RAM available for
the kernel to use from address 0 up to 3GiB; otherwise it's a user error
to tell the kernel it has that memory available (I did get bitten by that
myself too): garbage in, garbage out.
I think having a CONFIG option automatically selected to disable the
ability to give a memory map override would handicap people in debugging
their systems or working around firmware bugs, so I would rather be
against it.
Maciej
Powered by blists - more mailing lists