From: "Eric W. Biederman" <ebiederm@xmission.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ming Lei <ming.lei@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: Does anyone actually use KEXEC_JUMP?
Date: Mon, 16 Dec 2024 12:21:01 -0600 [thread overview]
Message-ID: <87bjxbzdyq.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <E64227FF-E6A2-4E2C-85F3-EF1D9EFEC91F@infradead.org> (David Woodhouse's message of "Mon, 16 Dec 2024 18:14:17 +0000")
David Woodhouse <dwmw2@infradead.org> writes:
> It isn't broken. I know of it being used a few million times a week.
>
> There are corner cases which have never worked right, like the callee
> putting a different return address for its next invocation, on the
> stack *above* the address it 'ret's to. Which since the first kjump
> patch has been the first word of the page *after* the swap page (and
> is now fixed in my tree). But fundamentally it *does* work.
>
> I only started messing with it because I was working on
> relocate_kernel() and needed to write a test case for it; the fact
> that I know of it being used in production is actually just a
> coincidence.
Cool. I had the sense that the original developer never got around
to using it, so I figured I should check.
Mind if I ask what you know of it being used for?
I had imagined it might be a way to call firmware code preventing the
need to code of a specific interface for each type of firmware.
Eric
next prev parent reply other threads:[~2024-12-16 18:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 13:39 [PATCH v1] kexec_core: Add and update comments regarding the KEXEC_JUMP flow Rafael J. Wysocki
2024-12-16 13:43 ` David Woodhouse
2024-12-16 16:00 ` Does anyone actually use KEXEC_JUMP? Eric W. Biederman
2024-12-16 18:14 ` David Woodhouse
2024-12-16 18:21 ` Eric W. Biederman [this message]
2024-12-20 7:22 ` Baoquan He
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=87bjxbzdyq.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=dwmw2@infradead.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.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