linux-kernel - Re: [PATCH 02/34] mm, vmscan: move lru

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: <59b2b5d5-cec6-2128-307c-92c2085afd30@suse.cz>
Date:	Wed, 13 Jul 2016 10:39:12 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	bsingharora@...il.com, Mel Gorman <mgorman@...hsingularity.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>, Rik van Riel <riel@...riel.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Minchan Kim <minchan@...nel.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 02/34] mm, vmscan: move lru_lock to the node

On 07/13/2016 07:50 AM, Balbir Singh wrote:
> On Tue, Jul 12, 2016 at 12:18:05PM +0100, Mel Gorman wrote:
>> On Tue, Jul 12, 2016 at 09:06:04PM +1000, Balbir Singh wrote:
>>>> diff --git a/Documentation/cgroup-v1/memory.txt b/Documentation/cgroup-v1/memory.txt
>>>> index b14abf217239..946e69103cdd 100644
>>>> --- a/Documentation/cgroup-v1/memory.txt
>>>> +++ b/Documentation/cgroup-v1/memory.txt
>>>> @@ -267,11 +267,11 @@ When oom event notifier is registered, event will be delivered.
>>>>     Other lock order is following:
>>>>     PG_locked.
>>>>     mm->page_table_lock
>>>> -       zone->lru_lock
>>>> +       zone_lru_lock
>>>
>>> zone_lru_lock is a little confusing, can't we just call it
>>> node_lru_lock?
>>>
>>
>> It's a matter of perspective. People familiar with the VM already expect
>> a zone lock so will be looking for it. I can do a rename if you insist
>> but it may not actually help.
>
> I don't want to insist, but zone_ in the name can be confusing, as to
> leading us to think that the lru_lock is still in the zone

On the other hand, it suggests that the argument of the function is a 
zone. Passing a zone to something called "node_lru_lock()" would be more 
confusing to me. Also it's mostly a convenience wrapper to ease the 
transition, whose usage will likely diminish over time.

> If the rest of the reviewers are fine with, we don't need to rename

Yes, it's not worth the trouble.