From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: bpf@vger.kernel.org
Cc: daniel@iogearbox.net, andrii@kernel.org,
torvalds@linux-foundation.org, brho@google.com,
hannes@cmpxchg.org, lstoakes@gmail.com,
akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org,
boris.ostrovsky@oracle.com, sstabellini@kernel.org,
jgross@suse.com, linux-mm@kvack.org,
xen-devel@lists.xenproject.org, kernel-team@fb.com
Subject: [PATCH v2 bpf-next 0/3] mm: Cleanup and identify various users of kernel virtual address space
Date: Fri, 23 Feb 2024 15:57:25 -0800 [thread overview]
Message-ID: <20240223235728.13981-1-alexei.starovoitov@gmail.com> (raw)
From: Alexei Starovoitov <ast@kernel.org>
There are various users of kernel virtual address space: vmalloc, vmap, ioremap, xen.
- vmalloc use case dominates the usage. Such vm areas have VM_ALLOC flag
and these areas are treated differently by KASAN.
- the areas created by vmap() function should be tagged with VM_MAP
(as majority of the users do).
- ioremap areas are tagged with VM_IOREMAP and vm area start is aligned to size
of the area unlike vmalloc/vmap.
- there is also xen usage that is marked as VM_IOREMAP, but it doesn't
call ioremap_page_range() unlike all other VM_IOREMAP users.
To clean this up:
1. Enforce that ioremap_page_range() checks the range and VM_IOREMAP flag.
2. Introduce VM_XEN flag to separate xen us cases from ioremap.
In addition BPF would like to reserve regions of kernel virtual address
space and populate it lazily, similar to xen use cases.
For that reason, introduce VM_SPARSE flag and vm_area_[un]map_pages() helpers
to populate this sparse area.
In the end the /proc/vmallocinfo will show
"vmalloc"
"vmap"
"ioremap"
"xen"
"sparse"
categories for different kinds of address regions.
ioremap, xen, sparse will return zero when dumped through /proc/kcore
Alexei Starovoitov (3):
mm: Enforce VM_IOREMAP flag and range in ioremap_page_range.
mm, xen: Separate xen use cases from ioremap.
mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().
arch/x86/xen/grant-table.c | 2 +-
drivers/xen/xenbus/xenbus_client.c | 2 +-
include/linux/vmalloc.h | 5 +++
mm/vmalloc.c | 71 +++++++++++++++++++++++++++++-
4 files changed, 76 insertions(+), 4 deletions(-)
--
2.34.1
next reply other threads:[~2024-02-23 23:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 23:57 Alexei Starovoitov [this message]
2024-02-23 23:57 ` [PATCH v2 bpf-next 1/3] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range Alexei Starovoitov
2024-02-26 10:50 ` Christoph Hellwig
2024-02-23 23:57 ` [PATCH v2 bpf-next 2/3] mm, xen: Separate xen use cases from ioremap Alexei Starovoitov
2024-02-26 10:51 ` Christoph Hellwig
2024-03-04 7:54 ` Mike Rapoport
2024-03-05 0:38 ` Alexei Starovoitov
2024-02-23 23:57 ` [PATCH v2 bpf-next 3/3] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages() Alexei Starovoitov
2024-02-27 17:59 ` Christoph Hellwig
2024-02-28 1:31 ` Alexei Starovoitov
2024-02-29 15:56 ` Christoph Hellwig
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=20240223235728.13981-1-alexei.starovoitov@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bpf@vger.kernel.org \
--cc=brho@google.com \
--cc=daniel@iogearbox.net \
--cc=hannes@cmpxchg.org \
--cc=hch@infradead.org \
--cc=jgross@suse.com \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=sstabellini@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=urezki@gmail.com \
--cc=xen-devel@lists.xenproject.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