From: Borislav Petkov <bp@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: [GIT PULL (not really)] x86/core for v5.16
Date: Mon, 1 Nov 2021 11:25:28 +0100 [thread overview]
Message-ID: <YX/AmFgkQ0AEqDaG@zn.tnic> (raw)
Hi Linus,
so this is not really a pull request but more of a question on the
process. I have merged the x86/cc branch into this branch I'm sending to
you - x86/core - and when I generate the diffstat with git request-pull,
it adds the changes of the merged branch x86/cc too, of course.
I can doctor the diffstat and the merge message by doing
git diff --stat ^x86/cc x86_core_for_v5.16_rc1
see below, so that the merged branch's changes are not there.
But I'm not sure if this is the right thing to do. Especially if you do
not merge x86/cc first - then the below diffstat becomes wrong.
So what I've been doing with cases like that in the past is to wait
until you merge the dependent branch and then to create the proper
diffstat and pull message.
And I'm going to do it this way too but thought that maybe I should ask
if there is an alternative accepted way which I could do in the future
too, without having to wait.
Thx.
---
The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f:
Linux 5.15-rc1 (2021-09-12 16:28:37 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_core_for_v5.16_rc1
for you to fetch changes up to a72fdfd21e01c626273ddcf5ab740d4caef4be54:
selftests/x86/iopl: Adjust to the faked iopl CLI/STI usage (2021-10-30 23:18:04 +0200)
----------------------------------------------------------------
- Do not #GP on userspace use of CLI/STI but pretend it was a NOP to
keep old userspace from breaking. Adjust the corresponding iopl selftest
to that.
- Improve stack overflow warnings to say which stack got overflowed and
raise the exception stack sizes to 2 pages since overflowing the single
page of exception stack is very easy to do nowadays with all the tracing
machinery enabled. With that, rip out the custom mapping of AMD SEV's
too.
- A bunch of changes in preparation for FGKASLR like supporting more
than 64K section headers in the relocs tool, correct ORC lookup table
size to cover the whole kernel .text and other adjustments.
----------------------------------------------------------------
Borislav Petkov (3):
Merge branch x86/cc into x86/core
x86/sev: Make the #VC exception stacks part of the default stacks storage
selftests/x86/iopl: Adjust to the faked iopl CLI/STI usage
Kees Cook (2):
x86/boot: Allow a "silent" kaslr random byte fetch
x86/boot/compressed: Avoid duplicate malloc() implementations
Kristen Carlson Accardi (2):
x86/tools/relocs: Support >64K section headers
vmlinux.lds.h: Have ORC lookup cover entire _etext - _stext
Peter Zijlstra (3):
x86/iopl: Fake iopl(3) CLI/STI usage
x86/mm/64: Improve stack overflow warnings
x86: Increase exception stack sizes
arch/x86/boot/compressed/kaslr.c | 4 --
arch/x86/boot/compressed/misc.c | 3 +
arch/x86/boot/compressed/misc.h | 2 +
arch/x86/include/asm/cpu_entry_area.h | 8 ++-
arch/x86/include/asm/insn-eval.h | 1 +
arch/x86/include/asm/irq_stack.h | 37 ++++++++----
arch/x86/include/asm/page_64_types.h | 2 +-
arch/x86/include/asm/processor.h | 1 +
arch/x86/include/asm/stacktrace.h | 10 ++++
arch/x86/include/asm/traps.h | 6 +-
arch/x86/kernel/dumpstack_64.c | 6 ++
arch/x86/kernel/process.c | 1 +
arch/x86/kernel/sev.c | 32 -----------
arch/x86/kernel/traps.c | 58 +++++++++++++++----
arch/x86/lib/insn-eval.c | 2 +-
arch/x86/lib/kaslr.c | 18 ++++--
arch/x86/mm/cpu_entry_area.c | 7 +++
arch/x86/mm/fault.c | 20 +++----
arch/x86/tools/relocs.c | 103 +++++++++++++++++++++++++---------
include/asm-generic/vmlinux.lds.h | 3 +-
include/linux/decompress/mm.h | 12 +++-
tools/testing/selftests/x86/iopl.c | 78 ++++++++++++++++++-------
22 files changed, 284 insertions(+), 130 deletions(-)
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg
next reply other threads:[~2021-11-01 10:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 10:25 Borislav Petkov [this message]
2021-11-01 21:16 ` Linus Torvalds
2021-11-02 5:22 ` Borislav Petkov
2021-11-02 5:48 ` [GIT PULL] " Borislav Petkov
2021-11-02 15:07 ` [GIT PULL (not really)] " pr-tracker-bot
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=YX/AmFgkQ0AEqDaG@zn.tnic \
--to=bp@suse.de \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®