From: Christoph Hellwig <hch@lst.de> To: Mike Rapoport <rppt@linux.ibm.com> Cc: linux-arch@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexander Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, Guan Xuetao <gxt@pku.edu.cn>, Christoph Hellwig <hch@lst.de>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 7/8] initramfs: proide a generic free_initrd_mem implementation Date: Wed, 13 Feb 2019 19:44:48 +0100 [thread overview] Message-ID: <20190213184448.GB20399@lst.de> (raw) In-Reply-To: <20190213184139.GC15270@rapoport-lnx> On Wed, Feb 13, 2019 at 08:41:40PM +0200, Mike Rapoport wrote: > csky seems to open-code free_reserved_page with the only > difference that it's also increments totalram_pages for the freed pages, > which doesn't seem correct anyway... > > That said, I suppose arch/csky can be also added to the party. Yes, I noticed that. But I'd rather move it over manually in another patch post rc1 or for the next merge window. > > +void __weak free_initrd_mem(unsigned long start, unsigned long end) > > +{ > > + free_reserved_area((void *)start, (void *)end, -1, "initrd"); > > Some architectures have pr_info("Freeing initrd memory..."), I'd add it for > the generic version as well. Well, if we think such a printk is useful it should probably be moved to the caller in init/initramfs.c instead. I can include a patch for that in the next iteration of the series. > Another thing that I was thinking of is that x86 has all those memory > protection calls in its free_initrd_mem, maybe it'd make sense to have them > in the generic version as well? Maybe. But I'd rather keep it out of the initial series as it looks a little more complicated. Having a single implementation of free_initrd_mem would be great, though.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de> To: Mike Rapoport <rppt@linux.ibm.com> Cc: Christoph Hellwig <hch@lst.de>, Andrew Morton <akpm@linux-foundation.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Guan Xuetao <gxt@pku.edu.cn>, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 7/8] initramfs: proide a generic free_initrd_mem implementation Date: Wed, 13 Feb 2019 19:44:48 +0100 [thread overview] Message-ID: <20190213184448.GB20399@lst.de> (raw) Message-ID: <20190213184448.IzmZgiOY2Ja9GM8vkEwXo4301FZRHH9pKOQg9d0zOCM@z> (raw) In-Reply-To: <20190213184139.GC15270@rapoport-lnx> On Wed, Feb 13, 2019 at 08:41:40PM +0200, Mike Rapoport wrote: > csky seems to open-code free_reserved_page with the only > difference that it's also increments totalram_pages for the freed pages, > which doesn't seem correct anyway... > > That said, I suppose arch/csky can be also added to the party. Yes, I noticed that. But I'd rather move it over manually in another patch post rc1 or for the next merge window. > > +void __weak free_initrd_mem(unsigned long start, unsigned long end) > > +{ > > + free_reserved_area((void *)start, (void *)end, -1, "initrd"); > > Some architectures have pr_info("Freeing initrd memory..."), I'd add it for > the generic version as well. Well, if we think such a printk is useful it should probably be moved to the caller in init/initramfs.c instead. I can include a patch for that in the next iteration of the series. > Another thing that I was thinking of is that x86 has all those memory > protection calls in its free_initrd_mem, maybe it'd make sense to have them > in the generic version as well? Maybe. But I'd rather keep it out of the initial series as it looks a little more complicated. Having a single implementation of free_initrd_mem would be great, though.
next prev parent reply other threads:[~2019-02-13 18:44 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-13 17:46 initramfs tidyups Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-13 17:46 ` [PATCH 1/8] mm: unexport free_reserved_area Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-13 17:46 ` [PATCH 2/8] initramfs: free initrd memory if opening /initrd.image fails Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-14 13:51 ` Steven Price 2019-02-14 13:51 ` Steven Price 2019-02-13 17:46 ` [PATCH 3/8] initramfs: cleanup initrd freeing Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-13 17:46 ` [PATCH 4/8] initramfs: factor out a helper to populate the initrd image Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-13 17:46 ` [PATCH 5/8] initramfs: cleanup populate_rootfs Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-13 17:46 ` [PATCH 6/8] initramfs: move the legacy keepinitrd parameter to core code Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-14 16:56 ` Catalin Marinas 2019-02-14 16:56 ` Catalin Marinas 2019-02-13 17:46 ` [PATCH 7/8] initramfs: proide a generic free_initrd_mem implementation Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-13 18:41 ` Mike Rapoport 2019-02-13 18:41 ` Mike Rapoport 2019-02-13 18:44 ` Christoph Hellwig [this message] 2019-02-13 18:44 ` Christoph Hellwig 2019-02-13 21:41 ` Mike Rapoport 2019-02-13 21:41 ` Mike Rapoport 2019-02-14 8:03 ` Geert Uytterhoeven 2019-02-14 8:03 ` Geert Uytterhoeven 2019-02-14 16:20 ` Mike Rapoport 2019-02-14 16:20 ` Mike Rapoport 2019-02-13 17:46 ` [PATCH 8/8] initramfs: poison freed initrd memory Christoph Hellwig 2019-02-13 17:46 ` Christoph Hellwig 2019-02-13 21:54 ` initramfs tidyups Mike Rapoport 2019-02-13 21:54 ` Mike Rapoport
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=20190213184448.GB20399@lst.de \ --to=hch@lst.de \ --cc=akpm@linux-foundation.org \ --cc=catalin.marinas@arm.com \ --cc=gxt@pku.edu.cn \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@armlinux.org.uk \ --cc=rppt@linux.ibm.com \ --cc=viro@zeniv.linux.org.uk \ --cc=will.deacon@arm.com \ /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: linkBe 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).