After setting the 'data' pointer (wchich is returned to the caller for
freeing later) the regmap_add_irq_chip() could still fail for various
reasons (ENOMEM, regmap_read or regmap_write failure). In such case the
memory under 'data' was freed in error path and error value was returned
but the 'data' variable was not changed.

This could lead to errors if the caller passed such 'data' to
regmap_del_irq_chip().

The 'data' pointer should be changed atomically from the caller
perspective - set it only on regmap_add_irq_chip() success.

Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
 drivers/base/regmap/regmap-irq.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 82692068d3cb..6d5d04d473f1 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -368,8 +368,6 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int 
irq_flags,
        if (!d)
                return -ENOMEM;
 
-       *data = d;
-
        d->status_buf = kzalloc(sizeof(unsigned int) * chip->num_regs,
                                GFP_KERNEL);
        if (!d->status_buf)
@@ -506,6 +504,8 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int 
irq_flags,
                goto err_domain;
        }
 
+       *data = d;
+
        return 0;
 
 err_domain:
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to