topic Possible kernel memory corruption in eglSwapBuffers for frame bufffer device. in i.MX Processors

Possible kernel memory corruption in eglSwapBuffers for frame bufffer device.

tonydefeo — Fri, 04 Sep 2015 23:36:14 GMT

Hi,

We are running a yocto build on an imx6 system based around the Wandboard module with a custom carrier board.

Using openGL with a framebuffer device (no X), imx-gpu-viv-1_5.0.11.p4.5.

What I am seeing is that when we issue an eglSwapBuffers call, 0's are being written several hundred bytes past the end of the framebuffer, into the next memory page.

In this particular case, this page was allocated by the kernel slub allocator, and contains tty driver data structures. This corruption of the kernel data structures eventually leads to a kernel crash.

Has anyone else seen any issues like this? Since I don't have source for libEGL-fb.so, I can't debug it any further!

I need a fix, or a work around for this!

Any help would be appreciated!

Thanks,

Tony

Re: Possible kernel memory corruption in eglSwapBuffers for frame bufffer device.

Bio_TICFSL — Tue, 08 Sep 2015 16:09:43 GMT

Hi Anthony,

If eglSwapbuffers is writting bytes on the next memory page this should be a bug in the vivante driver, rendering activity for one frame has very clearly defined demarcation of what is one frame and what is the next.

However in case of your issue, this is not reproducible in the Yocto BSP that Freescale provides, Please provide a sample code to reproduce in our side and get the fix from the developers team, GPU drivers are propietary and are just provided in binary form. or please send a email to support team: support@freescale.com

Regards

Re: Possible kernel memory corruption in eglSwapBuffers for frame bufffer device.

tonydefeo — Tue, 08 Sep 2015 20:06:17 GMT

Hi,

Thanks for the response. I have further narrowed down the cause of the problem, and can now work around it.

I will give you the details of what I have found, and include a simple test program that should reproduce the problem.

The problem only arises when creating a full screen window with fbCreateWindow(), and specifying a Y position that is NOT a multiple of 4.

For example, if the screen resolution is 1360x768:

fbCreateWindow(native_display, 0, 0, 1360, 768); // OK

fbCreateWindow(native_display, 0, 1, 1360, 768); // PROBLEM

fbCreateWindow(native_display, 0, 2, 1360, 768); // PROBLEM

fbCreateWindow(native_display, 0, 3, 1360, 768); // PROBLEM

fbCreateWindow(native_display, 0, 4, 1360, 768); // OK

etc....

When you set up the window this way, you don't even need to render anything, just calling eglSwapBuffers() will cause a write beyond the end of the allocated frame buffer. The overwrite is a multiple of SCREEN WIDTH bytes beyond the end of the buffer.

In my case, I was (unnecessarily) specifying a y offset of 1. I am now specifying a y offset of 0 and all is well.

So this really appears to be a fringe case, but, in my opinion, the driver should never write beyond the end of the allocated frame buffer regardless of what the application tells it.

Depending on what (kernel allocated) memory is mapped past the end of the frame buffer, the failure mode will vary, but sooner or later a kernel panic will occur.

Hope this helps, thanks,

Tony