On Tue, 11 Jun 2013 18:16:08 +0300 Pekka Enberg <penb...@kernel.org> wrote:
> On Tue, 11 Jun 2013, Sasha Levin wrote: > >> I think that leaving the warning makes sense to catch similar > >> things which are actually bugs - we had a similar issue with > >> /dev/kmsg (if I remember correctly) which actually pointed to > >> a bug. > > On 6/11/13 6:14 PM, Christoph Lameter wrote: > > Right. Requesting an allocation larger than even supported by the page > > allocator from the slab allocators that are specializing in allocations of > > small objects is usually an indication of a problem in the code. > > So you're OK with going forward with Sasha's patch? Yes please. slab should honour __GFP_NOWARN. __GFP_NOWARN is frequently used by kernel code to probe for "how big an allocation can I get". That's a bit lame, but it's used on slow paths and is pretty simple. In the case of pipe_set_size(), it's userspace who is doing the probing: an application can request a huge pipe buffer and if that fails, try again with a smaller one. It's just wrong to emit a kernel warning in this case. Plus, we've already reported the failure anyway, by returning -ENOMEM from pipe_fcntl(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
