lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 14 Nov 2017 11:44:41 -0800
From:   Eric Anholt <eric@...olt.net>
To:     Stefan Schake <stschake@...il.com>
Cc:     dri-devel@...ts.freedesktop.org,
        linux-rpi-kernel@...ts.infradead.org,
        David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled

Stefan Schake <stschake@...il.com> writes:

> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt <eric@...olt.net> wrote:
>> Stefan Schake <stschake@...il.com> writes:
>>
>>> The overflow mem work callback vc4_overflow_mem_work reenables its
>>> associated interrupt upon completion. To ensure all interrupts are disabled
>>> when we return from vc4_irq_uninstall, we need to disable it again if
>>> cancel_work_sync indicated pending work.
>>
>> Is there a reason we need the interrupts disabled at the V3D level while
>> we have the IRQ disabled at the irqchip level?  Once we re-enable at the
>> irqchip, we immediately V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS) anyway.
>
> irqchip will mask it in the ARM interrupt controller, so we will certainly never
> see an interrupt. I'm not sure on the exact guarantees V3D_INTENA and
> V3D_INTCTL make - does the state in INTENA affect if V3D will signal an
> interrupt in INTCTL? We're not currently clearing the latter in postinstall.

INTENA/INTDIS writes update the state of the single register that
controls which bits of INTCTL get ORed together to raise the interrupt
outside the V3D block.

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ