From: Peter Collingbourne <pcc@google.com>
To: John Hubbard <jhubbard@nvidia.com>,
Matthew Wilcox <willy@infradead.org>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Evgenii Stepanov <eugenis@google.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-mm@kvack.org
Subject: Re: [PATCH v2] mm: introduce reference pages
Date: Thu, 13 Aug 2020 15:20:59 -0700 [thread overview]
Message-ID: <CAMn1gO4k4ahjdzBmQUb3+PMvzLekYv8GStJtZ2yNT1aS3934aw@mail.gmail.com> (raw)
In-Reply-To: <20200813220937.40973-1-pcc@google.com>
On Thu, Aug 13, 2020 at 3:09 PM Peter Collingbourne <pcc@google.com> wrote:
>
> Introduce a new syscall, refpage_create, which returns a file
> descriptor which may be mapped using mmap. Such a mapping is similar
> to an anonymous mapping, but instead of clean pages being backed by the
> zero page, they are instead backed by a so-called reference page, whose
> contents are specified using an argument to refpage_create. Loads from
> the mapping will load directly from the reference page, and initial
> stores to the mapping will copy-on-write from the reference page.
Catalin, I needed this diff on top of my patch and your latest MTE
series in order for reference pages to cooperate with MTE. The first
hunk is probably fine but without the second one, the tags in the
reference page would not be set correctly in the case where the
mapping used to create the reference page was not mapped with
PROT_MTE. I'm not sure if it's appropriate to have MTE-specific stuff
directly in mm/refpage.c so it probably needs something like a new
architecture interface or a change to an existing one. Do you have any
ideas?
diff --git a/mm/refpage.c b/mm/refpage.c
index c2f62a4f0dc0..7e4e4b2aabe2 100644
--- a/mm/refpage.c
+++ b/mm/refpage.c
@@ -7,6 +7,7 @@ static int refpage_mmap(struct file *file, struct
vm_area_struct *vma)
{
vma_set_anonymous(vma);
vma->vm_private_data = vma->vm_file->private_data;
+ vma->vm_flags |= VM_MTE_ALLOWED;
return 0;
}
@@ -44,6 +45,14 @@ SYSCALL_DEFINE2(refpage_create, const void *__user,
content, unsigned long,
}
copy_highpage(refpage, userpage);
+
+#ifdef CONFIG_ARM64_MTE
+ if (system_supports_mte() && !test_bit(PG_mte_tagged,
&userpage->flags)) {
+ set_bit(PG_mte_tagged, &refpage->flags);
+ mte_clear_page_tags(page_address(refpage));
+ }
+#endif
+
put_page(userpage);
fd = anon_inode_getfd("[refpage]", &refpage_file_operations, refpage,
Peter
next prev parent reply other threads:[~2020-08-13 22:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 22:09 Peter Collingbourne
2020-08-13 22:20 ` Peter Collingbourne [this message]
2020-08-13 22:31 ` Matthew Wilcox
2020-08-13 23:46 ` Peter Collingbourne
2020-08-14 1:00 ` kernel test robot
2020-08-14 1:01 ` kernel test robot
2020-08-14 1:11 ` kernel test robot
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=CAMn1gO4k4ahjdzBmQUb3+PMvzLekYv8GStJtZ2yNT1aS3934aw@mail.gmail.com \
--to=pcc@google.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=eugenis@google.com \
--cc=jhubbard@nvidia.com \
--cc=kirill@shutemov.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox