lkml.org 
[lkml]   [2022]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[GIT PULL] RAS updates for 5.18
Hi Linus,

please pull the RAS side of things for 5.18.

But before you do, a git question if I may:

So the branch I'm sending you is tip/ras/core and I fast-forwarded it to
v5.17-rc4 before adding new stuff ontop.

However, I needed to have prerequisite work from another tip branch:
tip/locking/core which was fast-forwarded to v5.17-rc1 before it got
that prerequisite work added ontop.

So I merged tip/locking/core into tip/ras/core - see merge commit below
- and added the RAS stuff ontop.

However, when creating the diffstat for the pull request, it would
add additional files to it from tip/locking/core even if all the
tip/locking/core changes are already in your master branch:

$ git log master..tip/locking/core
$

After poking at it a bit more, I found a hint as to what it might be
complaining about:

$ git diff --stat master...ras_core_for_v5.18_rc1
warning: master...ras_core_for_v5.18_rc1: multiple merge bases, using 754e0b0e35608ed5206d6a67a791563c631cec07

and:

$ git merge-base -a master ras_core_for_v5.18_rc1
754e0b0e35608ed5206d6a67a791563c631cec07 - that's rc4
b008893b08dcc8c30d756db05c229a1491bcb992 - that's the top-commit of tip/locking/core at the time the merge commit was created.

So it looks like the diffstat for the pull request is created by using
the -rc4 as the merge base:

$ git diff --stat v5.17-rc4..ras_core_for_v5.18_rc1
...

while the correct diffstat should be from the merge-commit onwards:

$ git diff --stat c0f6799de2a0..ras_core_for_v5.18_rc1
...

So, long story short, what am I doing wrong?

Thx a lot!

---

The following changes since commit 754e0b0e35608ed5206d6a67a791563c631cec07:

Linux 5.17-rc4 (2022-02-13 12:13:30 -0800)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/ras_core_for_v5.18_rc1

for you to fetch changes up to 7f1b8e0d6360178e3527d4f14e6921c254a86035:

x86/mce: Remove the tolerance level control (2022-02-23 11:09:25 +0100)

----------------------------------------------------------------
- More noinstr fixes

- Add an erratum workaround for Intel CPUs which, in certain
circumstances, end up consuming an unrelated uncorrectable memory error
when using fast string copy insns

- Remove the MCE tolerance level control as it is not really needed or
used anymore

----------------------------------------------------------------
Borislav Petkov (3):
Merge tip:locking/core into tip:ras/core
x86/mce: Use arch atomic and bit helpers
x86/mce: Remove the tolerance level control

Jue Wang (1):
x86/mce: Work around an erratum on fast string copy instructions

Auto-merging MAINTAINERS
Auto-merging arch/x86/kernel/cpu/mce/core.c
Merge made by the 'ort' strategy.
Documentation/ABI/removed/sysfs-mce | 37 ++++++++++++++++
Documentation/ABI/testing/sysfs-mce | 32 --------------
Documentation/vm/hwpoison.rst | 2 -
Documentation/x86/x86_64/boot-options.rst | 9 +---
arch/x86/kernel/cpu/mce/core.c | 175 ++++++++++++++++++++++++++++++++++++++++++++-------------------------------
arch/x86/kernel/cpu/mce/internal.h | 31 +++++++++++---
arch/x86/kernel/cpu/mce/severity.c | 23 +++++-----
7 files changed, 177 insertions(+), 132 deletions(-)
create mode 100644 Documentation/ABI/removed/sysfs-mce

--
Regards/Gruss,
Boris.

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

\
 
 \ /
  Last update: 2022-03-23 18:30    [W:0.075 / U:1.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site