linux-kernel - Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP

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:	Sat, 22 Mar 2014 15:24:23 -0400
From:	Dave Jones <davej@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	tytso@....edu, Fabian Frederick <fabf@...net.be>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	reiserfs-devel@...r.kernel.org,
	David Rientjes <rientjes@...gle.com>,
	Joe Perches <joe@...ches.com>
Subject: Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete  __GFP_NOFAIL

On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
 > On Sat, 22 Mar 2014 13:32:07 -0400 tytso@....edu wrote:
 > 
 > > On Sat, Mar 22, 2014 at 01:26:06PM -0400, tytso@....EDU wrote:
 > > > > Well.  Converting an existing retry-for-ever caller to GFP_NOFAIL is
 > > > > good.  Adding new retry-for-ever code is not good.
 > > 
 > > Oh, and BTW --- now that checkpatch.pl now flags an warning whenever
 > > GFP_NOFAIL is used
 > 
 > I don't know what the basis for this NOFAIL-is-going-away theory could
 > have been.  What's the point in taking a centrally implemented piece of
 > logic and splattering its implementation out to tens of different
 > callsites?

I wonder if some of that thinking came from this..

commit dab48dab37d2770824420d1e01730a107fade1aa
Author: Andrew Morton <akpm@...ux-foundation.org>
Date:   Tue Jun 16 15:32:37 2009 -0700

    page-allocator: warn if __GFP_NOFAIL is used for a large allocation
    
    __GFP_NOFAIL is a bad fiction.  Allocations _can_ fail, and callers should
    detect and suitably handle this (and not by lamely moving the infinite
    loop up to the caller level either).


Perhaps some of the commentary in that changeset should be updated too.
Linus changed it from single page to > order 1 in 4923abf9f1a4c1864af438a57c1f3686548230e9
but there's still this..

+                        * __GFP_NOFAIL is not to be used in new code.
+                        *
+                        * All __GFP_NOFAIL callers should be fixed so that they
+                        * properly detect and handle allocation failures.


Additionally, I don't recall seeing that warn_on trigger in a while.
I have vague memories that e1000e used to step on it from time to time, but
maybe that got fixed.

	Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/