From: Mike Rapoport <rppt@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [GIT PULL] tracing: Fixes to bootconfig memory management
Date: Fri, 17 Sep 2021 23:10:06 +0300 [thread overview]
Message-ID: <YUT2Hjr0DDA6wnGd@kernel.org> (raw)
In-Reply-To: <CAHk-=wj9k4LZTz+svCxLYs5Y1=+yKrbAUArH1+ghyG3OLd8VVg@mail.gmail.com>
On Tue, Sep 14, 2021 at 11:01:31AM -0700, Linus Torvalds wrote:
> On Tue, Sep 14, 2021 at 7:56 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > A couple of memory management fixes to the bootconfig code
>
> These may be fixes, but they are too ugly to merit the tiny
> theoretical leak fix.
>
> All of these are just plain wrong:
>
> > +static void *init_xbc_data_copy __initdata;
> > +static phys_addr_t init_xbc_data_size __initdata;
> > + init_xbc_data_copy = copy;
> > + init_xbc_data_size = size + 1;
> > + memblock_free(__pa(init_xbc_data_copy), init_xbc_data_size);
>
> because the xbc code already saves these as xbc_data/xbc_data_size and
> that final free should just be done in xbc_destroy_all().
>
> So this fix is pointlessly ugly to begin with.
>
> But what I _really_ ended up reacting to was that
>
> > + memblock_free(__pa(copy), size + 1);
>
> where that "copy" was allocated with
>
> copy = memblock_alloc(size + 1, SMP_CACHE_BYTES);
>
> so it should damn well be free'd without any crazy "__pa()" games.
>
> This is a memblock interface bug, plain and simple.
>
> Mike - this craziness needs to just be fixed. If memblock_alloc()
> returns a virtual address, then memblock_free() should take one.
Yep, it was on my todo list. But since it was like this for years with both
memblock and bootmem I didn't prioritise this.
> Let's just get these interfaces fixed. It might be as simple as having
> a "memblock_free_phys()" interface, and doing a search-and-replace
> with coccinelle of
>
> memblock_free(__pa(xyz), .. -> memblock_free(xyz, ...
> memblock_free(other, .. -> memblock_free_phys(other, ..
>
> and adding the (trivial) internal helper functions to memblock,
> instead of making the atcual _users_ of memblock do insanely stupid
> and confusing things.
I've done the automated search and replace, with several fixups here and
there, so there is now memblock_phys_free(phys_addr_t addr) to match
memblock_phys_alloc() and memblock_free(void *ptr) to match
memblock_alloc().
The initial version is in memblock tree
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock.git/log/?h=memblock_free-cleanup/v0
I'm waiting for robots to run the builds before posting.
While doing the replacement I've found one mismatch in Xen code which used
memblock_free() to free a virtual pointer, but except that users seem to do
the correct thing, even if it is ugly __pa() conversions.
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2021-09-17 20:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 14:56 [GIT PULL] tracing: Fixes to bootconfig memory management Steven Rostedt
2021-09-14 18:01 ` Linus Torvalds
2021-09-14 18:59 ` Steven Rostedt
2021-09-14 19:05 ` Linus Torvalds
2021-09-14 19:14 ` Steven Rostedt
2021-09-14 19:23 ` Linus Torvalds
2021-09-14 19:38 ` Linus Torvalds
2021-09-14 20:48 ` Linus Torvalds
2021-09-14 21:05 ` Steven Rostedt
2021-09-14 22:47 ` Vlastimil Babka
2021-09-14 23:29 ` Linus Torvalds
2021-09-15 9:28 ` Vlastimil Babka
2021-09-14 23:44 ` Masami Hiramatsu
2021-09-17 20:10 ` Mike Rapoport [this message]
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=YUT2Hjr0DDA6wnGd@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.