linux-kernel - Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg

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, 29 Nov 2016 09:48:34 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Vlastimil Babka <vbabka@...e.cz>, Tejun Heo <tj@...nel.org>,
        Jens Axboe <axboe@...nel.dk>, linux-mm <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Marc MERLIN <marc@...lins.org>
Subject: Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations
 in blkcg

On Tue, Nov 29, 2016 at 9:28 AM, Michal Hocko <mhocko@...nel.org> wrote:
> How does this warning help those who are watching the logs? What are
> they supposed to do about it? Unlike GFP_ATOMIC there is no tuning you
> can possibly do.

You can report it and it will get fixed.

It's not about tuning. It's about people like Tejun who made changes
and didn't do them right.

In other words, exactly the patch that this whole thread started with.

Except that because of the idiotic arguments about the *obvious*
patch, the patch gets delayed and not applied.

The whole __GFP_NOWARN thing is not some kind of newfangled thing that
suddenly became a problem. It's been there for decades. Why are you
arguing for stupidly removing it now?

> I am confused, how can anybody _rely_ on GFP_NOWAIT to succeed?

You can't (except perhaps during bootup).

BUT YOU HAVE TO HAVE A FALLBACK, AND SHOW THAT YOU ARE *AWARE* THAT
YOU CAN"T RELY ON IT.

Christ. What's so hard to understand about this?

And no, GFP_NOWAIT is not special. Higher orders have the exact same
issue. And they too need that __GFP_NOWARN to show that "yes, I know,
and yes, I have a fallback strategy".

Because that warning shows real bugs. Seriously. We had fix for this
pending for 4.10 already (nfsd just blithely assuming it can do big
allocations).

So stop the idiotic arguments. The whole point is that lots of people
don't think about allocations failing (and NOWAIT and friends do not
change that ONE WHIT), and __GFP_NOWARN is there exactly to show that
you thought about them.

The warning _has_ been useful. We're not hiding it by default, because
that makes the whole warning pointless.

Really.

                Linus