[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a04_Xu+qv-Smtpnbw8iTkfWqiYP9+YE5pA_T+gsNGVVcw@mail.gmail.com>
Date: Tue, 8 Jun 2021 11:08:01 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Mark Rutland <mark.rutland@....com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Catalin Marinas <catalin.marinas@....com>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>, Emma Anholt <emma@...olt.net>,
Maxime Ripard <maxime@...no.tech>,
Will Deacon <will@...nel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] drm/vc4: fix vc4_atomic_commit_tail() logic
On Tue, Jun 8, 2021 at 10:56 AM Mark Rutland <mark.rutland@....com> wrote:
>
> In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and
> attempt to wait on any channels which are still in use. When we iterate
> over the CRTCs, we have:
>
> * `i` - the index of the CRTC
> * `channel` - the channel a CRTC is using
>
> When we check the channel state, we consult:
>
> old_hvs_state->fifo_state[channel].in_use
>
> ... but when we wait for the channel, we erroneously wait on:
>
> old_hvs_state->fifo_state[i].pending_commit
>
> ... rather than:
>
> old_hvs_state->fifo_state[channel].pending_commit
>
> ... and this bogus access has been observed to result in boot-time hangs
> on some arm64 configurations, and can be detected using KASAN. FIx this
> by using the correct index.
>
> I've tested this on a Raspberry Pi 3 model B v1.2 with KASAN.
...
>
> Link: https://lore.kernel.org/r/4d0c8318-bad8-2be7-e292-fc8f70c198de@samsung.com
> Link: https://lore.kernel.org/linux-arm-kernel/20210607151740.moncryl5zv3ahq4s@gilmour
> Signed-off-by: Mark Rutland <mark.rutland@....com>
> Reported-by: Marek Szyprowski <m.szyprowski@...sung.com>
> Cc: Arnd Bergmann <arnd@...db.de>
Acked-by: Arnd Bergmann <arnd@...db.de>
Powered by blists - more mailing lists