linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: torvalds@linux-foundation.org
Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kernel-team@android.com,
	peterz@infradead.org, mark.rutland@arm.com
Subject: [GIT PULL] arm64 fixes for -rc7
Date: Wed, 2 Dec 2020 17:17:51 +0000	[thread overview]
Message-ID: <20201202171750.GA29813@willie-the-truck> (raw)

Hi Linus,

I'm sad to say that we've got an unusually large arm64 fixes pull for
-rc7 which addresses numerous significant instrumentation issues with
our entry code. Without these patches, lockdep is hopelessly unreliable
in some configurations [1,2] and syzkaller is therefore not a lot of use
because it's so noisy. Although much of this has always been broken, it
appears to have been exposed more readily by other changes such as
044d0d6de9f5 ("lockdep: Only trace IRQ edges") and general lockdep
improvements around IRQ tracing and NMIs.

Fixing this properly required moving much of the instrumentation hooks
from our entry assembly into C, which Mark has been working on for the
last few weeks. We're not quite ready to move to the recently added
generic functions yet, but the code here has been deliberately written
to mimic that closely so we can look at cleaning things up once we have
a bit more breathing room.

Having said all that, the second version of these patches was posted
last week and I pushed it into our CI (kernelci and cki) along with a
commit which forced on PROVE_LOCKING, NOHZ_FULL and
CONTEXT_TRACKING_FORCE. The result? We found a real bug in the md/raid10
code [3].

Oh, and there's also a really silly typo patch that's unrelated.

In other words, none of this warrants an -rc8 if you end up considering
it.

Please pull. Cheers,

Will

[1] https://lore.kernel.org/r/CACT4Y+aAzoJ48Mh1wNYD17pJqyEcDnrxGfApir=-j171TnQXhw@mail.gmail.com
[2] https://lore.kernel.org/r/20201119193819.GA2601289@elver.google.com
[3] https://lore.kernel.org/r/94c76d5e-466a-bc5f-e6c2-a11b65c39f83@redhat.com

--->8

The following changes since commit ff1712f953e27f0b0718762ec17d0adb15c9fd0b:

  arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect() (2020-11-23 16:13:18 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes

for you to fetch changes up to 9e5344e0ffc33f4fee899f98b6939a0682b1d9c3:

  arm64: mte: Fix typo in macro definition (2020-11-30 17:36:52 +0000)

----------------------------------------------------------------
arm64 fixes for -rc7

- Fix numerous issues with instrumentation and exception entry

- Fix hideous typo in unused register field definition

----------------------------------------------------------------
Mark Rutland (11):
      arm64: syscall: exit userspace before unmasking exceptions
      arm64: mark idle code as noinstr
      arm64: entry: mark entry code as noinstr
      arm64: entry: move enter_from_user_mode to entry-common.c
      arm64: entry: prepare ret_to_user for function call
      arm64: entry: move el1 irq/nmi logic to C
      arm64: entry: fix non-NMI user<->kernel transitions
      arm64: ptrace: prepare for EL1 irq/rcu tracking
      arm64: entry: fix non-NMI kernel<->kernel transitions
      arm64: entry: fix NMI {user, kernel}->kernel transitions
      arm64: entry: fix EL1 debug transitions

Vincenzo Frascino (1):
      arm64: mte: Fix typo in macro definition

 arch/arm64/include/asm/daifflags.h |   3 +
 arch/arm64/include/asm/exception.h |   5 +
 arch/arm64/include/asm/ptrace.h    |   4 +
 arch/arm64/include/asm/sysreg.h    |   2 +-
 arch/arm64/kernel/entry-common.c   | 254 +++++++++++++++++++++++++++----------
 arch/arm64/kernel/entry.S          |  78 ++++--------
 arch/arm64/kernel/irq.c            |  15 ---
 arch/arm64/kernel/process.c        |   8 +-
 arch/arm64/kernel/sdei.c           |   7 +-
 arch/arm64/kernel/syscall.c        |   1 -
 arch/arm64/kernel/traps.c          |  22 ++--
 arch/arm64/mm/fault.c              |  25 ----
 12 files changed, 243 insertions(+), 181 deletions(-)

             reply	other threads:[~2020-12-02 17:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 17:17 Will Deacon [this message]
2020-12-02 20:48 ` pr-tracker-bot
  -- strict thread matches above, loose matches on Subject: below --
2022-09-23 18:28 Will Deacon
2022-09-23 22:43 ` Linus Torvalds
2022-09-28 10:46   ` Mark Rutland
2022-09-23 22:53 ` pr-tracker-bot
2022-05-13 16:52 Will Deacon
2022-05-13 17:30 ` pr-tracker-bot
2021-08-20  8:53 Will Deacon
2021-08-20 20:09 ` pr-tracker-bot
2020-03-20 15:35 Will Deacon
2020-03-20 17:15 ` pr-tracker-bot
2019-08-28 17:32 [GIT PULL] arm64: Fixes " Will Deacon
2019-08-28 17:45 ` pr-tracker-bot
2018-07-27 11:51 [GIT PULL] arm64: fixes " Will Deacon
2018-05-25 16:04 Will Deacon
2016-07-08 14:49 Will Deacon

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=20201202171750.GA29813@willie-the-truck \
    --to=will@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [GIT PULL] arm64 fixes for -rc7' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).