diff options
author | Alexander Gordeev <agordeev@linux.ibm.com> | 2023-06-17 20:58:18 +0200 |
---|---|---|
committer | Alexander Gordeev <agordeev@linux.ibm.com> | 2023-06-28 13:57:08 +0200 |
commit | 456be42aa713e7f83b467db66ceae779431c7d9d (patch) | |
tree | e04c32daa325721b9cd66e626c8ca7e98efff442 /mm/page_owner.c | |
parent | 6a46676994607a1bde51cba71c1b0d373a555f45 (diff) | |
download | linux-stable-456be42aa713e7f83b467db66ceae779431c7d9d.tar.gz linux-stable-456be42aa713e7f83b467db66ceae779431c7d9d.tar.bz2 linux-stable-456be42aa713e7f83b467db66ceae779431c7d9d.zip |
s390/mm: get rid of VMEM_MAX_PHYS macro
VMEM_MAX_PHYS is supposed to be the highest physical
address that can be added to the identity mapping.
It should match ident_map_size, which has the same
meaning. However, unlike ident_map_size it is not
adjusted against various limiting factors (see the
comment to setup_ident_map_size() function). That
renders all checks against VMEM_MAX_PHYS invalid.
Further, VMEM_MAX_PHYS is currently set to vmemmap,
which is an address in virtual memory space. However,
it gets compared against physical addresses in various
locations. That works, because both address spaces
are the same on s390, but otherwise it is wrong.
Instead of fixing VMEM_MAX_PHYS misuse and semantics
just remove it.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Diffstat (limited to 'mm/page_owner.c')
0 files changed, 0 insertions, 0 deletions