From: Peter Zijlstra <peterz@infradead.org>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
David Kaplan <David.Kaplan@amd.com>,
Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@kernel.org>,
x86@kernel.org
Subject: Re: Linux 6.6-rc3 (DEBUG_VIRTUAL is unhappy on x86)
Date: Mon, 2 Oct 2023 12:40:56 +0200 [thread overview]
Message-ID: <20231002104056.GA13957@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAB=+i9QiJ=BXkQuCFJTh3dMXrkKQvVA2EM51Mj6SsDMimWQ71g@mail.gmail.com>
On Sun, Oct 01, 2023 at 11:17:21PM +0900, Hyeonggon Yoo wrote:
> OK, I looked into this a little bit, and it turns out that the problematic
> address here is from cleanup_trusted() in
> security/keys/trusted-keys/trusted_core.c.
> (and it's builtin due to CONFIG_TRUSTED_KEYS=y)
That code is insane.. wth would you want to use an explicit
static_call() in either __init or __exit ?!?
I think the reason we support init was because it was just really hard
to avoid throughout the abstraction layers etc.. But this seems to be
the only __exit user, and it is really quite daft.
> The function is marked as __exit, so it does not fall within the
> 'core kernel text address range,' which is between _stext and _etext
> (or between _sinittext and _einittext). and thus __text_poke() thinks that
> it's vmalloc/module area.
>
> I think __text_poke() should be taught that functions marked as __exit
> also belong to kernel code just like __init.
Should we not do something like:
#ifdef MODULE
#define __exit __section(".exit.text") __exitused __cold notrace
#else
#define __exit __section(".discard.exit.text")
#endif
It's not like that code should ever be ran or referenced when built-in.
next prev parent reply other threads:[~2023-10-02 10:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-24 21:36 Linux 6.6-rc3 Linus Torvalds
2023-09-25 11:32 ` Build regressions/improvements in v6.6-rc3 Geert Uytterhoeven
2023-09-25 11:43 ` Geert Uytterhoeven
2023-09-30 16:26 ` Linux 6.6-rc3 (DEBUG_VIRTUAL is unhappy on x86) Hyeonggon Yoo
2023-10-01 12:24 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-10-08 11:32 ` Linux regression tracking #update (Thorsten Leemhuis)
2023-10-01 14:17 ` Hyeonggon Yoo
2023-10-01 20:48 ` Linus Torvalds
2023-10-03 12:06 ` Sumit Garg
2023-10-03 16:41 ` Peter Zijlstra
2023-10-05 0:46 ` Linus Torvalds
2023-10-05 5:09 ` Sumit Garg
2023-10-02 10:40 ` Peter Zijlstra [this message]
2023-10-05 8:26 ` Hyeonggon Yoo
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=20231002104056.GA13957@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=42.hyeyoo@gmail.com \
--cc=David.Kaplan@amd.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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.