From: Catalin Marinas <catalin.marinas@arm.com>
To: Russell King <linux@armlinux.org.uk>
Cc: Andre Mueller <am@emlix.com>, Will Deacon <will@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [External] : Re: [PATCH] Documentation/arm64: update memory layout table.
Date: Tue, 21 Jun 2022 18:25:17 +0100 [thread overview]
Message-ID: <YrH+/YyvPL5c/+zS@arm.com> (raw)
In-Reply-To: <DM8PR10MB54792798AE6434AD07318CDEE4B39@DM8PR10MB5479.namprd10.prod.outlook.com>
On Tue, Jun 21, 2022 at 02:47:30PM +0000, Russell King wrote:
> From: Catalin Marinas <catalin.marinas@arm.com>
> > On Tue, Jun 21, 2022 at 10:16:51AM +0200, Andre Mueller wrote:
> > > Commit b89ddf4cca43("arm64/bpf: Remove 128MB limit for BPF JIT programs")
> > > removes the bpf jit region from the memory layout of the Aarch64
> > > architecture. However, it forgets to update the documentation
> > > accordingly.
> > >
> > > - Remove the bpf jit region.
> > > - Fix the Start and End addresses of the modules region.
> > > - Fix the Start address of the vmalloc region.
> > >
> > > Signed-off-by: Andre Mueller <am@emlix.com>
> >
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> >
> > but I still wonder whether we should remove this table altogether.
>
> I've found the table particularly useful when wanting to know the
> virtual address space layout, so it does seem to have some value.
Yes but that's only one of the configurations and it keeps getting out
of sync. We used to print the information at boot until commit
071929dbdd86 ("arm64: Stop printing the virtual memory layout"). I think
we could bring some of that back, maybe even behind a debug command line
option or config (or expose it via sysfs). We shouldn't print the info
that has security implications like where stext is mapped or anything
randomised, only the rough layout like in the doc.
> (Replying from my work email as that's where it's been sent. Can't do
> anything but top-post, which is why I use my armlinux.org.uk email for
> kernel stuff - thanks Outlook web.)
As a side-note, Arm uses outlook as well but mutt can connect via IMAP
(if enabled; a bit of a pain with oauth2). For SMTP I use the kernel.org
one since outlook tends to corrupt patches.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-21 17:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 8:16 [PATCH] Documentation/arm64: update memory layout table Andre Mueller
2022-06-21 10:57 ` Catalin Marinas
2022-06-21 14:47 ` [External] : " Russell King
2022-06-21 14:53 ` André Müller
2022-06-21 17:25 ` Catalin Marinas [this message]
2022-06-21 18:06 ` Russell King (Oracle)
2022-07-20 13:57 ` Punit Agrawal
2022-06-23 19:31 ` Will Deacon
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=YrH+/YyvPL5c/+zS@arm.com \
--to=catalin.marinas@arm.com \
--cc=am@emlix.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.