Hi Madhavan,
As Mark Brown says, I think this needs to be split into several
patches. i have some comments on the general approach, but I'll save
in-depth review until this has been split.
On Tue, Feb 23, 2021 at 12:12:43PM -0600, madve...@linux.microsoft.com wrote:
> From: "Madhavan T.
On Tue, Feb 23, 2021 at 02:39:11AM +0900, Hector Martin wrote:
> On 20/02/2021 03.26, Mark Rutland wrote:
> > On Sat, Feb 20, 2021 at 02:25:30AM +0900, Hector Martin wrote:
> > > Apple SoCs (A11 and newer) have some interrupt sources hardwired to the
> > > FIQ
On Mon, Feb 22, 2021 at 11:43:13AM +, Marc Zyngier wrote:
> On 2021-02-22 11:25, Mark Rutland wrote:
> > On Mon, Feb 22, 2021 at 10:48:11AM +, Marc Zyngier wrote:
> > > On 2021-02-22 09:59, Mark Rutland wrote:
> > > > On Fri, Feb 19, 2021 at 11:39:
On Mon, Feb 22, 2021 at 10:48:11AM +, Marc Zyngier wrote:
> On 2021-02-22 09:59, Mark Rutland wrote:
> > On Fri, Feb 19, 2021 at 11:39:01AM +0000, Mark Rutland wrote:
> > > +void (*handle_arch_irq)(struct pt_regs *) __ro_after_init =
> > > default_handle_ir
On Fri, Feb 19, 2021 at 11:39:01AM +, Mark Rutland wrote:
> If we accidentally unmask IRQs before we've registered an IRQ
> controller, handle_arch_irq will be NULL, and the IRQ exception handler
> will branch to a bogus address.
>
> To make this easier to debug, this pa
//git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/fiq
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/fiqA
Thanks,
Mark.
>
> Signed-off-by: Hector Martin
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: James Morse
> Cc: Marc Z
On Fri, Feb 19, 2021 at 03:37:25PM +, Joey Gouly wrote:
> Hi Mark,
>
> On Fri, Feb 19, 2021 at 11:39:04AM +0000, Mark Rutland wrote:
> > On contemporary platforms we don't use FIQ, and treat any stray FIQ as a
> > fatal event. However, some platforms have an inter
On Sat, Feb 20, 2021 at 12:41:01AM +0900, Hector Martin wrote:
> Hi Mark,
>
> Thanks for tackling this side of the problem!
No problem -- I have a vested interest in the arm64 exception management
code lookin the way I expect/prefer! ;)
> On 19/02/2021 20.38, Mark Rutland wrote:
&g
to that handler.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Marc Zyngier
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch/arm64/include/asm/irq.h | 1 +
arch/arm64/kernel/entry.S| 26 ++
arch/arm64/kernel/irq.c | 15
-off-by: Hector Martin
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: James Morse
Cc: Marc Zyngier
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch/arm64/include/asm/assembler.h | 6 +++---
arch/arm64/include/asm/daifflags.h | 4 ++--
arch/arm64/include/asm/irqflags.h | 19
to the macros.
There should be no functional change as a result of this patch.
Signed-off-by: Marc Zyngier
[Mark: rework macros, commit message, rebase before DAIF rework]
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch
easier to
debug. When we add support for FIQ handlers, we can follow the same
approach.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Marc Zyngier
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch/arm64/kernel/irq.c | 11 ---
1 file changed, 8
for the
former.
This patch adds an arm64-specific implementation of set_handle_irq().
There should be no functional change as a result of this patch.
Signed-off-by: Marc Zyngier
[Mark: use a single handler pointer]
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc
by allowing architectures to provide their own
implementation of set_handle_irq when CONFIG_GENERIC_IRQ_MULTI_HANDLER
is not selected.
Signed-off-by: Marc Zyngier
[Mark: expand commit message]
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
.
Reported-by: Marc Rutland
Signed-off-by: Marc Zyngier
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index
-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20210217142800.2547737-1-...@kernel.org
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
Cc: Will Deacon
---
drivers/irqchip/Kconfig | 9 -
1 file changed, 9 deletions(-)
diff
into macros
Mark Rutland (2):
arm64: irq: add a default handle_irq panic function
arm64: irq: allow FIQs to be handled
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 -
arch/arm64/include/asm/assembler.h | 6 +--
arch/arm64/include/asm/daifflags.h | 4
On Thu, Feb 18, 2021 at 11:42:01PM +0900, Hector Martin wrote:
> On 18/02/2021 23.22, Mark Rutland wrote:
> > I think that for consistency we always want to keep IRQ and FIQ in-sync,
> > even when using GIC priorities. So when handling a pseudo-NMI we should
> > unmask DAIF
On Mon, Feb 15, 2021 at 09:16:48PM +0900, Hector Martin wrote:
> This series brings up initial support for the Apple M1 SoC, used in the
> 2020 Mac Mini, MacBook Pro, and MacBook Air models.
>
> The following features are supported in this initial port:
>
> - UART (samsung-style) with earlycon
On Thu, Feb 18, 2021 at 09:51:40PM +0900, Hector Martin wrote:
> On 17/02/2021 21.22, Mark Rutland wrote:
> > > Root irqchip drivers can discriminate between IRQs and FIQs by checking
> > > the ISR_EL1 system register.
> >
> > I think we can remove this not
Hi Hector,
On Mon, Feb 15, 2021 at 09:16:56PM +0900, Hector Martin wrote:
> Apple SoCs (A11 and newer) have some interrupt sources hardwired to the
> FIQ line. We implement support for this by simply treating IRQs and FIQs
> the same way in the interrupt vectors.
>
> To support these systems,
Hi Hector,
On Mon, Feb 15, 2021 at 09:16:57PM +0900, Hector Martin wrote:
> From: Marc Zyngier
>
> By default, FIQ exceptions trigger a panic. On platforms that need to
> deliver interrupts via FIQ, this gets redirected via an alternative to
> instead handle FIQ the same way as IRQ. It is up to
On Fri, Feb 12, 2021 at 04:24:35PM +, Amanieu d'Antras wrote:
> On Fri, Feb 12, 2021 at 1:28 PM Catalin Marinas
> wrote:
> > The only downside I think is that for some syscalls it's not that
> > efficient. Those using struct iovec come to mind, qemu probably
> > duplicates the user
On Thu, Feb 11, 2021 at 12:21:54PM -0800, sonicadvan...@gmail.com wrote:
> From: Ryan Houdek
>
> Sorry about the noise. I obviously don't work in this ecosystem.
> Didn't get any comments previously so I'm resending
>
> The problem:
> We need to support 32-bit processes running under a
On Tue, Feb 09, 2021 at 05:03:46PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 09, 2021 at 01:24:30PM +0000, Mark Rutland wrote:
> > On Tue, Feb 09, 2021 at 09:34:10AM +0100, Peter Zijlstra wrote:
> > >
> > > Subject: lockdep: Noinstr annotate warn_bogus_irq_restore()
tra (Intel)
Whoops; sorry for missing that!
Acked-by: Mark Rutland
Mark.
> ---
> include/linux/irqflags.h |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> --- a/include/linux/irqflags.h
> +++ b/include/linux/irqflags.h
> @@ -153,8 +15
On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote:
> On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote:
> > > >> Thus far we've been able to successfully reverse engineer it on x86,
> > > >> though it hasn't been easy.
> > > >>
> > > >> There were some particulars for
add support for Cortex-A78
> dt-bindings: arm: add Cortex-A78 binding
Both patches look good to me:
Acked-by: Mark Rutland
Will, I assume you'll pick this up.
Mark
>
> Documentation/devicetree/bindings/arm/pmu.yaml | 1 +
> arch/arm64/kernel/perf_event.c
... which more clearly justifies the change.
The patch itself looks sane to me (and the unary operator cleanup is
certianly nice), so with that wording:
Acked-by: Mark Rutland
Thanks,
Mark.
> ---
> arch/arm64/kernel/alternative.c | 2 +-
> arch/arm64/kernel/module-plts.c | 2 +-
&g
On Wed, Feb 03, 2021 at 01:19:12PM +0800, Zhiyuan Dai wrote:
> Fixed two coding style issues in kernel/trap.c
> 1. spaces required around that '='
This change makes sense to me as a cleanup.
> 2. Missing a blank line after declarations
We're inconsistent w.r.t. this across the tree, and
On Wed, Feb 03, 2021 at 09:26:45AM +0100, Julien Thierry wrote:
> On 2/2/21 11:17 AM, Mark Rutland wrote:
> > On Wed, Jan 20, 2021 at 06:17:41PM +0100, Julien Thierry wrote:
> > > Aarch64 instruction set encoding and decoding logic can prove useful
> > > for so
Hi,
On Tue, Feb 02, 2021 at 08:54:23AM -0800, sonicadvan...@gmail.com wrote:
> From: Ryan Houdek
>
> This is a continuation of https://lkml.org/lkml/2021/1/6/47
> This patch is currently based against a 5.10 kernel but rebasing against
> latest HEAD is trivial
>
> Specifically Amanieu pointed
On Wed, Jan 20, 2021 at 06:17:43PM +0100, Julien Thierry wrote:
> Create necessary functions to encode/decode aarch64 data/instruction
> barriers.
>
> Signed-off-by: Julien Thierry
> ---
> arch/arm64/include/asm/aarch64-insn.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git
Hi Julien,
On Wed, Jan 20, 2021 at 06:17:41PM +0100, Julien Thierry wrote:
> Aarch64 instruction set encoding and decoding logic can prove useful
> for some features/tools both part of the kernel and outside the kernel.
>
> Isolate the function dealing only with encoding/decoding instructions,
>
On Mon, Feb 01, 2021 at 04:08:38PM +, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 01:57:14PM +0000, Mark Rutland wrote:
> > We could simplify this slightly if we moved the kexec_& variables into a
> > struct (using asm-offset KEXEC_VAR_* offsets and a KE
Hi,
On Mon, Feb 01, 2021 at 02:39:46PM +, Giancarlo Ferrari wrote:
> On Mon, Feb 01, 2021 at 12:47:20PM +0000, Mark Rutland wrote:
> > On Mon, Feb 01, 2021 at 12:44:56AM +, Giancarlo Ferrari wrote:
> > > machine_kexec() need to set rw permission in text and rodata sectio
On Mon, Feb 01, 2021 at 01:03:45PM +, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 12:47:20PM +0000, Mark Rutland wrote:
> > 1. copy reloc code into buffer
> > 2. alter variables in copy of reloc code
> > 3. branch to buffer
> >
> >
On Mon, Feb 01, 2021 at 12:44:56AM +, Giancarlo Ferrari wrote:
> machine_kexec() need to set rw permission in text and rodata sections
> to assign some variables (e.g. kexec_start_address). To do that at
> the end (after flushing pdm in memory, etc.) it needs to invalidate
> TLB [section]
On Fri, Jan 29, 2021 at 09:44:31PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> locking/core
> head: 997acaf6b4b59c6a9c259740312a69ea549cc684
> commit: 997acaf6b4b59c6a9c259740312a69ea549cc684 [10/10] lockdep: report
> broken irq
On Fri, Jan 29, 2021 at 09:35:46AM +0100, Dmitry Vyukov wrote:
> On Fri, Jan 29, 2021 at 9:34 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:76c057c8 Merge branch 'parisc-5.11-2' of git://git.kernel...
> > git tree: upstream
> >
On Tue, Jan 26, 2021 at 11:00:05AM -0600, Bjorn Andersson wrote:
> On Tue 26 Jan 10:21 CST 2021, Mark Rutland wrote:
>
> > On Tue, Jan 26, 2021 at 02:58:33PM +, Matthew Wilcox wrote:
> > > On Tue, Jan 26, 2021 at 10:47:34AM +, Mark Rutland wrote:
> > > >
On Tue, Jan 26, 2021 at 02:58:33PM +, Matthew Wilcox wrote:
> On Tue, Jan 26, 2021 at 10:47:34AM +0000, Mark Rutland wrote:
> > Hi,
> >
> > When fuzzing arm64 with Syzkaller, I'm seeing some splats where
> > this_cpu_ptr() is used in the bo
On Tue, Jan 26, 2021 at 01:57:13PM +, Will Deacon wrote:
> > @@ -297,16 +297,20 @@ void __init __no_sanitize_address setup_arch(char
> > **cmdline_p)
> > */
> > arm64_use_ng_mappings = kaslr_requires_kpti();
> >
> > - early_fixmap_init();
> > - early_ioremap_init();
> > -
> > -
Hi,
When fuzzing arm64 with Syzkaller, I'm seeing some splats where
this_cpu_ptr() is used in the bowels of idr_alloc(), by way of
radix_tree_node_alloc(), in a preemptible context:
| BUG: using smp_processor_id() in preemptible [] code:
syz-executor.1/32582
| caller is
This patch itself looks fine, but it's not going to backport very far,
so I suspect we might need to write a preparatory patch that adds an
explicit range check to virt_addr_valid() which can be trivially
backported.
For this patch:
Acked-by: Mark Rutland
Thanks,
Mark.
> ---
> arch/ar
On Mon, Jan 25, 2021 at 02:59:12PM +, Catalin Marinas wrote:
> On Mon, Jan 25, 2021 at 02:36:34PM +, Vincenzo Frascino wrote:
> > On 1/25/21 1:02 PM, Mark Rutland wrote:
> > > On Fri, Jan 22, 2021 at 03:56:40PM +, Vincenzo Frascino wrote:
> > > This patch
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 997acaf6b4b59c6a9c259740312a69ea549cc684
Gitweb:
https://git.kernel.org/tip/997acaf6b4b59c6a9c259740312a69ea549cc684
Author:Mark Rutland
AuthorDate:Mon, 11 Jan 2021 15:37:07
Committer
On Fri, Jan 22, 2021 at 02:24:43PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 22, 2021 at 11:06:25AM +0000, Mark Rutland wrote:
> > Hi all,
> >
> > Any thoughts on this? I'd like to get this in soon if we could as it'll
> > help to flush out any remaining issues that a
On Fri, Jan 22, 2021 at 04:03:26AM -0800, Paul E. McKenney wrote:
> On Thu, Jan 21, 2021 at 11:11:17AM +0000, Mark Rutland wrote:
>
> [ . . . ]
>
> > I've given this a spin atop v5.11-rc4, building natively on arm64 on a
> > Debian 10.7 system, and with the whole series
Hi all,
Any thoughts on this? I'd like to get this in soon if we could as it'll
help to flush out any remaining issues that are liable to get in the way
of planned rework for arm64 and x86.
Thomas, are you happy to pick this?
Thanks,
Mark.
On Mon, Jan 11, 2021 at 03:37:07PM +, Mark Rutland
On Thu, Jan 21, 2021 at 01:43:14PM -0800, Paul E. McKenney wrote:
> On Thu, Jan 21, 2021 at 09:31:10PM +, Will Deacon wrote:
> > On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
> > > On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
> > > > While running
o me, from a scan of the no_context path. I
don't have any MIPS system to test on, but FWIW:
Acked-by: Mark Rutland
Thanks for spinning this!
Mark.
> ---
> arch/mips/mm/fault.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/mm/fault.c
On Thu, Jan 21, 2021 at 03:30:51PM +, Vincenzo Frascino wrote:
> On 1/21/21 3:12 PM, Mark Rutland wrote:
> > On Thu, Jan 21, 2021 at 01:19:55PM +, Vincenzo Frascino wrote:
> >> Currently, the __is_lm_address() check just masks out the top 12 bits
> >> of the
[adding Ard]
On Thu, Jan 21, 2021 at 01:19:55PM +, Vincenzo Frascino wrote:
> Currently, the __is_lm_address() check just masks out the top 12 bits
> of the address, but if they are 0, it still yields a true result.
> This has as a side effect that virt_addr_valid() returns true even for
>
On Thu, Jan 21, 2021 at 01:22:37PM +, Marc Zyngier wrote:
> On 2021-01-21 12:50, Mohamed Mediouni wrote:
> > > On 21 Jan 2021, at 13:44, Arnd Bergmann wrote:
> > >
> > > On Wed, Jan 20, 2021 at 2:27 PM Mohamed Mediouni
>
> [...]
>
> > > > + aic.fast_ipi = of_property_read_bool(node,
Hi all,
Arch maintainers, if you are Cc'd I believe your architecture has a
user-triggerable livelock; please see below for details. Apologies in
advance if I am mistaken!
I believe the following architectures ARE affected:
alpha, hexagon, ia64, m68k, microblaze, mips, nios2, openrisc,
On Thu, Jan 21, 2021 at 02:53:39PM +0800, guo...@kernel.org wrote:
> From: Guo Ren
>
> Pick up the patch from the 'Link' made by Mark Rutland. Keep the
> same with x86, arm, arm64, arc, sh, power.
>
> Link:
> https://lore.kernel.org/linux-arm-kernel/1499782763-31418-1-git
On Thu, Jan 21, 2021 at 11:05:48AM +, Valentin Schneider wrote:
> Thanks for having a look at this! And kuddos to Mark for nudging the
> right people.
Likewise to Paul for poking Willy!
Thanks all,
Mark.
/rcutorture/res/2021.01.21-10.53.24
| ./tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 255 --configs TREE03
--kmake-arg CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 --duration 1
| TREE03 --- 475 GPs (7.91667/s) [rcu: g5737 f0x0 total-gps=1713]
| :CONFIG_HYPERVISOR_GUEST=y: improperly set
|
On Wed, Jan 20, 2021 at 01:43:40PM +0100, Willy Tarreau wrote:
> On Wed, Jan 20, 2021 at 12:07:25PM +0000, Mark Rutland wrote:
> > On Tue, Jan 19, 2021 at 06:43:58PM +0100, Willy Tarreau wrote:
> > > On Tue, Jan 19, 2021 at 06:16:37PM +0100, Willy Tarreau wrote:
> Did you f
On Wed, Jan 20, 2021 at 03:25:00PM +0100, Willy Tarreau wrote:
> On Wed, Jan 20, 2021 at 01:45:11PM +0000, Mark Rutland wrote:
> > > Ah that's very interesting indeed because actually these ones should
> > > only be used when __NR_dup3 or __NR_clone are not defined. Thus I
On Wed, Jan 20, 2021 at 03:25:00PM +0100, Willy Tarreau wrote:
> On Wed, Jan 20, 2021 at 01:45:11PM +0000, Mark Rutland wrote:
> > There's still some latent issue when using nolibc (compared to using
> > glibc) where the init process never seems to exit, but that looks to be
On Tue, Jan 19, 2021 at 06:43:58PM +0100, Willy Tarreau wrote:
> On Tue, Jan 19, 2021 at 06:16:37PM +0100, Willy Tarreau wrote:
> Given that you used a native compiler we can't suspect an issue with a
> bare-metal compiler possibly affecting how kernel headers are passed
> there. But nevertheless,
Hi Willy,
On Tue, Jan 19, 2021 at 05:19:01PM +0100, Willy Tarreau wrote:
> On Tue, Jan 19, 2021 at 07:31:47AM -0800, Paul E. McKenney wrote:
> > Some people are having trouble running rcutorture on ARMv8. They
> > get things like this from the nolibc build of initrd:
> >
> >
On Tue, Jan 19, 2021 at 02:23:03PM +, Vincenzo Frascino wrote:
> On 1/19/21 1:04 PM, Catalin Marinas wrote:
> > On Mon, Jan 18, 2021 at 06:30:31PM +, Vincenzo Frascino wrote:
> >> +bool kasan_report_async(unsigned long addr, size_t size,
> >> + bool is_write, unsigned
On Sun, Jan 17, 2021 at 12:27:08PM +, Vincenzo Frascino wrote:
> Hi Mark,
>
> On 1/16/21 2:22 PM, Vincenzo Frascino wrote:
> >> Is there any chance that this can be used for the last bytes of the
> >> virtual address space? This might need to change to `_addr == _end` if
> >> that is
Hi Petr,
On Mon, Jan 18, 2021 at 03:02:31PM +0100, Petr Mladek wrote:
> On Fri 2021-01-15 17:16:17, Mark Brown wrote:
> > I've made a few assumptions about preferred behaviour, notably:
> >
> > * If you can reliably unwind through exceptions, you should (as x86_64
> > does).
IIRC this was
On Mon, Jan 18, 2021 at 01:37:35PM +, Vincenzo Frascino wrote:
> On 1/18/21 12:57 PM, Catalin Marinas wrote:
> >> + if (tfsr_el1 & SYS_TFSR_EL1_TF1) {
> >> + write_sysreg_s(0, SYS_TFSR_EL1);
> >> + isb();
> > While in general we use ISB after a sysreg update, I haven't
On Fri, Jan 15, 2021 at 10:20:14AM -0700, Jonathan Corbet wrote:
> On Fri, 15 Jan 2021 17:12:51 +
> Mark Brown wrote:
>
> > On Fri, Jan 15, 2021 at 04:47:18PM +0000, Mark Rutland wrote:
> > > On Fri, Jan 15, 2021 at 02:24:46PM +, Mark Brown wrote:
> >
On Sat, Jan 16, 2021 at 01:47:08PM +, Vincenzo Frascino wrote:
> On 1/15/21 3:08 PM, Mark Rutland wrote:
> > On Fri, Jan 15, 2021 at 12:00:40PM +, Vincenzo Frascino wrote:
> >> #ifdef CONFIG_KASAN_HW_TAGS
> >> -#define arch_enable_tagging()
Hi Mark,
On Fri, Jan 15, 2021 at 02:24:46PM +, Mark Brown wrote:
> +.. Table of Contents:
> +
> +1. Introduction
> +2. Requirements
> +3. Considerations
> + 3.1 Identifying successful termination
> + 3.2 Identifying unwindable code
> + 3.3 Unwinding across
On Fri, Jan 15, 2021 at 12:00:43PM +, Vincenzo Frascino wrote:
> mte_assign_mem_tag_range() is called on production KASAN HW hot
> paths. It makes sense to optimize it in an attempt to reduce the
> overhead.
>
> Optimize mte_assign_mem_tag_range() based on the indications provided at
> [1].
On Fri, Jan 15, 2021 at 12:00:42PM +, Vincenzo Frascino wrote:
> MTE provides a mode that asynchronously updates the TFSR_EL1 register
> when a tag check exception is detected.
>
> To take advantage of this mode the kernel has to verify the status of
> the register at:
> 1. Context
On Fri, Jan 15, 2021 at 12:00:41PM +, Vincenzo Frascino wrote:
> MTE provides an asynchronous mode for detecting tag exceptions. In
> particular instead of triggering a fault the arm64 core updates a
> register which is checked by the kernel after the asynchronous tag
> check fault has
On Fri, Jan 15, 2021 at 12:00:40PM +, Vincenzo Frascino wrote:
> Architectures supported by KASAN HW can provide a light mode of
> execution. On an MTE enabled arm64 hw for example this can be identified
> with the asynch mode of execution.
> In this mode, if a tag check fault occurs, the
like to get in touch with the people who are currently working
> in this area, find out what exactly they are working on and see if they
> could use an extra pair of eyes/hands with what they are working on.
>
> It looks like the most recent work in this area has been from the
> follo
On Wed, Jan 13, 2021 at 04:25:41PM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 13, 2021 at 08:23:15PM +, Mark Brown wrote:
> > On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote:
> >
> > > I think it's worth mentioning a little more about objtool. There are a
> > > few passing
On Thu, Jan 14, 2021 at 08:36:50AM -0600, Josh Poimboeuf wrote:
> On Thu, Jan 14, 2021 at 11:54:18AM +0000, Mark Rutland wrote:
> > On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote:
> > > On Wed, Jan 13, 2021 at 04:57:43PM +, Mark Brown wrote:
> >
On Thu, Jan 14, 2021 at 10:41:59AM +0800, kernel test robot wrote:
> All warnings (new ones prefixed by >>):
>
>arch/arm64/kernel/syscall.c:157:6: warning: no previous prototype for
> 'do_el0_svc' [-Wmissing-prototypes]
> 157 | void do_el0_svc(struct pt_regs *regs)
> |
On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 13, 2021 at 04:57:43PM +, Mark Brown wrote:
> > From: Mark Rutland
> > +There are several ways an architecture may identify kernel code which is
> > deemed
> > +unreliable to unwind fr
On Tue, Jan 12, 2021 at 04:09:53PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 12, 2021 at 01:59:48PM +0000, Mark Rutland wrote:
> > Hi,
> >
> > While fuzzing arm64 with Syzkaller (under QEMU+KVM) over a number of
> > releases,
> > I've occasionally seen
On Tue, Jan 12, 2021 at 03:07:36PM +, Will Deacon wrote:
> On Fri, Jan 08, 2021 at 08:55:27PM +0800, Lecopzer Chen wrote:
> > > On Mon, 21 Dec 2020 at 21:53, Lecopzer Chen
> > > wrote:
> > > >
> > > > commit 367c820ef08082 ("arm64: Enable perf events based hard lockup
> > > > detector")
> >
be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Cc: Marc Zyngier
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
---
kernel/irq/chip.c | 15 +++
kernel/irq/handle.c| 4 +---
kernel/irq/internals.h | 28
3 files
hung IRQ handlers (which requires an NMI, and
should already be caught by hung task detection on systems with NMIs),
but helps on platforms without NMI or where a periodic watchdog is
undesireable.
Signed-off-by: Mark Rutland
Cc: Marc Zyngier
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas
.
Thanks,
Mark.
Mark Rutland (2):
irq: abstract irqaction handler invocation
irq: detect long-running IRQ handlers
kernel/irq/chip.c | 15 +++--
kernel/irq/handle.c| 4 +---
kernel/irq/internals.h | 57 ++
lib/Kconfig.debug
On Fri, Jan 08, 2021 at 09:39:53PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 08, 2021 at 09:32:58AM +, Will Deacon wrote:
> > Hi Arnd,
> >
> > On Fri, Jan 08, 2021 at 10:19:56AM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > With UBSAN enabled and building with clang,
in Lv
I think PT_REGS_SIZE is certainly clearer than S_FRAME_SIZE, and the
patch looks sound to me, so:
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/kernel/asm-offsets.c | 2 +-
> arch/arm64/kernel/entry-ftrace.S | 12 ++--
> arch/arm64/kernel/entry
of CONFIG_TRACE_IRQFLAGS. As noted above such cases
will confuse lockdep, so CONFIG_DEBUG_LOCKDEP now selects
CONFIG_DEBUG_IRQFLAGS.
Signed-off-by: Mark Rutland
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Juergen Gross
Cc: Peter Zijlstra
Cc: Thomas Gleixner
---
include/linux/irqflags.h | 12
On Fri, Jan 08, 2021 at 12:00:55PM +0800, Tingwei Zhang wrote:
> On Wed, Jan 06, 2021 at 08:23:56PM +0800, Mark Rutland wrote:
> > On Wed, Jan 06, 2021 at 06:29:53PM +0800, ting...@codeaurora.org wrote:
> > > Hi Will and Mark,
> >
> > Hi Tingwei,
> >
&g
On Sat, Dec 19, 2020 at 01:23:17PM +0800, Sang Yan wrote:
> Introducing a feature of CPU PARK in order to save time
> of cpus down and up during kexec, which may cost 250ms of
> per cpu's down and 30ms of up.
Where is that 250ms spent? Is that mostly in FW, or in the kernel
preparing/monitoring
On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote:
> current code checks for sp bit flip in all exceptions,
> but only el1 exceptions requires this. el0 can not enter
> into stack overflow case directly.
>
> it will improve performance for el0 exceptions and interrupts.
>
>
On Wed, Jan 06, 2021 at 06:29:53PM +0800, ting...@codeaurora.org wrote:
> Hi Will and Mark,
Hi Tingwei,
> In recent implementation of save/restore ARM debug registers in
> EL2/EL3, we found it's necessary to know whether self-host debug is
> enabled so EL2/EL3 can avoid saving/restoring debug
On Tue, Jan 05, 2021 at 03:47:26PM +, Russell King - ARM Linux admin wrote:
> Hi,
Hi Russell,
> This is an update on where I am with this long standing issue at the
> current time.
>
> Since 5.4, I have been struggling with several of my ARM64 systems, of
> different SoC vendors and
system wide profiling or profiling
> applications that fork.
>
> There is a small performance overhead when enabling
> PID_IN_CONTEXTIDR, but SPE itself is optional and not enabled by
> default so the impact is minimised.
>
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Al Grant
On Thu, Dec 17, 2020 at 03:36:40PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 09, 2020 at 06:33:37PM +0000, Mark Rutland wrote:
> > This means that a seuence such as:
>
> +q
>
> > diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
> > index 3ed
Unfortunately the merge resolution broke the build for arm64 -- could
you please apply the fixup below? IIUC that matches what we did in
linux-next, and builds fine locally.
Thanks,
Mark.
>8
>From da1826cc5132bb9d46aebdb47fa033f94825a697 Mon Sep 17 00:00:00 2001
From: Mark Rutla
On Mon, Dec 14, 2020 at 10:28:48AM +, Catalin Marinas wrote:
> On Mon, Dec 14, 2020 at 03:12:34PM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: 2c85ebc57b3e1817b6ce1a6b703928e113a90442
> > commit:
On Wed, Dec 09, 2020 at 07:54:26PM +0100, Thomas Gleixner wrote:
> On Wed, Dec 09 2020 at 18:15, Mark Rutland wrote:
> > In arch/x86/kernel/apic/io_apic.c's timer_irq_works() we do:
> >
> > local_irq_save(flags);
> > local_irq_enable();
> &
On Wed, Dec 09, 2020 at 11:05:21AM -0800, Andy Lutomirski wrote:
> On Wed, Dec 9, 2020 at 10:33 AM Mark Rutland wrote:
> > diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
> > index 3ed4e8771b64..bca3c6fa8270 100644
> > --- a/include/linux/irqflags.h
&g
-by: Mark Rutland
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Juergen Gross
Cc: Peter Zijlstra
Cc: Thomas Gleixner
---
include/linux/irqflags.h | 18 +-
kernel/locking/Makefile| 1 +
kernel/locking/irqflag-debug.c | 12
lib/Kconfig.debug | 7
101 - 200 of 8690 matches
Mail list logo
