diff options
| author | John Stultz <john.stultz@linaro.org> | 2020-09-15 20:44:57 +0000 |
|---|---|---|
| committer | Yongqin Liu <yongqin.liu@linaro.org> | 2020-10-20 13:09:11 +0800 |
| commit | 49eaa79212d5c6a6c2fcf116398e79fd8ff178e3 (patch) | |
| tree | d75927fe5959cd2597b1eea76828be08251cfc23 | |
| parent | d67be46388c117f383939676092e4d246ca62f34 (diff) | |
| download | hikey-modules-49eaa79212d5c6a6c2fcf116398e79fd8ff178e3.tar.gz | |
MALI: Avoid null pointer deref
So the utgard driver for hikey hasn't ever really been
configured to actually use the dmabuf fences.
This results in the sync fence to not properly have
the fence ops configured, and due to changes in the
userland usage, we're now hitting null pointer
dereferences.
I took a brief swing at trying to properly enable
CONFIG_MALI_DMA_BUF_FENCE=y and reworking the use
of the old reservation_objects but even after doing
that I was still hitting crashes in mali_timeline.c
So for now, lets just skip the fence call here if it
is null and avoid the crash.
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit bb4992ede5d6fe6db8398e043e8d93f6d4348e2c)
Change-Id: I0a046fc7a19e4e52375ae5794bddfcc7fea3fd6a
| -rw-r--r-- | utgard/common/mali_timeline_fence_wait.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/utgard/common/mali_timeline_fence_wait.c b/utgard/common/mali_timeline_fence_wait.c index 1ab13f5..a25f755 100644 --- a/utgard/common/mali_timeline_fence_wait.c +++ b/utgard/common/mali_timeline_fence_wait.c @@ -113,7 +113,8 @@ static mali_bool mali_timeline_fence_wait_check_status(struct mali_timeline_syst #elif LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 0) if (0 < atomic_read(&sync_fence->status)) { #else - if (0 == sync_fence->fence->ops->signaled(sync_fence->fence)) { + if (sync_fence->fence->ops->signaled && + (0 == sync_fence->fence->ops->signaled(sync_fence->fence))) { #endif ret = MALI_FALSE; |