On Thu, 12 Jan 2012, Andrew Morton wrote: > > I think it's good to fix ecryptfs like Tyler is doing and, at the same > > time, ensure that the len passed to memdup_user() makes sense prior to > > kmallocing memory with GFP_KERNEL. Perhaps something like > > > > if (WARN_ON(len > PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) > > return ERR_PTR(-ENOMEM); > > > > in which case __GFP_NOWARN is irrelevant. > > If someone is passing huge size_t's into kmalloc() and getting failures > then that's probably a bug. So perhaps we should add a warning to > kmalloc itself if the size_t is out of bounds, and !__GFP_NOWARN. > That's already done. For slub, for example, the largest object size handled by the allocator itself is an order-1 page; everything else gets passed through to the page allocator and its limitation is MAX_ORDER, which is the warning that we're seeing in Sasha's changelog when !__GFP_NOWARN. > But none of this will be very effective. If someone is passing an > unchecked size_t into kmalloc then normal testing will not reveal the > problem because the testers won't pass stupid numbers into their > syscalls. > They'll get the same warning that Sasha got, which is because the page allocator can't handle larger than MAX_ORDER orders. The intention in my WARN_ON() above specifically for memdup_user() is to avoid the infinite loop in the page allocator for GFP_KERNEL allocations where the order is less than PAGE_ALLOC_COSTLY_ORDER and avoid the oom killer. It returns immediately rather than passing __GFP_NORETRY since we don't want to incur the side-effects of direct reclaim or compaction as well. The real fix would be to convert all callers to pass gfp flags into memdup_user() to determine the behavior they want, though. -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
