share_pool: Fix memleak of concurrent sp_free and sp_group_add_task

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4EUVI


CVE: NA

-------------------------------------------------

We found a concurrency problem of sp_group_add_task and sp_free which
lead to memory leak.

After process A calls __sp_free and vfs_fallocate but before calling
__sp_area_drop, process B is being added to the same group by a manager
process, the *dead* spa freed by sp_free may be mapped into process B
again, then do_mm_populate is called.

When sp_group_add_task is finished, this spa is dropped and can't be
seen in /proc/sharepool/spa_stat, but the memory of spa still reside in
the group. It can only be freed when the group is dead.

To fix the problem, we add a member is_dead in spa. We can access it
when spg->rw_lock is held. This may sound a little strange if not
realizing the life cycle of spa has a direct relation with sp group.

Suggested-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: Tang Yizhou <tangyizhou@huawei.com>
Reviewed-by: Ding Tianhong <dingtianhong@huwei.com>
Reviewed-by: 为珑 陈 <chenweilong@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>