On Wed, 26 Mar 2014, tytso@xxxxxxx wrote: > But that's another new user of GFP_NOFAIL (and one added three years > after David tried to declare There Shalt Be No New Users of > GFP_NOFAIL), and sure, we could probably patch around that by having > places where there's no other alternaive to keep a preallocated batch > of pages and/or allocated structures at each code site. But that's as > bad as looping at each code site; in fact, wouldn't it be better if > the allocator wants to avoid looping, to have a separate batch of > pages which (ala GFP_ATOMIC) which is reserved for just for GFP_NOFAIL > allocations when all else fails? > I didn't declare nobody should be adding __GFP_NOFAIL three years ago, rather three months ago I proposed a patch to fix __GFP_NOFAIL for GFP_ATOMIC allocations you're talking about above since, guess what, GPF_ATOMIC | __GFP_NOFAIL today easily returns NULL. I tried fixing that failable-__GFP_NOFAIL problem with http://marc.info/?l=linux-kernel&m=138662620812698 but Andrew requested a WARN_ON_ONCE() instead since nobody is currently doing that and we agreed to warn against new users. So we should either return to my earlier patch to actually make __GFP_NOFAIL not fail, or improve (but not remove) the checkpatch warning for these failable cases. I couldn't care less if we add 5,000 new __GFP_NOFAIL users tomorrow, I just care that it does what is expected if people are going to be adding them. -- 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
