linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Serge Semin <fancer.lancer@gmail.com>
To: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	James Hogan <jhogan@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Bogendoerfer <tbogendoerfer@suse.de>,
	Huacai Chen <chenhc@lemote.com>, Stefan Agner <stefan@agner.ch>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Juergen Gross <jgross@suse.com>,
	Serge Semin <Sergey.Semin@t-platforms.ru>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging
Date: Wed, 8 May 2019 02:38:51 +0300	[thread overview]
Message-ID: <20190507233849.7z6kqfxitlnp2qtk@mobilestation> (raw)
In-Reply-To: <20190507224108.qhoxlyrdvgwayb4k@pburton-laptop>

On Tue, May 07, 2019 at 10:41:10PM +0000, Paul Burton wrote:
> Hi Serge,
> 
> On Wed, May 08, 2019 at 01:36:07AM +0300, Serge Semin wrote:
> > Thanks for the report regarding this issue. I actually thought I
> > tested the patch being buildable for 64bit systems. It turns out I
> > didn't.(
> 
> Easily done :)
> 
> > Should I resend the fixed patch as a separate v3 one In-Reply-to this
> > v2 patch or resubmit the patchset with cover-letter and only the fixed
> > patch being there?
> 
> Replying with just v3 of this patch will be fine, no need to resend the
> cover letter.
> 

Ok. I've just submitted the v3 version with fixed buildability problem.

> I currently plan to submit a pull request for mips-next as-is, without
> this patch, in the next day or two. There are a few last minute
> submissions this time round that I'll then queue up & send a second pull
> request next week, which this can be part of.
> 
> Thanks,
>     Paul

Regarding this patch being part of the mips mm init code. I've just found out
that 32-bit arm subsystem maintainers removed the same functionality from the
kernel 5.1. This also was removed from arm64 in kernel 4.15:
commit 1c31d4e96b8c ("ARM: 8820/1: mm: Stop printing the virtual memory layout")
commit 071929dbdd86 ("arm64: Stop printing the virtual memory layout")

Maintainer of m68k and unicore32 discarded the printing as well:
commit 1476ea250cf0 ("unicore32: stop printing the virtual memory layout")
commit 31833332f798 ("m68k/mm: Stop printing the virtual memory layout")

The reasoning of these removal was that since commit ad67b74d2469 ("printk:
hash addresses printed with %p") the kernel virtual addresses weren't
printed to the system log anyway. So instead of replacing the format string with
"%px" they decided not to leak a virtual memory layout information and completely
removed the printing. I don't really know why they didn't closed the printing for
debug kernel only as we did, since the info might be useful in this case.

Since I see a tendency of this functionality removal, we might need to
reconsider this patch integration into the MIPS arch code. What do you think?

Although some architectures still perform the virtual memory layout printing
at boot-time: x86_32, parisc, xtensa, sh, nds32 (might be others).

Cheers,
-Sergey

  reply	other threads:[~2019-05-07 23:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-03 17:50 [PATCH v2 0/5] mips: Post-bootmem-memblock transition fixes Serge Semin
2019-05-03 17:50 ` [PATCH v2 1/5] mips: Dump memblock regions for debugging Serge Semin
2019-05-06 19:11   ` Paul Burton
2019-05-03 17:50 ` [PATCH v2 2/5] mips: Perform early low memory test Serge Semin
2019-05-06 19:11   ` Paul Burton
2019-05-03 17:50 ` [PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging Serge Semin
2019-05-06 19:14   ` Paul Burton
2019-05-07 22:36     ` Serge Semin
2019-05-07 22:41       ` Paul Burton
2019-05-07 23:38         ` Serge Semin [this message]
2019-06-17 13:39           ` Serge Semin
2019-05-07 23:03   ` [PATCH v3] " Serge Semin
2019-05-03 17:50 ` [PATCH v2 4/5] mips: Make sure dt memory regions are valid Serge Semin
2019-05-06 19:12   ` Paul Burton
2019-05-03 17:50 ` [PATCH v2 5/5] mips: Manually call fdt_init_reserved_mem() method Serge Semin
2019-05-06 19:12   ` Paul Burton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190507233849.7z6kqfxitlnp2qtk@mobilestation \
    --to=fancer.lancer@gmail.com \
    --cc=Sergey.Semin@t-platforms.ru \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=chenhc@lemote.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgross@suse.com \
    --cc=jhogan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    --cc=rppt@linux.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=stefan@agner.ch \
    --cc=tbogendoerfer@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).