linux-kernel - Re: [PATCH memcg] mm/page_alloc.c: avoid statistic update with 0

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]

Date:   Tue, 12 Oct 2021 13:42:41 +0300
From:   Vasily Averin <vvs@...tuozzo.com>
To:     Vlastimil Babka <vbabka@...e.cz>, Michal Hocko <mhocko@...nel.org>
Cc:     Johannes Weiner <hannes@...xchg.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        cgroups@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, kernel@...nvz.org,
        Mel Gorman <mgorman@...hsingularity.net>,
        Uladzislau Rezki <urezki@...il.com>
Subject: Re: [PATCH memcg] mm/page_alloc.c: avoid statistic update with 0

On 08.10.2021 14:47, Vlastimil Babka wrote:
> On 10/8/21 11:24, Vasily Averin wrote:
>> __alloc_pages_bulk can call __count_zid_vm_events and zone_statistics
>> with nr_account = 0.
> 
> But that's not a bug, right? Just an effective no-op that's not commonly
> happening, so is it worth the check?

Why not?

Yes, it's not a bug, it just makes the kernel a bit more efficient in a very unlikely case.
However, it looks strange and makes uninformed code reviewers like me worry about possible
problems inside the affected functions. No one else calls these functions from 0.
 
>> Fixes: 3e23060b2d0b ("mm/page_alloc: batch the accounting updates in the bulk allocator")
>> Signed-off-by: Vasily Averin <vvs@...tuozzo.com>
>> ---
>>  mm/page_alloc.c | 7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 602819a232e5..e67113452ee8 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5364,9 +5364,10 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
>>  	}
>>  
>>  	local_unlock_irqrestore(&pagesets.lock, flags);
>> -
>> -	__count_zid_vm_events(PGALLOC, zone_idx(zone), nr_account);
>> -	zone_statistics(ac.preferred_zoneref->zone, zone, nr_account);
>> +	if (nr_account) {
>> +		__count_zid_vm_events(PGALLOC, zone_idx(zone), nr_account);
>> +		zone_statistics(ac.preferred_zoneref->zone, zone, nr_account);
>> +	}
>>  	if (objcg)
>>  		memcg_bulk_post_charge_hook(objcg, nr_pre_charge - nr_account);
>>  
>>
>