From: Subash Abhinov Kasiviswanathan <subas...@codeaurora.org>
Date: Mon, 21 Aug 2017 16:36:59 -0600
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/Makefile
> b/drivers/net/ethernet/qualcomm/rmnet/Makefile
> new file mode 100644
> index 0000000..1c43e2f
> --- /dev/null
> +++ b/drivers/net/ethernet/qualcomm/rmnet/Makefile
> @@ -0,0 +1,12 @@
> +#
> +# Makefile for the RMNET module
> +#
> +
> +rmnet-y := rmnet_config.o
> +rmnet-y += rmnet_vnd.o
> +rmnet-y += rmnet_handlers.o
> +rmnet-y += rmnet_map_data.o
> +rmnet-y += rmnet_map_command.o
> +obj-$(CONFIG_RMNET) += rmnet.o
> +
> +CFLAGS_rmnet.o := -I$(src)
You do not need this CFLAGS rule, the local include files are included
using "" double quotes so it uses the local directory always.
> +static void rmnet_free_later(struct work_struct *work)
> +{
> + struct rmnet_free_work *fwork;
> +
> + fwork = container_of(work, struct rmnet_free_work, work);
> +
> + rtnl_lock();
> + rmnet_delink(fwork->rmnet_dev, NULL);
> + rtnl_unlock();
> +
> + kfree(fwork);
> +}
This is racy and doesn't work properly.
When you schedule this work, the RTNL mutex is dropped. Meanwhile
another request can come in the associate this device.
Your work function will still run and erroneously unlink the object.
Furthermore, during this time that the RTNL mutex is dropped, people
will see the unassociated device in the lists.
You have to atomically remove the object from all possible locations
which provide external visibility of that object, before the RTNL
mutex is dropped.
So you can defer the freeing, but you cannot defer the unlink
operation.
You probably need to move to RCU as well in order for all of this to
work properly since scans of the lists occur in the data path which
is completely asynchronous and not protected by the RTNL mutex.
