From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2() Date: Fri, 06 Apr 2012 20:40:12 +0100 Message-ID: <1333741246_275838@CP5-2952> References: <1333717099-32679-1-git-send-email-xi.wang@gmail.com> <1333719431_271283@CP5-2952> <1333720475_271533@CP5-2952> <5065822E-8C69-442E-A59C-98D6C27B289D@gmail.com> <1333723480_272185@CP5-2952> <507CC69B-BD9C-421B-9107-B3284BEB116E@gmail.com> Return-path: In-Reply-To: <507CC69B-BD9C-421B-9107-B3284BEB116E@gmail.com> Sender: linux-kernel-owner@vger.kernel.org To: Xi Wang Cc: Keith Packard , Daniel Vetter , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang wrote: > On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote: > > > That I agreed with, I just disagree with how you chose to handle it. > > Rather than continue on and attempt to vmalloc a large array we should > > just fail the ioctl with EINVAL. > > Why an attempt to vmalloc? The overflow check in drm_malloc_ab() > will simply return NULL and fail the ioctl with -ENOMEM. It's an invalid value for the ioctl and should be treated as such, not making ENOMEM more ambiguous. -Chris -- Chris Wilson, Intel Open Source Technology Centre