Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 8 May 2019 02:38:51 +0300
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
Message-ID: <20190507233849.7z6kqfxitlnp2qtk@mobilestation>
References: <20190503175041.7949-1-fancer.lancer@gmail.com>
 <20190503175041.7949-4-fancer.lancer@gmail.com>
 <20190506191419.w3qtkgcjrjjuzwmu@pburton-laptop>
 <20190507223603.ewuye6lutbb5wz2l@mobilestation>
 <20190507224108.qhoxlyrdvgwayb4k@pburton-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190507224108.qhoxlyrdvgwayb4k@pburton-laptop>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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