[GIT PULL (not really)] x86/core for v5.16

[GIT PULL (not really)] x86/core for v5.16

[Borislav Petkov]

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

Re: [GIT PULL (not really)] x86/core for v5.16

[Linus Torvalds]

On Mon, Nov 1, 2021 at 3:25 AM Borislav Petkov <bp@suse.de> wrote:
>
> 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 other developers do this kind of thing fairly regularly, because
they have some "core branch" that does the basic core development
(say, a driver subsystem), and then they have other branches (eg the
lowlevel drivers themselves etc) that depended on the core work but
are sent as individual pull requests to keep the conceptual separation
alive, and make it easier to review.

The way to do it tends to be:

 (a) make it clear that some pull request depends on a previous one,
so that I'm aware of it, and don't do them out of order and get
confused

 (b) when you have a series of pull requests that aren't independent,
create the series of pulls yourself in a temporary tree, and generate
the pull request from that series, with the previous merge always as
the "base".

The reason for (a) is obvious, and the reason for (b) is that then
each pull request automatically gets the right shortlog and diffstat.

Of course, if this is the only time you expect to haev this kind of
dependency, you don't need to have much of a process in place, and a
hacky manual one-time thing like the above works fine too.

And in general, the more independent the pull request can be, the
better. But having two or more branches that have some serial
dependency certainly isn't unheard of or wrong either.  It happens.

             Linus

Re: [GIT PULL (not really)] x86/core for v5.16

[Borislav Petkov]

On Mon, Nov 01, 2021 at 02:16:24PM -0700, Linus Torvalds wrote:
> So other developers do this kind of thing fairly regularly, because
> they have some "core branch" that does the basic core development
> (say, a driver subsystem), and then they have other branches (eg the
> lowlevel drivers themselves etc) that depended on the core work but
> are sent as individual pull requests to keep the conceptual separation
> alive, and make it easier to review.

Right, exactly.

> The way to do it tends to be:
> 
>  (a) make it clear that some pull request depends on a previous one,
> so that I'm aware of it, and don't do them out of order and get
> confused

Ok.
 
>  (b) when you have a series of pull requests that aren't independent,
> create the series of pulls yourself in a temporary tree, and generate
> the pull request from that series, with the previous merge always as
> the "base".

Ah ok, that sounds good.

> The reason for (a) is obvious, and the reason for (b) is that then
> each pull request automatically gets the right shortlog and diffstat.
> 
> Of course, if this is the only time you expect to haev this kind of
> dependency, you don't need to have much of a process in place, and a
> hacky manual one-time thing like the above works fine too.

Yeah, it does happen but not too often. With tip, the usual situation
is one branch does change/add something which is needed elsewhere and a
merge is needed. Basically the case you described above.

> And in general, the more independent the pull request can be, the
> better. But having two or more branches that have some serial
> dependency certainly isn't unheard of or wrong either.  It happens.

Yeah.

Ok, thanks for explaining.

/me writes this down for the future.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

[GIT PULL] x86/core for v5.16

[Borislav Petkov]

On Mon, Nov 01, 2021 at 02:16:24PM -0700, Linus Torvalds wrote:
>  (b) when you have a series of pull requests that aren't independent,
> create the series of pulls yourself in a temporary tree, and generate
> the pull request from that series, with the previous merge always as
> the "base".

And doing the pull request message now, it looks like I could have
simply used as the <start> point in the invocation of

$ git request-pull [-p] <start> <url> [<end>]

the merged branch. I.e., usually I do:

$ git request-pull master tip x86_core_for_v5.16_rc1

i.e., master up to the tag and doing

$ git request-pull tip/x86/cc tip x86_core_for_v5.16_rc1

where tip/x86/cc is the branch which had to be merged into x86/core,
gives the exact same diffstat etc...

Now, with that out of the way, you can finally please pull the x86/core
updates for 5.16.

Btw, there's a small merge conflict with your tree, resolution at the
end of this mail, courtesy of Ingo.

Thanks!

---

The following changes since commit e9d1d2bb75b2d5d4b426769c5aae0ce8cef3558f:

  treewide: Replace the use of mem_encrypt_active() with cc_platform_has() (2021-10-04 11:47:24 +0200)

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(-)


Merge conflict resolution:

---
commit 67ec0b0f87d0c5886006cb2b00b7c82eeab8c004
Merge: edfb8366b13b 2258a6fc33d5
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Nov 1 10:19:22 2021 +0100

    Merge branch 'irq/core'
    
    Conflicts:
            arch/x86/include/asm/irq_stack.h

diff --cc arch/x86/include/asm/irq_stack.h
index e23a7868c6d2,ea0c5ab31da4..ae9d40f6c706
--- a/arch/x86/include/asm/irq_stack.h
+++ b/arch/x86/include/asm/irq_stack.h
@@@ -201,6 -185,10 +201,7 @@@
  			      IRQ_CONSTRAINTS, regs, vector);		\
  }
  
+ #ifndef CONFIG_PREEMPT_RT
 -#define ASM_CALL_SOFTIRQ						\
 -	"call %P[__func]				\n"
 -
  /*
   * Macro to invoke __do_softirq on the irq stack. This is only called from
   * task context when bottom halves are about to be reenabled and soft

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

Re: [GIT PULL (not really)] x86/core for v5.16

[pr-tracker-bot]

The pull request you sent on Mon, 1 Nov 2021 11:25:28 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_core_for_v5.16_rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cc0356d6a02e064387c16a83cb96fe43ef33181e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html