linux-kernel - Re: [PATCH v3 2/4] drm: Add support for ARM's HDLCD controller.

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]

Message-ID: <20151203100021.GD972@e106497-lin.cambridge.arm.com>
Date:	Thu, 3 Dec 2015 10:00:21 +0000
From:	Liviu Dudau <Liviu.Dudau@....com>
To:	Daniel Stone <daniel@...ishbar.org>
Cc:	David Airlie <airlied@...ux.ie>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Sudeep Holla <sudeep.holla@....com>,
	Jon Medhurst <tixy@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Rob Herring <robh@...nel.org>,
	Russell King <rmk+kernel@....linux.org.uk>,
	devicetree <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>, Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Punit Agrawal <punit.agrawal@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	DRI devel <dri-devel@...ts.freedesktop.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Robin Murphy <robin.murphy@....com>,
	LAKML <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 2/4] drm: Add support for ARM's HDLCD controller.

On Wed, Dec 02, 2015 at 05:21:44PM +0000, Daniel Stone wrote:
> Hi Liviu,

Hi Daniel,

> 
> On 2 December 2015 at 12:23, Liviu Dudau <Liviu.Dudau@....com> wrote:
> > +       if (irq_status & HDLCD_INTERRUPT_VSYNC) {
> > +               unsigned long flags;
> > +
> > +               drm_handle_vblank(drm, 0);
> > +
> > +               spin_lock_irqsave(&drm->event_lock, flags);
> > +               if (hdlcd->event) {
> > +                       drm_send_vblank_event(drm, hdlcd->event->pipe, hdlcd->event);
> > +                       drm_crtc_vblank_put(&hdlcd->crtc);
> > +                       hdlcd->event = NULL;
> > +               }
> > +               spin_unlock_irqrestore(&drm->event_lock, flags);
> > +       }
> 
> As with VC4 and Rockchip, you're missing a ->preclose handler in your
> drm_drv, to make sure that you don't try to send events to a dead
> client (which causes an OOPS):
> https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7
> (and its parent)
 
Thanks for reviewing this!

I do acknowledge your concerns and you might correct my understanding on
how atomic DRM works, but I believe in this case we should be safe. The
event stored in hdlcd->event is taken out of the crtc->state->event during
the crtc->atomic_begin() callback. If the client is dead the callback should
not be called, so that's how we avoid the OOPS.

> Also, is there anything preventing clients from submitting multiple
> pageflips before the event is sent? I couldn't see anything from a
> quick look, so you could have the situation of:
>   - client submits pageflip, event 1 stored to hdlcd->event
>   - client submits pageflip, event 2 stored to hdlcd->event
>   - vblank arrives, event 2 is sent
>   - event 1 has disappeared and been leaked

As for multiple events being submitted before vsync interrupt happening: given
that the event is plucked out of the crtc->state, is that possible? And if so,
is there a case where having the later event overwrite the earlier one a desired
outcome?

> 
> Cheers,
> Daniel
> 

Best regards,
Liviu

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/