Normally, its a good practice to free resources in the reverse order in
which they are allocated, so that all the dependencies can be sorted out
properly.
This is true while creating/destroying devices as well. For example
consider this scenario (I faced a crash with control protocol due to
this). For a new module, we will first create a bundle+connection for
the control cport and then create other bundles/connections after
parsing manifest.
And while destroying interface on module hot unplug, we are removing the
devices in the order they are added. And so the bundle/connection for
the control cport are destroyed first. But, control cport was still
required while destroying other bundles/connections.
To solve this problem, lets destroy the resources in the reverse order
in which they are added.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
}
spin_lock_irq(&gb_bundles_lock);
- list_add_tail(&bundle->links, &intf->bundles);
+ list_add(&bundle->links, &intf->bundles);
spin_unlock_irq(&gb_bundles_lock);
return bundle;
"protocol 0x%02hhx handler not found\n", protocol_id);
spin_lock_irq(&gb_connections_lock);
- list_add_tail(&connection->hd_links, &hd->connections);
- list_add_tail(&connection->bundle_links, &bundle->connections);
+ list_add(&connection->hd_links, &hd->connections);
+ list_add(&connection->bundle_links, &bundle->connections);
spin_unlock_irq(&gb_connections_lock);
atomic_set(&connection->op_cycle, 0);
}
spin_lock_irq(&gb_interfaces_lock);
- list_add_tail(&intf->links, &hd->interfaces);
+ list_add(&intf->links, &hd->interfaces);
spin_unlock_irq(&gb_interfaces_lock);
return intf;