lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e22cbcdc-e9ce-50b7-aa88-6a3579ffd509@gmail.com>
Date:   Wed, 19 Aug 2020 10:15:53 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Doug Berger <opendmb@...il.com>
Cc:     Jason Baron <jbaron@...mai.com>,
        David Rientjes <rientjes@...gle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm: include CMA pages in lowmem_reserve at boot

On 8/18/20 8:18 PM, Andrew Morton wrote:
> On Fri, 14 Aug 2020 09:49:26 -0700 Doug Berger <opendmb@...il.com> wrote:
> 
>> 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.
> 
> 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.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ