linux-kernel - Re: [RFC PATCH 2/2] mm, vmstat: reduce zone->lock holding time by /proc/pagetypeinfo

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:   Wed, 23 Oct 2019 18:20:08 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>, Waiman Long <longman@...hat.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Roman Gushchin <guro@...com>,
        Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        Jann Horn <jannh@...gle.com>, Song Liu <songliubraving@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rafael Aquini <aquini@...hat.com>, linux-mm@...ck.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 2/2] mm, vmstat: reduce zone->lock holding time by
 /proc/pagetypeinfo

On 10/23/19 4:31 PM, Michal Hocko wrote:
> On Wed 23-10-19 15:48:36, Vlastimil Babka wrote:
>> On 10/23/19 3:37 PM, Michal Hocko wrote:
>>>
>>> But those wouldn't really help to prevent from the lockup, right?
>>
>> No, but it would perhaps help ensure that only people who know what they
>> are doing (or been told so by a developer e.g. on linux-mm) will try to
>> collect the data, and not some automatic monitoring tools taking
>> periodic snapshots of stuff in /proc that looks interesting.
> 
> Well, we do trust root doesn't do harm, right?

Perhaps too much :)

>>> Besides that who would enable that config and how much of a difference
>>> would root only vs. debugfs make?
>>
>> I would hope those tools don't scrap debugfs as much as /proc, but I
>> might be wrong of course :)
>>
>>> Is the incomplete value a real problem?
>>
>> Hmm perhaps not. If the overflow happens only for one migratetype, one
>> can use also /proc/buddyinfo to get to the exact count, as was proposed
>> in this thread for Movable migratetype.
> 
> Let's say this won't be the case. What is the worst case that the
> imprecision would cause? In other words. Does it really matter whether
> we have 100k pages on the free list of the specific migrate type for
> order or say 200k?

Probably not, it rather matters for which order the count approaches zero.