staging: lustre: improve LNet clean up code and API
This patch addresses a set of related issues: LU-5568, LU-5734, LU-5839, LU-5849, LU-5850. Create the local lnet_startup_lndni() API. This function starts up one LND. lnet_startup_lndnis() calls this function in a loop on every ni in the list passed in. lnet_startup_lndni() is responsible for cleaning up after itself in case of failure. It calls lnet_free_ni() if the ni fails to start. It calls lnet_shutdown_lndni() if it successfully called the lnd startup function, but fails later on. lnet_startup_lndnis() also cleans up after itself. If lnet_startup_lndni() fails then lnet_shutdown_lndnis() is called to clean up all nis that might have been started, and then free the rest of the nis on the list which have not been started yet. To facilitate the above changes lnet_dyn_del_ni() now manages the ping info. It calls lnet_shutdown_lndni(), to shutdown the NI. lnet_shutdown_lndni() is no longer an exposed API and doesn't manage the ping info, making it callable from lnet_startup_lndni() as well. There are two scenarios for calling lnet_startup_lndni() 1. from lnet_startup_lndnis() If lnet_startup_lndni() fails it requires to shutdown the ni without doing anything with the ping information as it hasn't been created yet. 2. from lnet_dyn_add_ni() As above it will shutdown the ni, and then lnet_dyn_add_ni() will take care of managing the ping info The second part of this change is to ensure that the LOLND is not added by lnet_parse_networks(), but the caller which needs to do it (IE: LNetNIInit) This change ensures that lnet_dyn_add_ni() need only check if there is only one net that's being added, if not then it frees everything, otherwise it proceeds to startup the requested net. Signed-off-by: Amir Shehata <amir.shehata@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5734 Reviewed-on: http://review.whamcloud.com/12658Reviewed-by: Liang Zhen <liang.zhen@intel.com> Reviewed-by: Isaac Huang <he.huang@intel.com> Reviewed-by: James Simmons <uja.ornl@gmail.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment