* [PATCH 0/2] dspbridge: proc: double free on error path
@ 2010-02-12 16:26 Phil Carmody
2010-02-12 16:26 ` [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle Phil Carmody
0 siblings, 1 reply; 8+ messages in thread
From: Phil Carmody @ 2010-02-12 16:26 UTC (permalink / raw)
To: omar.ramirez; +Cc: nm, linux-omap
First a bit of a cleanup of what was clearly some legacy 'handle'
usage, and then a new quicker escape route for an error path to
avoid a double free.
It's tempting to get a bit more invasive, as there's a lot of
quite dodgy looking code (e.g. casting away const) in the areas
around my changes, but they'll have to wait for another time.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle
2010-02-12 16:26 [PATCH 0/2] dspbridge: proc: double free on error path Phil Carmody
@ 2010-02-12 16:26 ` Phil Carmody
2010-02-12 16:26 ` [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths Phil Carmody
2010-02-18 23:53 ` [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle Omar Ramirez Luna
0 siblings, 2 replies; 8+ messages in thread
From: Phil Carmody @ 2010-02-12 16:26 UTC (permalink / raw)
To: omar.ramirez; +Cc: nm, linux-omap
From: Phil Carmody <ext-phil.2.carmody@nokia.com>
If there's one thing worse than systems hungarian notation,
it's misleading systems hungarian notation. And you don't
need 2 copies of the pointer.
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
---
drivers/dsp/bridge/rmgr/proc.c | 25 +++++++++++--------------
1 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 2ccbc9b..7bc1bcd 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -313,7 +313,6 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
DSP_STATUS status = DSP_EFAIL;
u32 dwAutoStart = 0; /* autostart flag */
struct PROC_OBJECT *pProcObject;
- struct PROC_OBJECT *hProcObject;
char szExecFile[MAXCMDLINELEN];
char *argv[2];
struct MGR_OBJECT *hMgrObject = NULL;
@@ -345,19 +344,18 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
GT_0trace(PROC_DebugMask, GT_1CLASS, "NTFY Created \n");
pProcObject->hDevObject = hDevObject;
pProcObject->hMgrObject = hMgrObject;
- hProcObject = pProcObject;
status = DEV_GetIntfFxns(hDevObject, &pProcObject->pIntfFxns);
if (DSP_SUCCEEDED(status)) {
status = DEV_GetWMDContext(hDevObject,
&pProcObject->hWmdContext);
if (DSP_FAILED(status)) {
- MEM_FreeObject(hProcObject);
+ MEM_FreeObject(pProcObject);
GT_0trace(PROC_DebugMask, GT_7CLASS,
"PROC_AutoStart: Failed "
"to get WMD Context \n");
}
} else {
- MEM_FreeObject(hProcObject);
+ MEM_FreeObject(pProcObject);
GT_0trace(PROC_DebugMask, GT_7CLASS,
"PROC_AutoStart: Failed to "
"get IntFxns \n");
@@ -366,7 +364,7 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
goto func_cont;
/* Stop the Device, put it into standby mode */
- status = PROC_Stop(hProcObject);
+ status = PROC_Stop(pProcObject);
if (DSP_FAILED(status))
goto func_cont;
@@ -388,9 +386,9 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
argv[0] = szExecFile;
argv[1] = NULL;
/* ...and try to load it: */
- status = PROC_Load(hProcObject, 1, (CONST char **)argv, NULL);
+ status = PROC_Load(pProcObject, 1, (CONST char **)argv, NULL);
if (DSP_SUCCEEDED(status)) {
- status = PROC_Start(hProcObject);
+ status = PROC_Start(pProcObject);
if (DSP_SUCCEEDED(status)) {
GT_0trace(PROC_DebugMask, GT_1CLASS,
"PROC_AutoStart: Processor started "
@@ -409,9 +407,9 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
"No Exec file found \n");
}
func_cont:
- kfree(hProcObject->g_pszLastCoff);
- hProcObject->g_pszLastCoff = NULL;
- MEM_FreeObject(hProcObject);
+ kfree(pProcObject->g_pszLastCoff);
+ pProcObject->g_pszLastCoff = NULL;
+ MEM_FreeObject(pProcObject);
func_end:
GT_1trace(PROC_DebugMask, GT_ENTER,
"Exiting PROC_AutoStart, status:0x%x\n", status);
@@ -1742,7 +1740,7 @@ func_end:
* This does a WMD_BRD_Stop, DEV_Destroy2 and WMD_BRD_Monitor.
* In DEV_Destroy2 we delete the node manager.
* Parameters:
- * hProcObject: Handle to Processor Object
+ * pProcObject: Pointer to Processor Object
* Returns:
* DSP_SOK: Processor placed in monitor mode.
* !DSP_SOK: Failed to place processor in monitor mode.
@@ -1751,10 +1749,9 @@ func_end:
* Ensures:
* Success: ProcObject state is PROC_IDLE
*/
-static DSP_STATUS PROC_Monitor(struct PROC_OBJECT *hProcObject)
+static DSP_STATUS PROC_Monitor(struct PROC_OBJECT *pProcObject)
{
DSP_STATUS status = DSP_EFAIL;
- struct PROC_OBJECT *pProcObject = (struct PROC_OBJECT *)hProcObject;
struct MSG_MGR *hMsgMgr;
#ifdef CONFIG_BRIDGE_DEBUG
BRD_STATUS uBrdState;
@@ -1764,7 +1761,7 @@ static DSP_STATUS PROC_Monitor(struct PROC_OBJECT *hProcObject)
DBC_Require(MEM_IsValidHandle(pProcObject, PROC_SIGNATURE));
GT_1trace(PROC_DebugMask, GT_ENTER, "Entered PROC_Monitor, args:\n\t"
- "hProcessor: 0x%x\n", hProcObject);
+ "hProcessor: 0x%x\n", pProcObject);
/* This is needed only when Device is loaded when it is
* already 'ACTIVE' */
/* Destory the Node Manager, MSG Manager */
--
1.6.0.4
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths
2010-02-12 16:26 ` [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle Phil Carmody
@ 2010-02-12 16:26 ` Phil Carmody
2010-02-17 0:24 ` Omar Ramirez Luna
2010-02-18 23:53 ` Omar Ramirez Luna
2010-02-18 23:53 ` [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle Omar Ramirez Luna
1 sibling, 2 replies; 8+ messages in thread
From: Phil Carmody @ 2010-02-12 16:26 UTC (permalink / raw)
To: omar.ramirez; +Cc: nm, linux-omap
From: Phil Carmody <ext-phil.2.carmody@nokia.com>
We free in the tail cleanup, so don't free before jumping there.
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
---
drivers/dsp/bridge/rmgr/proc.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 7bc1bcd..e89077b 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -349,13 +349,11 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
status = DEV_GetWMDContext(hDevObject,
&pProcObject->hWmdContext);
if (DSP_FAILED(status)) {
- MEM_FreeObject(pProcObject);
GT_0trace(PROC_DebugMask, GT_7CLASS,
"PROC_AutoStart: Failed "
"to get WMD Context \n");
}
} else {
- MEM_FreeObject(pProcObject);
GT_0trace(PROC_DebugMask, GT_7CLASS,
"PROC_AutoStart: Failed to "
"get IntFxns \n");
@@ -377,6 +375,10 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
"CFG_GetAutoStart DSP_FAILED \n");
goto func_cont;
}
+
+ /* paranoid - must be able to kfree this on remaining error paths */
+ pProcObject->g_pszLastCoff = NULL;
+
/* Get the default executable for this board... */
DEV_GetDevType(hDevObject, (u32 *)&devType);
pProcObject->uProcessor = devType;
@@ -406,9 +408,9 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
GT_0trace(PROC_DebugMask, GT_7CLASS, "PROC_AutoStart: "
"No Exec file found \n");
}
-func_cont:
kfree(pProcObject->g_pszLastCoff);
pProcObject->g_pszLastCoff = NULL;
+func_cont:
MEM_FreeObject(pProcObject);
func_end:
GT_1trace(PROC_DebugMask, GT_ENTER,
--
1.6.0.4
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths
2010-02-12 16:26 ` [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths Phil Carmody
@ 2010-02-17 0:24 ` Omar Ramirez Luna
2010-02-17 13:12 ` Phil Carmody
2010-02-18 23:53 ` Omar Ramirez Luna
1 sibling, 1 reply; 8+ messages in thread
From: Omar Ramirez Luna @ 2010-02-17 0:24 UTC (permalink / raw)
To: Phil Carmody; +Cc: Menon, Nishanth, linux-omap@vger.kernel.org
On 2/12/2010 10:26 AM, Phil Carmody wrote:
> From: Phil Carmody<ext-phil.2.carmody@nokia.com>
>
> We free in the tail cleanup, so don't free before jumping there.
>
> Signed-off-by: Phil Carmody<ext-phil.2.carmody@nokia.com>
> ---
[...]
> }
> +
> + /* paranoid - must be able to kfree this on remaining error paths */
> + pProcObject->g_pszLastCoff = NULL;
> +
do we need this? afaik it should be NULL at this point, because of
kmalloc + memset (which btw should be replaced by kzalloc).
i.e:
MEM_AllocObject(pProcObject, struct PROC_OBJECT, PROC_SIGNATURE);
-> MEM_Calloc(sizeof(Obj), MEM_NONPAGED);
-> pMem = kmalloc(...)
if (pMem)
memset(pMem, 0, cBytes);
> /* Get the default executable for this board... */
> DEV_GetDevType(hDevObject, (u32 *)&devType);
> pProcObject->uProcessor = devType;
[...]
Regards,
Omar
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths
2010-02-17 0:24 ` Omar Ramirez Luna
@ 2010-02-17 13:12 ` Phil Carmody
2010-02-17 15:52 ` Omar Ramirez Luna
0 siblings, 1 reply; 8+ messages in thread
From: Phil Carmody @ 2010-02-17 13:12 UTC (permalink / raw)
To: ext Omar Ramirez Luna; +Cc: Menon, Nishanth, linux-omap@vger.kernel.org
On 17/02/10 01:24 +0100, ext Omar Ramirez Luna wrote:
> On 2/12/2010 10:26 AM, Phil Carmody wrote:
> > From: Phil Carmody<ext-phil.2.carmody@nokia.com>
> >
> > We free in the tail cleanup, so don't free before jumping there.
> >
> > Signed-off-by: Phil Carmody<ext-phil.2.carmody@nokia.com>
> > ---
>
> [...]
> > }
> > +
> > + /* paranoid - must be able to kfree this on remaining error paths */
> > + pProcObject->g_pszLastCoff = NULL;
> > +
>
> do we need this? afaik it should be NULL at this point, because of
> kmalloc + memset (which btw should be replaced by kzalloc).
I suspected it wasn't. I confess I was a little bit rushed when
looking at that.
> i.e:
> MEM_AllocObject(pProcObject, struct PROC_OBJECT, PROC_SIGNATURE);
> -> MEM_Calloc(sizeof(Obj), MEM_NONPAGED);
> -> pMem = kmalloc(...)
> if (pMem)
> memset(pMem, 0, cBytes);
i.e. kzalloc().
> > /* Get the default executable for this board... */
> > DEV_GetDevType(hDevObject, (u32 *)&devType);
> > pProcObject->uProcessor = devType;
> [...]
>
> Regards,
I can resend without, if you like, whatever's simplest for you.
Phil
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths
2010-02-17 13:12 ` Phil Carmody
@ 2010-02-17 15:52 ` Omar Ramirez Luna
0 siblings, 0 replies; 8+ messages in thread
From: Omar Ramirez Luna @ 2010-02-17 15:52 UTC (permalink / raw)
To: Phil Carmody; +Cc: Menon, Nishanth, linux-omap@vger.kernel.org
On 2/17/2010 7:12 AM, Phil Carmody wrote:
> On 17/02/10 01:24 +0100, ext Omar Ramirez Luna wrote:
>> On 2/12/2010 10:26 AM, Phil Carmody wrote:
>>> From: Phil Carmody<ext-phil.2.carmody@nokia.com>
>>>
>>> We free in the tail cleanup, so don't free before jumping there.
>>>
>>> Signed-off-by: Phil Carmody<ext-phil.2.carmody@nokia.com>
>>> ---
>>
>> [...]
>>> }
>>> +
>>> + /* paranoid - must be able to kfree this on remaining error paths */
>>> + pProcObject->g_pszLastCoff = NULL;
>>> +
>>
>> do we need this? afaik it should be NULL at this point, because of
>> kmalloc + memset (which btw should be replaced by kzalloc).
>
> I suspected it wasn't. I confess I was a little bit rushed when
> looking at that.
>
>> i.e:
>> MEM_AllocObject(pProcObject, struct PROC_OBJECT, PROC_SIGNATURE);
>> -> MEM_Calloc(sizeof(Obj), MEM_NONPAGED);
>> -> pMem = kmalloc(...)
>> if (pMem)
>> memset(pMem, 0, cBytes);
>
> i.e. kzalloc().
>
>>> /* Get the default executable for this board... */
>>> DEV_GetDevType(hDevObject, (u32 *)&devType);
>>> pProcObject->uProcessor = devType;
>> [...]
>>
>> Regards,
>
> I can resend without, if you like, whatever's simplest for you.
>
No worries, I'll remove from original.
Regards,
Omar
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle
2010-02-12 16:26 ` [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle Phil Carmody
2010-02-12 16:26 ` [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths Phil Carmody
@ 2010-02-18 23:53 ` Omar Ramirez Luna
1 sibling, 0 replies; 8+ messages in thread
From: Omar Ramirez Luna @ 2010-02-18 23:53 UTC (permalink / raw)
To: Phil Carmody; +Cc: Menon, Nishanth, linux-omap@vger.kernel.org
On 2/12/2010 10:26 AM, Phil Carmody wrote:
> From: Phil Carmody<ext-phil.2.carmody@nokia.com>
>
> If there's one thing worse than systems hungarian notation,
> it's misleading systems hungarian notation. And you don't
> need 2 copies of the pointer.
>
> Signed-off-by: Phil Carmody<ext-phil.2.carmody@nokia.com>
> ---
> drivers/dsp/bridge/rmgr/proc.c | 25 +++++++++++--------------
> 1 files changed, 11 insertions(+), 14 deletions(-)
>
Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Pushed to dspbridge.
- omar
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths
2010-02-12 16:26 ` [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths Phil Carmody
2010-02-17 0:24 ` Omar Ramirez Luna
@ 2010-02-18 23:53 ` Omar Ramirez Luna
1 sibling, 0 replies; 8+ messages in thread
From: Omar Ramirez Luna @ 2010-02-18 23:53 UTC (permalink / raw)
To: Phil Carmody; +Cc: Menon, Nishanth, linux-omap@vger.kernel.org
On 2/12/2010 10:26 AM, Phil Carmody wrote:
> From: Phil Carmody<ext-phil.2.carmody@nokia.com>
>
> We free in the tail cleanup, so don't free before jumping there.
>
> Signed-off-by: Phil Carmody<ext-phil.2.carmody@nokia.com>
> ---
> drivers/dsp/bridge/rmgr/proc.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
Removed NULL assignment as agreed.
Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Pushed to dspbridge.
- omar
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-02-18 23:53 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-12 16:26 [PATCH 0/2] dspbridge: proc: double free on error path Phil Carmody
2010-02-12 16:26 ` [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle Phil Carmody
2010-02-12 16:26 ` [PATCH 2/2] dspbridge: proc: fix a double-free on 2 error paths Phil Carmody
2010-02-17 0:24 ` Omar Ramirez Luna
2010-02-17 13:12 ` Phil Carmody
2010-02-17 15:52 ` Omar Ramirez Luna
2010-02-18 23:53 ` Omar Ramirez Luna
2010-02-18 23:53 ` [PATCH 1/2] dspbridge: proc: it's a pointer, not a handle Omar Ramirez Luna
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox