mm: include CMA pages in lowmem_reserve at boot
Subsystems (2)
PATCH v2 1/1 mm: include CMA pages in lowmem_reserve at boot
The lowmem_reserve arrays provide a means of applying pressure against allocations from lower zones that were targeted at higher zones. Its values are a function of the number of pages managed by higher zones and are assigned by a call to the setup_per_zone_lowmem_reserve() function.
The function is initially called at boot time by the function init_per_zone_wmark_min() and may be called later by accesses of the /proc/sys/vm/lowmem_reserve_ratio sysctl file.
The function init_per_zone_wmark_min() was moved up from a module_init to a core_initcall to resolve a sequencing issue with khugepaged. Unfortunately this created a sequencing issue with CMA page accounting.
The CMA pages are added to the managed page count of a zone when cma_init_reserved_areas() is called at boot also as a core_initcall. This makes it uncertain whether the CMA pages will be added to the managed page counts of their zones before or after the call to init_per_zone_wmark_min() as it becomes dependent on link order. With the current link order the pages are added to the managed count after the lowmem_reserve arrays are initialized at boot.
This means the lowmem_reserve values at boot may be lower than the values used later if /proc/sys/vm/lowmem_reserve_ratio is accessed even if the ratio values are unchanged.
In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout
[ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]
would result in 0 lowmem_reserve for the DMA zone. This would allow userspace to deplete the DMA zone easily. Funnily enough
$ cat /proc/sys/vm/lowmem_reserve_ratio would fix up the situation because it forces setup_per_zone_lowmem_reserve as a side effect.
This commit breaks the link order dependency by invoking init_per_zone_wmark_min() as a postcore_initcall so that the CMA pages have the chance to be properly accounted in their zone(s) and allowing the lowmem_reserve arrays to receive consistent values.
--- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/page_alloc.c +1 -1
@@ -7887,7 +7887,7 @@ int __meminit init_per_zone_wmark_min(void)return 0 ; } -core_initcall (init_per_zone_wmark_min) +postcore_initcall (init_per_zone_wmark_min)/* * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so
Signature · 1 line
2.7.4
Andrew Morton
maintainerQuoted 30 lines · On Fri, 14 Aug 2020 09:49:26 -0700 Doug Berger <[email protected]> wrote:
The
lowmem_reservearrays provide a means of applying pressure against allocations from lower zones that were targeted at higher zones. Its values are a function of the number of pages managed by higher zones and are assigned by a call to thesetup_per_zone_lowmem_reserve()function.The function is initially called at boot time by the function
init_per_zone_wmark_min()and may be called later by accesses of the/proc/sys/vm/lowmem_reserve_ratiosysctl file.The function
init_per_zone_wmark_min()was moved up from amodule_initto acore_initcallto resolve a sequencing issue with khugepaged. Unfortunately this created a sequencing issue with CMA page accounting.The CMA pages are added to the managed page count of a zone when
cma_init_reserved_areas()is called at boot also as acore_initcall. This makes it uncertain whether the CMA pages will be added to the managed page counts of their zones before or after the call toinit_per_zone_wmark_min()as it becomes dependent on link order. With the current link order the pages are added to the managed count after thelowmem_reservearrays are initialized at boot.This means the
lowmem_reservevalues at boot may be lower than the values used later if/proc/sys/vm/lowmem_reserve_ratiois accessed even if the ratio values are unchanged.In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout
Quoted 8 lines
[ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]would result in 0
lowmem_reservefor the DMA zone. This would allow userspace to deplete the DMA zone easily.
Sounds fairly serious for thos machines. Was a cc:stable considered?
Quoted 11 lines
Funnily enough
$ cat /proc/sys/vm/lowmem_reserve_ratio would fix up the situation because it forces setup_per_zone_lowmem_reserve as a side effect.This commit breaks the link order dependency by invoking
init_per_zone_wmark_min()as apostcore_initcallso that the CMA pages have the chance to be properly accounted in their zone(s) and allowing thelowmem_reservearrays to receive consistent values.
Quoted 38 lines · Andrew Morton
Quoted 36 lines · On Fri, 14 Aug 2020 09:49:26 -0700 Doug Berger <[email protected]> wrote:
The
lowmem_reservearrays provide a means of applying pressure against allocations from lower zones that were targeted at higher zones. Its values are a function of the number of pages managed by higher zones and are assigned by a call to thesetup_per_zone_lowmem_reserve()function.The function is initially called at boot time by the function
init_per_zone_wmark_min()and may be called later by accesses of the/proc/sys/vm/lowmem_reserve_ratiosysctl file.The function
init_per_zone_wmark_min()was moved up from amodule_initto acore_initcallto resolve a sequencing issue with khugepaged. Unfortunately this created a sequencing issue with CMA page accounting.The CMA pages are added to the managed page count of a zone when
cma_init_reserved_areas()is called at boot also as acore_initcall. This makes it uncertain whether the CMA pages will be added to the managed page counts of their zones before or after the call toinit_per_zone_wmark_min()as it becomes dependent on link order. With the current link order the pages are added to the managed count after thelowmem_reservearrays are initialized at boot.This means the
lowmem_reservevalues at boot may be lower than the values used later if/proc/sys/vm/lowmem_reserve_ratiois accessed even if the ratio values are unchanged.In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout
[ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]
Quoted 4 lines
Quoted 2 lines
would result in 0
lowmem_reservefor the DMA zone. This would allow userspace to deplete the DMA zone easily.Sounds fairly serious for thos machines. Was a cc:stable considered?
Since there is a Fixes: tag, it may have been assumed that the patch would be picked up and as soon as it reaches Linus' tree it would be picked up by the stable selection.
Signature · 1 line
Florian
Andrew Morton
maintainerQuoted 8 lines · On Wed, 19 Aug 2020 10:15:53 -0700 Florian Fainelli <[email protected]>…
Quoted 8 lines
Quoted 8 lines
In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout
[ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
would result in 0
lowmem_reservefor the DMA zone. This would allow userspace to deplete the DMA zone easily.Sounds fairly serious for thos machines. Was a cc:stable considered?
Since there is a Fixes: tag, it may have been assumed that the patch would be picked up and as soon as it reaches Linus' tree it would be picked up by the stable selection.
It doesn't work that way - sometimes a fix isn't considered important enough to backport. It could just fix a typo in a comment!
Quoted 13 lines · Andrew Morton
Quoted 11 lines · On Wed, 19 Aug 2020 10:15:53 -0700 Florian Fainelli <[email protected]>…
Quoted 11 lines
Quoted 10 lines
In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout
[ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]would result in 0
lowmem_reservefor the DMA zone. This would allow userspace to deplete the DMA zone easily.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Sounds fairly serious for thos machines. Was a cc:stable considered?
Since there is a Fixes: tag, it may have been assumed that the patch would be picked up and as soon as it reaches Linus' tree it would be picked up by the stable selection.
It doesn't work that way - sometimes a fix isn't considered important enough to backport. It could just fix a typo in a comment!
Then can this be applied ASAP and back ported?
Signature · 1 line
Florian
Andrew Morton
maintainerQuoted 16 lines · On Wed, 19 Aug 2020 10:30:25 -0700 Florian Fainelli <[email protected]>…
Quoted 15 lines · Andrew Morton
Quoted 13 lines · On Wed, 19 Aug 2020 10:15:53 -0700 Florian Fainelli <[email protected]>…
Quoted 12 lines
Quoted 10 lines
In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout
[ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]would result in 0
lowmem_reservefor the DMA zone. This would allow userspace to deplete the DMA zone easily.Sounds fairly serious for thos machines. Was a cc:stable considered?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Since there is a Fixes: tag, it may have been assumed that the patch would be picked up and as soon as it reaches Linus' tree it would be picked up by the stable selection.
It doesn't work that way - sometimes a fix isn't considered important enough to backport. It could just fix a typo in a comment!
Then can this be applied ASAP and back ported?
Sure.
Quoted 22 lines · Andrew Morton
Quoted 20 lines · On Wed, 19 Aug 2020 10:30:25 -0700 Florian Fainelli <[email protected]>…
Quoted 19 lines · Andrew Morton
Quoted 16 lines · On Wed, 19 Aug 2020 10:15:53 -0700 Florian Fainelli <[email protected]>…
Quoted 8 lines
Quoted 8 lines
In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout
[ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]Quoted 4 lines
Quoted 2 lines
would result in 0
lowmem_reservefor the DMA zone. This would allow userspace to deplete the DMA zone easily.Sounds fairly serious for thos machines. Was a cc:stable considered?
Since there is a Fixes: tag, it may have been assumed that the patch would be picked up and as soon as it reaches Linus' tree it would be picked up by the stable selection.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
It doesn't work that way - sometimes a fix isn't considered important enough to backport. It could just fix a typo in a comment!
Then can this be applied ASAP and back ported?
Sure.
As Florian guessed, I assumed the Fixes: tag was a sufficient clue since I wouldn't normally apply a Fixes tag to a typo correction in a comment. I suspect I have been spoiled by David Miller :).
Thanks for the quick turn-around and applying the cc:stable to the mmotm,
Doug