On 2017年01月23日 16:30, Peter Rosin wrote:
On 2017-01-23 03:21, Qi Hou wrote:
Refcount of of_node is increased with of_node_get() in i2c_mux_add_adapter().
It must be decreased with of_node_put() in i2c_mux_del_adapters().
Signed-off-by: Qi Hou <qi.hou@xxxxxxxxxxxxx>
Reviewed-by: Zhang Xiao <xiao.zhang@xxxxxxxxxxxxx>
Acked-by: Bruce Ashfield <bruce.ashfield@xxxxxxxxxxxxx>
---
drivers/i2c/i2c-mux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 83768e8..d7ebbfb 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -437,6 +437,7 @@ void i2c_mux_del_adapters(struct i2c_mux_core *muxc)
sysfs_remove_link(&muxc->dev->kobj, symlink_name);
sysfs_remove_link(&priv->adap.dev.kobj, "mux_device");
+ of_node_put(adap->dev.of_node);
I'd feel more comfortable if the node was put after the i2c_del_adapter
call. The current patch invites use-after-free. Unfortunately (for us)
i2c_del_adapter zeros out the .dev member (isn't that a bit dubious?) of
the adapter which means that the of_node has to be kept in a temporary.
Yes, it is ridiculous to invite use-after-free, I considered this before.
It is good to put of_node in a temporary.
What about ?
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index d7ebbfb..cd5c2f2 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -429,6 +429,7 @@ void i2c_mux_del_adapters(struct i2c_mux_core *muxc)
while (muxc->num_adapters) {
struct i2c_adapter *adap =
muxc->adapter[--muxc->num_adapters];
struct i2c_mux_priv *priv = adap->algo_data;
+ struct device_node *of = adap->dev.of_node;
muxc->adapter[muxc->num_adapters] = NULL;
@@ -437,8 +438,8 @@ void i2c_mux_del_adapters(struct i2c_mux_core *muxc)
sysfs_remove_link(&muxc->dev->kobj, symlink_name);
sysfs_remove_link(&priv->adap.dev.kobj, "mux_device");
- of_node_put(adap->dev.of_node);
i2c_del_adapter(adap);
+ of_node_put(of);
kfree(priv);
}
}
Cheers,
peda
i2c_del_adapter(adap);
kfree(priv);
}
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html