Hi, On Thu, 2010-02-04 at 22:17 +0100, ext Omar Ramirez Luna wrote: > From: Ernest Ramos Falcon <erne...@ti.com> > > This patch adds a check before calling Proc_Detach, otherwise > in case a failure occurs on PROC_Attach and hProcessor is > invalid when the userspace task closes its handle, unexpected > behavior might be seen as this pointer is dereferenced in > PROC_Detach. > > Signed-off-by: Ernest Ramos Falcon <erne...@ti.com> > --- > drivers/dsp/bridge/rmgr/drv_interface.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c > b/drivers/dsp/bridge/rmgr/drv_interface.c > index 32aff66..b0f0d93 100644 > --- a/drivers/dsp/bridge/rmgr/drv_interface.c > +++ b/drivers/dsp/bridge/rmgr/drv_interface.c > @@ -539,7 +539,8 @@ static int bridge_release(struct inode *ip, struct file > *filp) > pr_ctxt = filp->private_data; > flush_signals(current); > DRV_RemoveAllResources(pr_ctxt); > - PROC_Detach(pr_ctxt); > + if (pr_ctxt->hProcessor) > + PROC_Detach(pr_ctxt); > MEM_Free(pr_ctxt); > > filp->private_data = NULL;
I guess PROC_Detach already checks for a valid hProcessor handle! Why we need this check here again? Also if you go ahead with this patch, then how are you going to cover a use case where userspace application calls PROC_Attach() which fails, but without checking the failure userspace application calls PROC_Detach()! Cheers, Ameya. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
