From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AF64C433FE for ; Sat, 5 Mar 2022 13:14:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA8456B009B; Sat, 5 Mar 2022 08:14:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A57F76B009C; Sat, 5 Mar 2022 08:14:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9470F6B009D; Sat, 5 Mar 2022 08:14:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 84D5D6B009B for ; Sat, 5 Mar 2022 08:14:08 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 459F7203C2 for ; Sat, 5 Mar 2022 13:14:08 +0000 (UTC) X-FDA: 79210375776.04.ED8F1DF Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf23.hostedemail.com (Postfix) with ESMTP id B44C3140005 for ; Sat, 5 Mar 2022 13:14:07 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 629E1B80BE8; Sat, 5 Mar 2022 13:14:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C15F4C004E1; Sat, 5 Mar 2022 13:13:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646486042; bh=AOS5Hc26yUdN2q3VcU3wpupvzKmzfbhIgzFaCkVc7aE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OLoGsRC5Uv+FOxo0IthzzF9n3x3zm8FfELIh8lIUGkruGz7xywD8XFVKziSSuPYPg uXgnQPdOLD9Y2DyEkFjhBSptVYSj3Ck8AcYVjWl8qq1mKkM3pBPy8SKFF/ZJoMyKns GDc6QejZArGAqbQDKyQbKPitJLiq4WBFag0gHsRvJ5DvDCkL6lw2dM3AKkd+eD5P5y du8J9w9EA+jSTmFl9XvvG0t/Uup/F7OqdWB6umBT9XR3kzMuV8XyrwasIDIR3oO73w cI+Ysi0s6+KOtvDArKMt1+ogesT4nBuxXCzaQYMMoVVSfXD94xeXaXC5ZYDInxlOB4 +GM80JCTJ4xvg== Date: Sat, 5 Mar 2022 15:13:54 +0200 From: Mike Rapoport To: "Maciej W. Rozycki" Cc: Thomas Bogendoerfer , Tiezhu Yang , Andrew Morton , Xuefeng Li , linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter Message-ID: References: <1646108941-27919-1-git-send-email-yangtiezhu@loongson.cn> <1646108941-27919-2-git-send-email-yangtiezhu@loongson.cn> <20220304151052.GA27642@alpha.franken.de> <20220304153517.GA28487@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: aj6ueckemn5ix8txtdngwg4eg893bc58 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OLoGsRC5; spf=pass (imf23.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Queue-Id: B44C3140005 X-HE-Tag: 1646486047-627288 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Mar 04, 2022 at 05:11:44PM +0000, Maciej W. Rozycki wrote: > 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. This is exactly the case here because the system does not have contiguous RAM: [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000004000000-0x000000000effffff] [ 0.000000] node 0: [mem 0x0000000090200000-0x00000000ffffffff] [ 0.000000] node 0: [mem 0x0000000120000000-0x00000001653fffff] (from patch 3/4 in this series) I don't see what "bug" this patch is trying to fix. Is indeed possible to make MIPS' mem= behave like it does not arm64 and ppc, but that would break systems that use current semantics and I recall seeing some of OpenWRT machines using mem= to override memory map supplied by firmware. > Maciej -- Sincerely yours, Mike.