On Fri, Feb 2, 2024 at 6:56 AM Alexandru Elisei
wrote:
>
> Hi Peter,
>
> On Thu, Feb 01, 2024 at 08:02:40PM -0800, Peter Collingbourne wrote:
> > On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
> > wrote:
> > >
> > > Linux restores tags wh
ed for
> the page.
>
> Signed-off-by: Alexandru Elisei
> ---
>
> Changes since rfc v2:
>
> * Restore saved tags **before** setting the PG_tag_storage_reserved bit to
> eliminate a brief window of opportunity where userspace can access
> uninitialized
> tags (Peter Collingbo
On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
wrote:
>
> Reserve tag storage for a page that is being allocated as tagged. This
> is a best effort approach, and failing to reserve tag storage is
> allowed.
>
> When all the associated tagged pages have been freed, return the tag
> storage pages
On Thu, Jan 25, 2024 at 8:43 AM Alexandru Elisei
wrote:
>
> arm64 uses VM_HIGH_ARCH_0 and VM_HIGH_ARCH_1 for enabling MTE for a VMA.
> When VM_HIGH_ARCH_0, which arm64 renames to VM_MTE, is set for a VMA, and
> the gfp flag __GFP_ZERO is present, the __GFP_ZEROTAGS gfp flag also gets
> set in
On Sun, Nov 19, 2023 at 8:59 AM Alexandru Elisei
wrote:
>
> Handle PAGE_FAULT_ON_ACCESS faults for huge pages in a similar way to
> regular pages.
>
> Signed-off-by: Alexandru Elisei
> ---
> arch/arm64/include/asm/mte_tag_storage.h | 1 +
> arch/arm64/include/asm/pgtable.h | 7 ++
>
Hi Alexandru,
On Wed, Aug 23, 2023 at 6:16 AM Alexandru Elisei
wrote:
>
> If the source page being migrated has metadata associated with it, make
> sure to reserve the metadata storage when choosing a suitable destination
> page from the free list.
>
> Signed-off-by: Alexandru Elisei
> ---
>
On Mon, Apr 5, 2021 at 2:53 PM Andrey Konovalov wrote:
>
> On Mon, Apr 5, 2021 at 11:43 PM Peter Collingbourne wrote:
> >
> > We can sometimes end up with kasan_byte_accessible() being called
> > on non-slab memory. For example ksize() and krealloc() may end up
> >
on against
KASAN_TAG_KERNEL.
Therefore, update kasan_byte_accessible() for both SW and HW tags
modes to correspond with the respective checks on loads and stores.
Link:
https://linux-review.googlesource.com/id/Ic6d40803c57dcc6331bd97fbb9a60b0d38a65a36
Signed-off-by: Peter Collingbourne
---
mm/kas
on against
KASAN_TAG_KERNEL.
Therefore, update kasan_byte_accessible() for both SW and HW tags
modes to correspond with the respective checks on loads and stores.
Link:
https://linux-review.googlesource.com/id/Ic6d40803c57dcc6331bd97fbb9a60b0d38a65a36
Signed-off-by: Peter Collingbourne
---
mm/kas
On Sat, Apr 3, 2021 at 4:52 PM Andrey Konovalov wrote:
>
> On Sun, Apr 4, 2021 at 12:31 AM Marco Elver wrote:
> >
> > However, given the above, I think we need to explain this in the
> > commit message (which also makes the dependency between these 2
> > patches clear) and add a comment above
On Sat, Apr 3, 2021 at 3:03 AM Marco Elver wrote:
>
> On Sat, 3 Apr 2021 at 07:13, Peter Collingbourne wrote:
> > If the memory region allocated by KFENCE had previously been poisoned,
> > any validity checks done using kasan_byte_accessible() will fail. Fix
> > it b
Signed-off-by: Peter Collingbourne
---
mm/kfence/core.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index d53c91f881a4..bb22b0cf77aa 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -633,13 +633,19 @@ static
On Thu, Mar 25, 2021 at 4:28 PM Sami Tolvanen wrote:
>
> On Thu, Mar 25, 2021 at 3:38 AM Mark Rutland wrote:
> >
> > On Tue, Mar 23, 2021 at 01:39:41PM -0700, Sami Tolvanen wrote:
> > > With CONFIG_CFI_CLANG, the compiler replaces function addresses in
> > > instrumented C code with jump table
of the panel are not being met.
>
> Reported-by: Peter Collingbourne
> Suggested-by: Peter Collingbourne
> Signed-off-by: Robert Foss
> Tested-by: John Stultz
Tested-by: Peter Collingbourne
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c | 8 +++-
> 1 file changed, 7 i
On Wed, Nov 25, 2020 at 11:06 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> arch/arm64/mm/proc.S
>
> between commit:
>
> 49b3cf035edc ("kasan: arm64: set TCR_EL1.TBID1 when enabled")
>
> from the arm64 tree and commit:
>
>
On Fri, Oct 2, 2020 at 8:58 AM Yu, Yu-cheng wrote:
>
> On 10/1/2020 7:06 PM, Peter Collingbourne wrote:
> > On Fri, Sep 25, 2020 at 7:57 AM Yu-cheng Yu wrote:
> >>
> >> There was no more caller passing vm_flags to do_mmap(), and vm_flags was
> >
On Fri, Sep 25, 2020 at 7:57 AM Yu-cheng Yu wrote:
>
> There was no more caller passing vm_flags to do_mmap(), and vm_flags was
> removed from the function's input by:
>
> commit 45e55300f114 ("mm: remove unnecessary wrapper function
> do_mmap_pgoff()").
>
> There is a new user now. Shadow
On Mon, Jun 1, 2020 at 4:18 PM Nick Desaulniers wrote:
>
> Will reported UBSAN warnings:
> UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
> UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
>
> Looks like the emulated offsetof macro ACPI_OFFSET is causing these. We
> can avoid
On Wed, Aug 7, 2019 at 8:25 AM Will Deacon wrote:
>
> Hello Masahiro,
>
> On Wed, Aug 07, 2019 at 11:43:02PM +0900, Masahiro Yamada wrote:
> > On Wed, Aug 7, 2019 at 8:46 PM Will Deacon wrote:
> > > On Tue, Aug 06, 2019 at 07:34:36PM -0700, Peter Collingbourne wrot
On Tue, Aug 6, 2019 at 4:50 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the arm64 tree, today's linux-next build (powerpc
> ppc64_defconfig) was just spinning in make - it executing some scripts,
> but it was hard to catch just what.
>
> Apparently caused by commit
>
> 5cf896fb6be3
Commit-ID: 98cd3c3f83fbba27a6bacd75ad12e8388a61a32a
Gitweb: https://git.kernel.org/tip/98cd3c3f83fbba27a6bacd75ad12e8388a61a32a
Author: Peter Collingbourne
AuthorDate: Fri, 21 Jun 2019 10:52:32 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 21:21:06 +0200
arm64: vdso
21 matches
Mail list logo
