All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Documentation/arm64: update memory layout table.
@ 2022-06-21  8:16 Andre Mueller
  2022-06-21 10:57 ` Catalin Marinas
  2022-06-23 19:31 ` Will Deacon
  0 siblings, 2 replies; 8+ messages in thread
From: Andre Mueller @ 2022-06-21  8:16 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Russell King, linux-arm-kernel, Andre Mueller

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>
---
 Documentation/arm64/memory.rst | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
index 901cd094f4ec..2a641ba7be3b 100644
--- a/Documentation/arm64/memory.rst
+++ b/Documentation/arm64/memory.rst
@@ -33,9 +33,8 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
   0000000000000000	0000ffffffffffff	 256TB		user
   ffff000000000000	ffff7fffffffffff	 128TB		kernel logical memory map
  [ffff600000000000	ffff7fffffffffff]	  32TB		[kasan shadow region]
-  ffff800000000000	ffff800007ffffff	 128MB		bpf jit region
-  ffff800008000000	ffff80000fffffff	 128MB		modules
-  ffff800010000000	fffffbffefffffff	 124TB		vmalloc
+  ffff800000000000	ffff800007ffffff	 128MB		modules
+  ffff800008000000	fffffbffefffffff	 124TB		vmalloc
   fffffbfff0000000	fffffbfffdffffff	 224MB		fixed mappings (top down)
   fffffbfffe000000	fffffbfffe7fffff	   8MB		[guard region]
   fffffbfffe800000	fffffbffff7fffff	  16MB		PCI I/O space
@@ -51,9 +50,8 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):
   0000000000000000	000fffffffffffff	   4PB		user
   fff0000000000000	ffff7fffffffffff	  ~4PB		kernel logical memory map
  [fffd800000000000	ffff7fffffffffff]	 512TB		[kasan shadow region]
-  ffff800000000000	ffff800007ffffff	 128MB		bpf jit region
-  ffff800008000000	ffff80000fffffff	 128MB		modules
-  ffff800010000000	fffffbffefffffff	 124TB		vmalloc
+  ffff800000000000	ffff800007ffffff	 128MB		modules
+  ffff800008000000	fffffbffefffffff	 124TB		vmalloc
   fffffbfff0000000	fffffbfffdffffff	 224MB		fixed mappings (top down)
   fffffbfffe000000	fffffbfffe7fffff	   8MB		[guard region]
   fffffbfffe800000	fffffbffff7fffff	  16MB		PCI I/O space

base-commit: 018ab4fabddd94f1c96f3b59e180691b9e88d5d8
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] Documentation/arm64: update memory layout table.
  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-23 19:31 ` Will Deacon
  1 sibling, 1 reply; 8+ messages in thread
From: Catalin Marinas @ 2022-06-21 10:57 UTC (permalink / raw)
  To: Andre Mueller; +Cc: Will Deacon, Russell King, linux-arm-kernel

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.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [External] : Re: [PATCH] Documentation/arm64: update memory layout table.
  2022-06-21 10:57 ` Catalin Marinas
@ 2022-06-21 14:47   ` Russell King
  2022-06-21 14:53     ` André Müller
  2022-06-21 17:25     ` Catalin Marinas
  0 siblings, 2 replies; 8+ messages in thread
From: Russell King @ 2022-06-21 14:47 UTC (permalink / raw)
  To: Catalin Marinas, Andre Mueller; +Cc: Will Deacon, linux-arm-kernel

(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.)

I've found the table particularly useful when wanting to know the virtual address space layout, so it does seem to have some value.

Russell.

________________________________________
From: Catalin Marinas <catalin.marinas@arm.com>
Sent: 21 June 2022 11:57
To: Andre Mueller
Cc: Will Deacon; Russell King; linux-arm-kernel@lists.infradead.org
Subject: [External] : Re: [PATCH] Documentation/arm64: update memory layout table.

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.

--
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [External] : Re: [PATCH] Documentation/arm64: update memory layout table.
  2022-06-21 14:47   ` [External] : " Russell King
@ 2022-06-21 14:53     ` André Müller
  2022-06-21 17:25     ` Catalin Marinas
  1 sibling, 0 replies; 8+ messages in thread
From: André Müller @ 2022-06-21 14:53 UTC (permalink / raw)
  To: Russell King, Catalin Marinas; +Cc: Will Deacon, linux-arm-kernel

Sorry about using the incorrect email address, Russell, I just took the one from
the b89ddf4cca43 commit.

I agree. We also found the table useful for getting a quick overview. Even
though it is now obvious, that the information in the table needs to be double
checked, if you want to rely on it.

Best regards,
André



On Tue, 2022-06-21 at 14:47 +0000, Russell King wrote:
> (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.)
> 
> I've found the table particularly useful when wanting to know the virtual
> address space layout, so it does seem to have some value.
> 
> Russell.
> 
> ________________________________________
> From: Catalin Marinas <catalin.marinas@arm.com>
> Sent: 21 June 2022 11:57
> To: Andre Mueller
> Cc: Will Deacon; Russell King; linux-arm-kernel@lists.infradead.org
> Subject: [External] : Re: [PATCH] Documentation/arm64: update memory layout
> table.
> 
> 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.
> 
> --
> Catalin

-- 
Besuchen Sie uns auf der Embedded World 2022 in Nürnberg!
-> 21.-23.06.2022 - Halle 4, Stand 336

André Müller
emlix GmbH, https://www.emlix.com
Fon +49 228 94 77 96 94
Bachstraße 6, 53115 Bonn, Germany
Sitz der Gesellschaft: Goettingen, Amtsgericht Goettingen HR B 3160
Geschaeftsfuehrung: Heike Jordan, Dr. Uwe Kracke
Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [External] : Re: [PATCH] Documentation/arm64: update memory layout table.
  2022-06-21 14:47   ` [External] : " Russell King
  2022-06-21 14:53     ` André Müller
@ 2022-06-21 17:25     ` Catalin Marinas
  2022-06-21 18:06       ` Russell King (Oracle)
  2022-07-20 13:57       ` Punit Agrawal
  1 sibling, 2 replies; 8+ messages in thread
From: Catalin Marinas @ 2022-06-21 17:25 UTC (permalink / raw)
  To: Russell King; +Cc: Andre Mueller, Will Deacon, linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [External] : Re: [PATCH] Documentation/arm64: update memory layout table.
  2022-06-21 17:25     ` Catalin Marinas
@ 2022-06-21 18:06       ` Russell King (Oracle)
  2022-07-20 13:57       ` Punit Agrawal
  1 sibling, 0 replies; 8+ messages in thread
From: Russell King (Oracle) @ 2022-06-21 18:06 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: Andre Mueller, Will Deacon, linux-arm-kernel

On Tue, Jun 21, 2022 at 06:25:17PM +0100, Catalin Marinas wrote:
> On Tue, Jun 21, 2022 at 02:47:30PM +0000, Russell King wrote:
> > From: Catalin Marinas <catalin.marinas@arm.com>
> > 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.

Sounds like a good idea - if there's a way to come up with it
programatically, then it's going to have a better chance of remaining
accurate.

> > (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.

I've tried neomutt + oauth2 over a few weeks... and with the gpg
splatting over the top of neomutt's output and the problems if you
don't notice the splatting and respond in time... yea, I gave up with
it, it was _way_ more hassle than using Outlook's web interface. It's
probably fine if all you're doing is monitoring email and nothing else.

I never thought I'd say that Outlook is better than neomutt, but in
this instance, Outlook web takes several orders of magnitude less user
maintenance than neomutt does. Neomutt + oauth2 is just way too
painful, even with the Outlook web quirks such as only supporting
top-post replying.

I guess that neomutt + oauth2 might be fine if you check email just
once a day, but not if you want to monitor email throughout the day.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Documentation/arm64: update memory layout table.
  2022-06-21  8:16 [PATCH] Documentation/arm64: update memory layout table Andre Mueller
  2022-06-21 10:57 ` Catalin Marinas
@ 2022-06-23 19:31 ` Will Deacon
  1 sibling, 0 replies; 8+ messages in thread
From: Will Deacon @ 2022-06-23 19:31 UTC (permalink / raw)
  To: Catalin Marinas, Andre Mueller
  Cc: kernel-team, Will Deacon, Russell King, linux-arm-kernel

On Tue, 21 Jun 2022 10:16:51 +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.
> 
> [...]

Applied to arm64 (for-next/docs), thanks!

[1/1] Documentation/arm64: update memory layout table.
      https://git.kernel.org/arm64/c/5bed6a93920d

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [External] : Re: [PATCH] Documentation/arm64: update memory layout table.
  2022-06-21 17:25     ` Catalin Marinas
  2022-06-21 18:06       ` Russell King (Oracle)
@ 2022-07-20 13:57       ` Punit Agrawal
  1 sibling, 0 replies; 8+ messages in thread
From: Punit Agrawal @ 2022-07-20 13:57 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Russell King, Andre Mueller, Will Deacon, linux-arm-kernel

Apologies for reviving an old thread.

Catalin Marinas <catalin.marinas@arm.com> writes:

> 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.

The kernel memory layout is available (indirectly) from
/sys/kernel/debug/kernel_page_tables with CONFIG_PTDUMP_DEBUGFS
enabled. Admittedly, it requires a bit of staring to infer the start,
end and size of the various regions but the information is there.

Is that sufficient? If so, the documentation can be updated to point to
the debugfs node.

[...]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-07-20 13:59 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2022-06-21 18:06       ` Russell King (Oracle)
2022-07-20 13:57       ` Punit Agrawal
2022-06-23 19:31 ` Will Deacon

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.