linux-kernel - Re: [PATCH] mm: Drop "PFNs busy" printk in an expected path.

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:   Fri, 30 Dec 2016 12:25:00 -0800
From:   Eric Anholt <eric@...olt.net>
To:     Michal Nazarewicz <mina86@...a86.com>,
        Michal Hocko <mhocko@...nel.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linux-stable <stable@...r.kernel.org>,
        "Robin H. Johnson" <robbat2@...is-terrarum.net>,
        Vlastimil Babka <vbabka@...e.cz>,
        Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH] mm: Drop "PFNs busy" printk in an expected path.

Michal Nazarewicz <mina86@...a86.com> writes:

> On Thu, Dec 29 2016, Eric Anholt wrote:
>> Michal Nazarewicz <mina86@...a86.com> writes:
>>
>>> On Thu, Dec 29 2016, Eric Anholt wrote:
>>>> Michal Hocko <mhocko@...nel.org> writes:
>>>>
>>>>> This has been already brought up
>>>>> http://lkml.kernel.org/r/20161130092239.GD18437@dhcp22.suse.cz and there
>>>>> was a proposed patch for that which ratelimited the output
>>>>> http://lkml.kernel.org/r/20161130132848.GG18432@dhcp22.suse.cz resp.
>>>>> http://lkml.kernel.org/r/robbat2-20161130T195244-998539995Z@orbis-terrarum.net
>>>>>
>>>>> then the email thread just died out because the issue turned out to be a
>>>>> configuration issue. Michal indicated that the message might be useful
>>>>> so dropping it completely seems like a bad idea. I do agree that
>>>>> something has to be done about that though. Can we reconsider the
>>>>> ratelimit thing?
>>>>
>>>> I agree that the rate of the message has gone up during 4.9 -- it used
>>>> to be a few per second.
>>>
>>> Sounds like a regression which should be fixed.
>>>
>>> This is why I don’t think removing the message is a good idea.  If you
>>> suddenly see a lot of those messages, something changed for the worse.
>>> If you remove this message, you will never know.
>>>
>>>> However, if this is an expected path during normal operation,
>>>
>>> This depends on your definition of ‘expected’ and ‘normal’.
>>>
>>> In general, I would argue that the fact those ever happen is a bug
>>> somewhere in the kernel – if memory is allocated as movable, it should
>>> be movable damn it!
>>
>> I was taking "expected" from dae803e165a11bc88ca8dbc07a11077caf97bbcb --
>> if this is a actually a bug, how do we go about debugging it?
>
> That’s why I’ve pointed out that this depends on the definition.  In my
> opinion it’s a design bug which is now nearly impossible to fix in
> efficient way.

OK, so the design is bad.  When you said bug, I definitely thought you
were saying that the message shouldn't happen in the design.

Given CMA's current design, should everyone using CMA see their logs
slowly growing with this message that is an secret code for "CMA's
design hasn't yet changed"?  If you want to have people be able to track
how often this is happening, let's make a perf event for it or something
instead.

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)