staging: ozwpan: fix potential race in oz_pd_destroy
If two routines A and B call oz_pd_destroy() in parallel, there could be
a race condition they are both able to get through to the point of increasing
pd_destroy_scheduled. For example, routine A reads pd_destroy_scheduled
and its value is zero, right after that routine B reads pd_destroy_scheduled
as well and its value is still zero. Then routine A and B will both be able
to go ahead to increase pd_destroy_scheduled and then schedule the oz_pd_free
workitem, causing the reduplicate oz_pd_free.
To fix that, using spinlock instead of atomic operation. Also do some cleanup
of the redundant code and fix a potential NULL pointer error in oz_pd_alloc().
Bug
200014887
Bug
1522180
Change-Id: I777c39298600c273b6f55bbaf524edd597c80c57
Signed-off-by: Allen Yu <alleny@nvidia.com>
Signed-off-by: Vinayak Pane <vpane@nvidia.com>
Reviewed-on: http://git-master/r/432519
GVS: Gerrit_Virtual_Submit
Tested-by: Kevin Bruckert <kbruckert@nvidia.com>
Reviewed-by: Mitch Luban <mluban@nvidia.com>