This patch fixes a memory leak that appears when caam_jr module is unloaded.
Cc: <[email protected]> # 3.13+
Signed-off-by: Cristian Stoica <[email protected]>
---
drivers/crypto/caam/jr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 1d80bd3..f127f86 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -117,6 +117,7 @@ static int caam_jr_remove(struct platform_device *pdev)
if (ret)
dev_err(jrdev, "Failed to shut down job ring\n");
irq_dispose_mapping(jrpriv->irq);
+ kfree(jrpriv);
return ret;
}
--
1.8.3.1
This patch fixes a memory leak that appears when caam_jr module is unloaded.
Cc: <[email protected]> # 3.13+
Signed-off-by: Cristian Stoica <[email protected]>
---
drivers/crypto/caam/jr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 1d80bd3..f127f86 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -117,6 +117,7 @@ static int caam_jr_remove(struct platform_device *pdev)
if (ret)
dev_err(jrdev, "Failed to shut down job ring\n");
irq_dispose_mapping(jrpriv->irq);
+ kfree(jrpriv);
Can you replace kmalloc for jrpriv with devm_kzalloc() instead?
This will fix leaks for jrpriv in other places as well and make code compact.
return ret;
}
--
1.8.3.1
--
This patch fixes a memory leak that appears when caam_jr module is unloaded.
Cc: <[email protected]> # 3.13+
Signed-off-by: Cristian Stoica <[email protected]>
---
drivers/crypto/caam/jr.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 1d80bd3..e0b91fc 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -453,7 +453,7 @@ static int caam_jr_probe(struct platform_device *pdev)
int error;
jrdev = &pdev->dev;
- jrpriv = kmalloc(sizeof(struct caam_drv_private_jr),
+ jrpriv = devm_kzalloc(jrdev, sizeof(struct caam_drv_private_jr),
GFP_KERNEL);
if (!jrpriv)
return -ENOMEM;
@@ -487,10 +487,8 @@ static int caam_jr_probe(struct platform_device *pdev)
/* Now do the platform independent part */
error = caam_jr_init(jrdev); /* now turn on hardware */
- if (error) {
- kfree(jrpriv);
+ if (error)
return error;
- }
jrpriv->dev = jrdev;
spin_lock(&driver_data.jr_alloc_lock);
--
1.8.3.1
On Thu, 3 Jul 2014 15:07:50 +0300
Cristian Stoica <[email protected]> wrote:
> This patch fixes a memory leak that appears when caam_jr module is unloaded.
>
> Cc: <[email protected]> # 3.13+
> Signed-off-by: Cristian Stoica <[email protected]>
> ---
> drivers/crypto/caam/jr.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
> index 1d80bd3..e0b91fc 100644
> --- a/drivers/crypto/caam/jr.c
> +++ b/drivers/crypto/caam/jr.c
> @@ -453,7 +453,7 @@ static int caam_jr_probe(struct platform_device *pdev)
> int error;
>
> jrdev = &pdev->dev;
> - jrpriv = kmalloc(sizeof(struct caam_drv_private_jr),
> + jrpriv = devm_kzalloc(jrdev, sizeof(struct caam_drv_private_jr),
> GFP_KERNEL);
alignment. Also, why are we replacing a _m_alloc with a _z_alloc?
Please start using get_maintainer.pl.
Thanks,
Kim
On Friday, July 04, 2014 at 12:54:06 AM, Kim Phillips wrote:
> On Thu, 3 Jul 2014 15:07:50 +0300
>
> Cristian Stoica <[email protected]> wrote:
> > This patch fixes a memory leak that appears when caam_jr module is
> > unloaded.
> >
> > Cc: <[email protected]> # 3.13+
> > Signed-off-by: Cristian Stoica <[email protected]>
> > ---
> >
> > drivers/crypto/caam/jr.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
> > index 1d80bd3..e0b91fc 100644
> > --- a/drivers/crypto/caam/jr.c
> > +++ b/drivers/crypto/caam/jr.c
> > @@ -453,7 +453,7 @@ static int caam_jr_probe(struct platform_device
> > *pdev)
> >
> > int error;
> >
> > jrdev = &pdev->dev;
> >
> > - jrpriv = kmalloc(sizeof(struct caam_drv_private_jr),
> > + jrpriv = devm_kzalloc(jrdev, sizeof(struct caam_drv_private_jr),
> >
> > GFP_KERNEL);
>
> alignment. Also, why are we replacing a _m_alloc with a _z_alloc?
I am fine with replacing kmalloc with kzalloc in this context.
Best regards,
Marek Vasut