, thanks!
[1/1] kselftest/arm64: abi: fix SVCR detection
https://git.kernel.org/arm64/c/ce03573a1917
--
Catalin
elftest/arm64: Check that SVCR is 0 in signal handlers
https://git.kernel.org/arm64/c/116e50d6474e
--
Catalin
On Fri, 08 Nov 2024 13:49:16 +, Catalin Marinas wrote:
> It looks like people started ignoring the compiler warnings (or even
> errors) when building the arm64-specific kselftests. The first three
> patches are printf() arguments adjustment. The last one adds
> ".arch_extensio
64: Add FPMR coverage to fp-ptrace
https://git.kernel.org/arm64/c/7dbd26d0b22d
--
Catalin
Applied to arm64 (for-next/kselftest), thanks!
[1/1] kselftest/arm64: Fix build with stricter assemblers
https://git.kernel.org/arm64/c/ae465d9ca192
--
Catalin
> being stubbed or omitted.
>
> [...]
Applied to arm64 (for-next/kselftest), thanks!
[3/6] kselftest/arm64: Corrupt P0 in the irritator when testing SSVE
https://git.kernel.org/arm64/c/3e360ef0c0a1
--
Catalin
st/arm64: Enable build of PAC tests with LLVM=1
https://git.kernel.org/arm64/c/c297aa7d3fb6
--
Catalin
https://git.kernel.org/arm64/c/27141b690547
[2/2] kselftest/arm64: Try harder to generate different keys during PAC tests
https://git.kernel.org/arm64/c/91a6533811bb
--
Catalin
Did this build for you? I may not have a new enough assembler.
fp-ptrace-asm.S:149:6: error: expected writable system register or pstate
msr FPMR, x7
I changed it to REG_FPMR locally.
--
Catalin
tderr, "Unexpected SVCR %llx\n", get_svcr());
> + return 1;
> + }
I think I'll change both printf specifiers to %lx here since in the libc
I have installed, uin64_t is an unsigned long (the kernel defines it as
unsigned long long). Both gcc and clang complain but the compiler
shouldn't matter since the headers come with glibc.
--
Catalin
rectory
132 | #include "asm/sysreg-defs.h"
| ^~~
Probably sysreg-defs.h has not been generated yet. Too late to figure it
out now.
--
Catalin
On Fri, Nov 08, 2024 at 03:27:58PM +, Catalin Marinas wrote:
> On Fri, Nov 08, 2024 at 03:20:46PM +, Mark Brown wrote:
> > While some assemblers (including the LLVM assembler I mostly use) will
> > happily accept SMSTART as an instruction by default others, specifically
&
This will reset ZA to all bits 0
> smstop
> - smstart
> + smstart_za
And is smstop ok for assemblers? I think I got the error first on
smstop with my toolchain.
--
Catalin
ignal handler state modification in fp-stress
https://git.kernel.org/arm64/c/ead1c35ce3b3
I did not merge patch 3 in case Mark R has any other comments.
--
Catalin
ernel.org/arm64/c/161e9925053c
--
Catalin
16B16 test
https://git.kernel.org/arm64/c/69c0d8247798
--
Catalin
. Simplify the
> interface to just return an int with 0 on success and a negative error code
> on failure.
>
> Acked-by: Deepak Gupta
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
t; Standardise on using the ksft_perror() helper in these cases so that more
> information is available should the tests fail.
>
>
> [...]
Applied to arm64 (for-next/kselftest), thanks!
[1/1] kselftest/arm64: Use ksft_perror() to log MTE failures
https://git.kernel.org/arm64/c/17a2409783f1
--
Catalin
errors to stdout
https://git.kernel.org/arm64/c/dca93d29845d
--
Catalin
ilure if any of the individual tests has failed.
>
>
Applied to arm64 (for-next/kselftest), thanks!
[1/1] kselftest/arm64: Fail the overall fp-stress test if any test fails
https://git.kernel.org/arm64/c/7a08cb9b4bb9
--
Catalin
freeing hugetlb folio, the MTE flags will be cleared.
>
> [...]
Applied to arm64 (for-next/mte), thanks!
[1/2] hugetlb: arm64: add mte support
https://git.kernel.org/arm64/c/25c17c4b55de
[2/2] selftests: arm64: add hugetlb mte tests
https://git.kernel.org/arm64/c/27879e8cb6b0
--
Catalin
issions work
https://git.kernel.org/arm64/c/48f8d9cef766
--
Catalin
4 (for-next/gcs), thanks!
[1/1] kselftest/arm64: Ensure stable names for GCS stress test results
https://git.kernel.org/arm64/c/9b9be7825851
--
Catalin
On Mon, Sep 09, 2024 at 08:40:34AM +0100, Vincent Donnefort wrote:
> On Sat, Sep 07, 2024 at 03:12:13PM +0100, Catalin Marinas wrote:
> > On Fri, Sep 06, 2024 at 04:38:56PM +0100, Vincent Donnefort wrote:
> > > commit ac3b43283923 ("module: replace module_la
reas which
> intended to limit kmemleak scan to sections containing writable data.
> This means sections such as .text and .rodata are scanned by kmemleak.
>
> Refine the scanned areas for modules by limiting it to MOD_TEXT and
> MOD_INIT_TEXT mod_mem regions.
>
> CC: Son
+0x14/0xa0
> [] start_kernel+0x12e/0x3c0
> [] x86_64_start_reservations+0x18/0x30
> [] x86_64_start_kernel+0x7b/0x80
> [] secondary_startup_64_no_verify+0x15e/0x16b
>
> Link: https://lore.kernel.org/linux-trace-kernel/87r0hfnr9r....@kernel.org/
>
> Fixes: 44dc5c41b5b1 ("tracing: Fix wasted memory in saved_cmdlines logic")
> Reported-by: Kalle Valo
> Signed-off-by: Steven Rostedt (Google)
Reviewed-by: Catalin Marinas
ch/arm64/kernel/vdso32/Makefile | 10 --
For arm64:
Acked-by: Catalin Marinas
information
> related to that feature, like in the Google spec document.
If you are aware of any vendors not supporting this, please direct them
to the Arm support team, it would be very useful information for us.
Thanks.
--
Catalin
ssume that the tag storage itself supports tagging. Hopefully
it makes the patches a bit simpler.
--
Catalin
e model).
I'll try to dig out how the mtu_tag_addr_shutter registers work and how
the sparse DRAM space is compressed to a smaller tag range. But that's
something done by firmware and the kernel only learns the tag storage
location from the DT (provided by firmware). We also don't need to know
the fine-grained mapping between 32 bytes of data and 1 byte (2 tags) in
the tag storage, only the block size in the tag storage space that
covers all interleaving done by the interconnect (it can be from 1 byte
to something larger like a page; the kernel will then use the lowest
common multiple between a page size and this tag block size to figure
out how many pages to reserve).
--
Catalin
On Mon, Sep 11, 2023 at 02:29:03PM +0200, David Hildenbrand wrote:
> On 11.09.23 13:52, Catalin Marinas wrote:
> > On Wed, Sep 06, 2023 at 12:23:21PM +0100, Alexandru Elisei wrote:
> > > On Thu, Aug 24, 2023 at 04:24:30PM +0100, Catalin Marinas wrote:
> > > > On T
On Wed, Sep 06, 2023 at 12:23:21PM +0100, Alexandru Elisei wrote:
> On Thu, Aug 24, 2023 at 04:24:30PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 24, 2023 at 01:25:41PM +0200, David Hildenbrand wrote:
> > > On 24.08.23 13:06, David Hildenbrand wrote:
> > > > Re
HOLES_IN_ZONE
> select IOMMU_DMA if IOMMU_SUPPORT
> select IRQ_DOMAIN
> select IRQ_FORCED_THREADING
> @@ -1053,9 +1054,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> def_bool y
> depends on NUMA
>
> -config HOLES_IN_ZONE
> - def_bool y
> -
> source "kernel/Kconfig.hz"
For arm64:
Acked-by: Catalin Marinas
es: Move length validation in alternative_{insn, endif}
arch/arm64/include/asm/alternative-macros.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
--
Catalin
at_thread(). It saves us from worrying whether regs are for the
current context.
I think we should change regs_return_value() instead. This function
seems to be called from several other places and it has the same
potential problems if called on compat pt_regs.
--
Catalin
nsn, endif}
https://git.kernel.org/arm64/c/22315a2296f4
--
Catalin
On Thu, Apr 15, 2021 at 08:50:25AM -0700, Sami Tolvanen wrote:
> On Thu, Apr 15, 2021 at 7:02 AM Catalin Marinas
> wrote:
> >
> > On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> > > On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
&
he later release and up before the control
> dependency here...
>
> > + } while (!atomic_try_cmpxchg_relaxed(&lock->cnts, &cnt, _QW_LOCKED));
>
> ... and then this cmpxchg() will succeed, so our speculated stale reads
> could be used.
>
> *HOWEVER*
>
> Speculating a read should be fine in the face of a concurrent _reader_,
> so for this to be an issue it implies that the reader is also doing some
> (atomic?) updates.
There's at least one such case: see chain_epi_lockless() updating
epi->next, called from ep_poll_callback() with a read_lock held. This
races with ep_done_scan() which has the write_lock held.
I think the authors of the above code interpreted the read_lock as
something that multiple threads can own disregarding the _read_ part.
--
Catalin
On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> > On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_A
d error. I used both clang-10 from
Debian stable and clang-11 from Debian sid. So, which clang version did
you use or which kernel config options?
--
Catalin
t; as well (ARM has a similar thing but less useful, see it's spinlock.h
> and look for wfe() and dsb_sev()).
>
> Once your arch hits NUMA, qspinlock is probably a win. However, low
> contention performance is still king for most workloads. Better high
> contention behaviour is nice.
--
Catalin
sure what the case is on other arm64 SOC, but it should do
> no harm.
> Signed-off-by: Kai Shen
Do you have a real world workload that's affected by this function?
I'm against adding alignments and nops for specific hardware
implementations. What about lots of other loops that the compiler may
generate or that we wrote in asm?
--
Catalin
f97
--
Catalin
On Wed, Apr 14, 2021 at 08:23:51AM +0800, Guo Ren wrote:
> On Tue, Apr 13, 2021 at 5:31 PM Catalin Marinas
> wrote:
> > On Tue, Apr 13, 2021 at 11:22:40AM +0200, Christoph Müllner wrote:
> > > On Tue, Apr 13, 2021 at 10:03 AM Peter Zijlstra
> > > wrote:
> &g
On Tue, Apr 13, 2021 at 04:52:34PM +, Liam Howlett wrote:
> * Catalin Marinas [210412 13:44]:
> > On Wed, Apr 07, 2021 at 03:11:06PM +, Liam Howlett wrote:
> > > find_vma() will continue to search upwards until the end of the virtual
> > > memory space. T
lease_conditional(lock, l.v32);
> } while (!success);
> return success;
> }
>
> But here we can't tell the compiler to optimize the code between LL and SC...
This indeed needs some care. IIUC RISC-V has similar restrictions as arm
here, no load/store instructions are allowed between LR and SC. You
can't guarantee that the compiler won't spill some variable onto the
stack.
BTW, I think the SC doesn't need release semantics above, only the LR
needs acquire semantics.
--
Catalin
7
[9/9] kasan, arm64: tests supports for HW_TAGS async mode
https://git.kernel.org/arm64/c/e80a76aa1a91
--
Catalin
ylock()?
> I.e. one could implement trylock() without a loop, by letting
> trylock() fail if the SC fails.
> That looks safe on first view, but nobody does this right now.
Not familiar with RISC-V but I'd recommend that a trylock only fails if
the lock is locked (after LR). A SC may fail for other reasons
(cacheline eviction; depending on the microarchitecture) even if the
lock is unlocked. At least on arm64 we had this issue with an
implementation having a tendency to always fail the first STXR.
--
Catalin
\
> + WRITE_ONCE(fail_data.report_found, false); \
> + WRITE_ONCE(fail_data.report_expected, false); \
> } while (0)
>
> #define KASAN_TEST_NEEDS_CONFIG_ON(test, config) do {
> \
Thanks Stephen. The resolution looks correct.
Andrew, if you'd rather I dropped the MTE async mode support from the
arm64 tree please let me know. Thanks.
https://lore.kernel.org/r/20210315132019.33202-1-vincenzo.frasc...@arm.com/
--
Catalin
= SEGV_ACCERR;
I don't think your change is entirely correct either. We can have a
fault below the vma of a stack (with VM_GROWSDOWN) and
find_vma_intersection() would return NULL but it should be a SEGV_ACCERR
instead.
Maybe this should employ similar checks as __do_page_fault() (with
expand_stack() and VM_GROWSDOWN).
--
Catalin
On Sun, Apr 11, 2021 at 03:03:16PM -0700, Andrew Morton wrote:
> On Sun, 11 Apr 2021 11:53:33 +0100 Catalin Marinas
> wrote:
> > On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> > > On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
> > > wrot
On Thu, Mar 18, 2021 at 06:56:07PM +, Catalin Marinas wrote:
> On Mon, Mar 15, 2021 at 01:20:10PM +, Vincenzo Frascino wrote:
> > This patchset implements the asynchronous mode support for ARMv8.5-A
> > Memory Tagging Extension (MTE), which is a debugging feature that allow
> >
> > Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
> > Cc: sta...@vger.kernel.org
>
> Got it, thanks. I updated the changelog to mention the warning fix and
> moved these ahead for a -rc merge.
Is there a chance this patch makes it into 5.12? I still get the warning
with the latest Linus' tree (v5.12-rc6-408-g52e44129fba5) when enabling
KASAN_HW_TAGS.
Thanks.
--
Catalin
stset \tmp, [\ti_flags]
msr_s SYS_TFSRE0_EL1, xzr
1:
#endif
@@ -244,7 +246,7 @@ alternative_else_nop_endif
disable_step_tsk x19, x20
/* Check for asynchronous tag check faults in user space */
- check_mte_async_tcf x19, x22
+ check_mte_async_tcf x22, x23
apply_ssbd 1, x22, x23
ptrauth_keys_install_kernel tsk, x20, x22, x23
--
Catalin
dsb(ish);
> write_sysreg_s(0, SYS_TFSRE0_EL1);
> +}
I think Mark suggested on your first version that we should keep these
functions in mte.h so that they can be inlined. They are small and only
called in one or two places.
--
Catalin
On Thu, Apr 08, 2021 at 08:16:17PM +0200, David Hildenbrand wrote:
> On 08.04.21 16:18, Catalin Marinas wrote:
> > On Wed, Apr 07, 2021 at 04:52:54PM +0100, Steven Price wrote:
> > > On 07/04/2021 16:14, Catalin Marinas wrote:
> > > > On Wed, Apr 07, 2021 at 11:20:
tps://git.kernel.org/arm64/c/df652a16a657
--
Catalin
rm64/c/a7dcf58ae5d2
--
Catalin
On Wed, Apr 07, 2021 at 04:52:54PM +0100, Steven Price wrote:
> On 07/04/2021 16:14, Catalin Marinas wrote:
> > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> > > On 31/03/2021 19:43, Catalin Marinas wrote:
> > > > When a slot is added by the VMM, i
On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> On 31/03/2021 19:43, Catalin Marinas wrote:
> > When a slot is added by the VMM, if it asked for MTE in guest (I guess
> > that's an opt-in by the VMM, haven't checked the other patches), can we
> > r
On Wed, Apr 07, 2021 at 07:34:08AM +0200, Greg Kroah-Hartman wrote:
> The common scripts/install.sh script will now work for arm65, no changes
> needed so convert the arm64 boot Makefile to call it instead of the
> arm64-only version of the file and remove the now unused file.
>
&
g pud_dirty is causing a compilation error.
>
> The drivers/gpu/drm/vmwgfx code uses mapping_dirty_helpers and
> has been ported to ARM64 but it depends on this code getting in
> first in order to compile/work.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Peter Zijlst
On Tue, 30 Mar 2021 04:58:17 -0400, He Ying wrote:
> depending -> depending on
Applied to arm64 (for-next/misc), thanks!
[1/1] docs: arm64: Fix a grammar error
https://git.kernel.org/arm64/c/68f638a432df
--
Catalin
On Wed, Mar 31, 2021 at 11:41:20AM +0100, Steven Price wrote:
> On 31/03/2021 10:32, David Hildenbrand wrote:
> > On 31.03.21 11:21, Catalin Marinas wrote:
> > > On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
> > > > On 30.03.21 12:30, Catalin M
On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
> On 30.03.21 12:30, Catalin Marinas wrote:
> > On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
> > > On 28/03/2021 13:21, Catalin Marinas wrote:
> > > > On Sat, Mar 27, 2021 at 03:23:24P
On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
> On 28/03/2021 13:21, Catalin Marinas wrote:
> > On Sat, Mar 27, 2021 at 03:23:24PM +, Catalin Marinas wrote:
> > > On Fri, Mar 12, 2021 at 03:18:58PM +, Steven Price wrote:
> > > > diff --git
On Mon, Mar 29, 2021 at 04:55:29PM +0100, Steven Price wrote:
> On 26/03/2021 18:56, Catalin Marinas wrote:
> > On Fri, Mar 12, 2021 at 03:18:57PM +, Steven Price wrote:
> > > A KVM guest could store tags in a page even if the VMM hasn't mapped
> > > the page
AN_VMALLOC
https://git.kernel.org/arm64/c/31d02e7ab008
[5/5] arm64: Kconfig: select KASAN_VMALLOC if KANSAN_GENERIC is enabled
https://git.kernel.org/arm64/c/acc3042d62cb
--
Catalin
nt panic_smp_self_stop()") a new
> function "panic_smp_self_stop" was added without a prototype.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: smp: Add missing prototype for some smp.c functions
https://git.kernel.org/arm64/c/a52ef778ff28
--
Catalin
N 62
>
> --#define ARM64_NCAPS 62
> ++#define ARM64_NCAPS 63
>
> #endif /* __ASM_CPUCAPS_H */
Thanks Stephen, it looks fine.
--
Catalin
work.h
> @@ -2,6 +2,9 @@
> #ifndef __ASM_IRQ_WORK_H
> #define __ASM_IRQ_WORK_H
>
> +extern void arch_irq_work_raise(void);
> +extern void panic_smp_self_stop(void);
The second prototype makes more sense in arch/arm64/include/asm/smp.h
where we already have crash_smp_send_stop().
--
Catalin
On Sat, Mar 27, 2021 at 03:23:24PM +, Catalin Marinas wrote:
> On Fri, Mar 12, 2021 at 03:18:58PM +, Steven Price wrote:
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 77cb2d28f2a4..b31b7a821f90 100644
> > --- a/arch/arm64/kvm/mmu.c
> >
On Sun, Mar 28, 2021 at 03:59:29PM +0900, Masahiro Yamada wrote:
> On Fri, Mar 26, 2021 at 11:36 PM Catalin Marinas
> wrote:
> > On Wed, Mar 24, 2021 at 04:11:28PM +0900, Masahiro Yamada wrote:
> > > $(call ld-option, --fix-cortex-a53-843419) in arch/arm64/Makefile is
>
if (!test_and_set_bit(PG_mte_tagged, &page->flags))
> + mte_clear_page_tags(page_address(page));
> + }
> + }
> +
> if (writable)
> prot |= KVM_PGTABLE_PROT_W;
>
--
Catalin
On Fri, Mar 26, 2021 at 05:35:19PM -0700, Andrei Vagin wrote:
> On Fri, Mar 26, 2021 at 11:28 AM Catalin Marinas
> wrote:
> >
> > On Mon, Mar 22, 2021 at 03:50:50PM -0700, Andrei Vagin wrote:
> > > diff --git a/arch/arm64/include/uapi/asm/ptrace.h
> > > b/
ing (say fault-around)? It's not too bad if we keep the
metadata around for when the pte becomes accessible but I suspect we
remove it if the page is removed from swap.
--
Catalin
US but which restores x0 to orig_x0 and x7
to orig_x7.
Sorry if this was already discussed. I had a brief look at the previous
versions and couldn't see a user_pt_regs structure change, nor a
suggestion to do so.
--
Catalin
ta) would write past the end
of an old struct user_pt_regs in the debugger.
--
Catalin
option name is.
> Please suggest a one if you have a better idea.
>
>
> arch/arm64/Kconfig | 3 +++
> arch/arm64/Makefile | 2 +-
> 2 files changed, 4 insertions(+), 1 deletion(-)
Would you like this patch to go in via the arm64 tree or you will queue
it via the kbuild tree?
Thanks.
--
Catalin
5d337
[6/6] arm64: irq: allow FIQs to be handled
https://git.kernel.org/arm64/c/3889ba70102e
--
Catalin
24 Mar 2021 15:51:14 +,
> > > > Suzuki K Poulose wrote:
> > > > >
> > > > > On 24/03/2021 13:49, Marc Zyngier wrote:
> > > > > > On Wed, 24 Mar 2021 09:39:13 +,
> > > > > > Suzuki K Poulose wrote:
> > > &
eir author.
Thanks Stephen. Now fixed.
--
Catalin
Hi Suzuki?
On Tue, Mar 23, 2021 at 12:06:33PM +, Suzuki K Poulose wrote:
> tsb csync synchronizes the trace operation of instructions.
> The instruction is a nop when FEAT_TRF is not implemented.
>
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Cc: Catalin Marinas
> Cc:
to date.
If having non-optimal (but good enough) uaccess routines is acceptable,
I'd go for (2) with a plan to move to (3) at the next Cortex Strings
update.
I also need to look again at option (1) to see how complex it is but
given the time one spends on importing a new Cortex Strings library, I
don't think (1) scales well on the long term. We could, however, go for
(1) now and look at (3) with the next update.
--
Catalin
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
The resolution looks fine. Thanks Stephen.
--
Catalin
I've given this a spin with a bunch of
> toolchains, verifying the output of /proc/self/stack and checking that
> the assembly looked sound. For GCC (where we require version 5.1.0 or
> later) I tested with the kernel.org crosstool binares for versions
> 5.5.0, 6.4.0, 6.5.0, 7.3.0,
RCH_ENABLE_SPLIT_PMD_PTLOCK
> mm: Drop redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE
>
> arch/arc/Kconfig | 9 ++--
> arch/arm/Kconfig | 10 ++---
> arch/arm64/Kconfig | 30 ++
For arm64:
Acked-by: Catalin Marinas
And the dependency cannot be guaranteed by Kconfig.
>
> move the definition of CONFIG_DEBUG_KMEMLEAK_TEST from lib/Kconfig.debug
> to samples/Kconfig.
>
> Signed-off-by: Chen Jun
> Acked-by: Catalin Marinas
Cc'ing Andrew, I don't think he's seen the patch.
'__compiletime_assert_417' declared with attribute error: BUILD_BUG_ON
> failed: KMALLOC_MIN_SIZE > 16 | KMALLOC_SHIFT_HIGH < 10
KMALLOC_MIN_SIZE is 128 on arm64, so commit 1a58eef5def9 ("selftests:
add a kselftest for SLUB debugging functionality") breaks the build. The
test was previously in mm/slub.c hidden behind macro that no-one
enabled.
--
Catalin
onovalov
> Tested-by: Ard Biesheuvel
You could move these to individual patches rather than the cover letter,
assuming that they still stand after the changes you've made. Also note
that Andrey K no longer has the @google.com email address if you cc him
on future patches (replace it with @gmail.com).
Thanks.
--
Catalin
hadow_end)
> + kasan_populate_early_shadow((void *)mod_shadow_end,
> + (void *)kimg_shadow_start);
> + }
>
> for_each_mem_range(i, &pa_start, &pa_end) {
> void *start = (void *)__phys_to_virt(pa_start);
> --
> 2.25.1
>
--
Catalin
IG_MEMTEST.
> Conversely CONFIG_MEMTEST cannot be enabled on platforms where it would
> not be tested anyway.
>
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Thomas Bogendoerfer
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
On Thu, Mar 18, 2021 at 09:41:54AM +0100, Arnd Bergmann wrote:
> On Wed, Mar 17, 2021 at 5:18 PM Catalin Marinas
> wrote:
> >
> > On Wed, Mar 17, 2021 at 02:37:57PM +, Catalin Marinas wrote:
> > > On Thu, Feb 25, 2021 at 12:20:56PM +0100, Arnd Bergmann wrote:
>
y with the google.com
address and you've been cc'ed on that. You may want to update the
.mailmap file in the kernel.
Thanks.
--
Catalin
On Thu, Mar 18, 2021 at 05:12:07PM +, Mark Rutland wrote:
> On Thu, Mar 18, 2021 at 04:17:24PM +0000, Catalin Marinas wrote:
> > On Wed, Mar 17, 2021 at 07:34:16PM +, Mark Rutland wrote:
> > > On Wed, Mar 17, 2021 at 06:36:36PM +, Catalin Marinas wrote:
> > >
On Wed, Mar 17, 2021 at 07:34:16PM +, Mark Rutland wrote:
> On Wed, Mar 17, 2021 at 06:36:36PM +0000, Catalin Marinas wrote:
> > On Wed, Mar 17, 2021 at 02:20:50PM +, Chen Jun wrote:
> > > On ARM64, cat /sys/kernel/debug/page_owner, all pages return th
rrent ? 2 : 0;
+
while (1) {
int ret;
- if (!fn(data, frame->pc))
+ if (skip)
+ skip--;
+ else if (!fn(data, frame->pc))
break;
ret = unwind_frame(tsk, frame);
if (ret < 0)
--
Catalin
On Wed, Mar 17, 2021 at 02:37:57PM +, Catalin Marinas wrote:
> On Thu, Feb 25, 2021 at 12:20:56PM +0100, Arnd Bergmann wrote:
> > diff --git a/arch/arm64/kernel/vmlinux.lds.S
> > b/arch/arm64/kernel/vmlinux.lds.S
> > index bad2b9eaab22..926cdb597a45 100644
> &
m the EFI stub */
INIT_DATA already covers .init.data and .init.data.*, so I don't think
we need this change.
Also, mainline doesn't have .init.bss.*, do you know where this came
from? I can't find it in -next either.
--
Catalin
e_ksize() in
> slab_post_alloc_hook() (and avoid new IS_ENABLED(CONFIG_DEBUG_KMEMLEAK)
> guard), just call kfence_ksize() in mm/kmemleak.c:create_object().
>
> Reported-by: Luis Henriques
> Cc: Catalin Marinas
> Signed-off-by: Marco Elver
Reviewed-by: Catalin Marinas
1 - 100 of 1932 matches
Mail list logo
