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
| ||
|
Date: Fri, 6 Mar 2020 13:12:10 +0200 From: Laurentiu Palcu <laurentiu.palcu@....nxp.com> To: Philipp Zabel <p.zabel@...gutronix.de> Cc: Lucas Stach <l.stach@...gutronix.de>, Laurentiu Palcu <laurentiu.palcu@....com>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>, NXP Linux Team <linux-imx@....com>, linux-arm-kernel@...ts.infradead.org, agx@...xcpu.org, lukas@...mn.com, linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org Subject: Re: [PATCH v3 2/4] drm/imx: Add initial support for DCSS on iMX8MQ Hi Philipp, On Fri, Mar 06, 2020 at 11:20:51AM +0100, Philipp Zabel wrote: > Hi Laurentiu, > > On Fri, 2020-03-06 at 11:58 +0200, Laurentiu Palcu wrote: > > On Wed, Feb 26, 2020 at 02:19:11PM +0100, Lucas Stach wrote: > [...] > > > > +/* This function will be called from interrupt context. */ > > > > +void dcss_scaler_write_sclctrl(struct dcss_scaler *scl) > > > > +{ > > > > + int chnum; > > > > + > > > > + for (chnum = 0; chnum < 3; chnum++) { > > > > + struct dcss_scaler_ch *ch = &scl->ch[chnum]; > > > > + > > > > + if (ch->scaler_ctrl_chgd) { > > > > + dcss_ctxld_write_irqsafe(scl->ctxld, scl->ctx_id, > > > > + ch->scaler_ctrl, > > > > + ch->base_ofs + > > > > + DCSS_SCALER_CTRL); > > > > > > Why is this using the _irqsafe variant without any locking? Won't this > > > lead to potential internal state corruption? dcss_ctxld_write is using > > > the _irqsave locking variants, so it fine with being called from IRQ > > > context. > > > > This is only called from __dcss_ctxld_enable() which is already protected > > by lock/unlock in dcss_ctxld_kick(). > > You could add a lockdep_assert_held() line to the top of this function > to make it clear this depends on the lock being held. Thanks for the suggestion. Will add a check. Thanks, laurentiu
Powered by blists - more mailing lists