[Intel-gfx] [PATCH 1/1] drm/i915: gracefully reject mmap of huge tiled objects

[Xiong, James]

Thanks,
James

-----Original Message-----
From: Chris Wilson [mailto:chris.ickle.wilson at gmail.com] On Behalf Of Chris Wilson
Sent: Friday, July 1, 2016 12:25 AM
To: Xiong, James <james.xiong at intel.com>
Cc: intel-gfx at lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: gracefully reject mmap of huge tiled objects

On Thu, Jun 30, 2016 at 05:04:42PM -0700, James Xiong wrote:
> From: "Xiong, James" <james.xiong at intel.com>
> 
> currently mmap of a tiled object that is larger than mappable aperture 
> is rejected in fault handler, and causes sigbus error and application 
> crash.

Please note that SIGBUS can be returned at any time. If your application doesn't handle it, please fix that.
[JX] I agree, the way I put it like it's a bug is wrong, it's okay to return sigbus in i915 fault handler.

It's a common practice that an application validates a pointer then accesses it directly, in case of SIGBUS,
there is not much signal handler can do other than clearing up before the application aborts(please
correct me if I am wrong). I have seen people use longjump/sigaction to handle sigbus but it has problems:
only be able to jump within the current function, reentrancy etc,etc,. makes it impractical to apply for all accesses.

And sometime the app wants to be able to continue in case of SIGBUG, for example: one test case fails because of
 the buffer size and SIGBUS, with this change, the app is able to either reduce buffer size, re-run test or continue
with the next test. The change helps with these cases.

 Another thing is that when mmap is called to map a tiled/250M+ obj to user space, i915 knows it doesn't have enough
space, shouldn't ENOSPC be returned right there and then? 
> This commit rejects it in mmap instead so that the client has chance 
> to handle the failure.

Wrong. Please review the patches to fix this correctly.
-Chris

--
Chris Wilson, Intel Open Source Technology Centre