summaryrefslogtreecommitdiffstats
path: root/mm/page_owner.c
diff options
context:
space:
mode:
authorAlexander Gordeev <agordeev@linux.ibm.com>2023-06-17 20:58:18 +0200
committerAlexander Gordeev <agordeev@linux.ibm.com>2023-06-28 13:57:08 +0200
commit456be42aa713e7f83b467db66ceae779431c7d9d (patch)
treee04c32daa325721b9cd66e626c8ca7e98efff442 /mm/page_owner.c
parent6a46676994607a1bde51cba71c1b0d373a555f45 (diff)
downloadlinux-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