On Wed, 26 Mar 2014 02:19:04 -0400 tytso@xxxxxxx wrote: > On Tue, Mar 25, 2014 at 06:06:17PM -0700, David Rientjes wrote: > > > > The point is not to add new callers and new code should handle NULL > > correctly, not that we should run around changing current users to just do > > infinite retries. Checkpatch should have nothing to do with that. > > My problem with this doctrinaire "there should never be any new users" > is that sometiems there *are* worse things than infinite retries. If > the alternative is bringing the entire system down, or livelocking the > entire system, or corrupting user data, __GFP_NOFAIL *is* the more > appropriate option. Well, there are always alternatives. For example ext3 could preallocate a single transaction_t and a single IO page and fall back to synchronous page-at-a-time journal writes. But I can totally see that such things are unattractive: heaps of new code which is never tested in real life. The page allocator works so damn well that it doesn't make sense to implement it. > If you try to tell those of us outside of the mm layer, "thou shalt > never use __GFP_NOFAIL in new code", and we have some new code where > the alternative is worse, we can either open-code the loop, or have > some mm hackers and/or checkpatch whine at us. > > Andrew has declared that he'd prefer that we not open code the retry > loop; if you want to disagree with Andrew, feel free to pursuade him > otherwise. If you want to tell me that I should accept user data > corruption, I'm going to ignore you (and/or checkpatch). Please use NOFAIL ;) The core page allocator will always be able to implement this better than callers. -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
