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: <20161019115525.GH7517@dhcp22.suse.cz>
Date:   Wed, 19 Oct 2016 13:55:25 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     akpm@...ux-foundation.org, hannes@...xchg.org, mgorman@...e.de,
        dave.hansen@...el.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: How to make warn_alloc() reliable?

On Wed 19-10-16 20:27:53, Tetsuo Handa wrote:
[...]
> What I'm talking about is "why don't you stop playing whack-a-mole games
> with missing warn_alloc() calls". I don't blame you for not having a good
> idea, but I blame you for not having a reliable warn_alloc() mechanism.

Look, it seems pretty clear that our priorities and viewes are quite
different. While I believe that we should solve real issues in a
reliable and robust way you seem to love to be have as much reporting as
possible. I do agree that reporting is important part of debugging of
problems but as your previous attempts for the allocation watchdog show
a proper and bullet proof reporting requires state tracking and is in
general too complex for something that doesn't happen in most properly
configured systems. Maybe there are other ways but my time is better
spent on something more useful - like making the direct reclaim path
more deterministic without any unbound loops.

So let's agree to disagree about importance of the reliability
warn_alloc. I see it as an improvement which doesn't really have to be
perfect.
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ