Whamcloud - gitweb
LU-12225 obdclass: fix race access vs removal of jobid_hash 63/34763/5
authorWang Shilong <wshilong@ddn.com>
Mon, 29 Apr 2019 12:46:47 +0000 (20:46 +0800)
committerOleg Drokin <green@whamcloud.com>
Fri, 10 May 2019 07:12:38 +0000 (07:12 +0000)
We added @pidmap into hash and reference count will be 1.
However, another thread might reclaim this newely added
@pidmap from hash list, we try to access this @pidmap
will become a user-after-free operation.

Fix this problem by init reference count as 1 before
adding hash list, which gurantee memory could be not
freed during our access.

Check other places where memory reclaim used did similar
idea like this.

Change-Id: Idd5f429b97e064e29b6883243f8a012c2b4b4ae7
Signed-off-by: Wang Shilong <wshilong@ddn.com>
Reviewed-on: https://review.whamcloud.com/34763
Tested-by: Jenkins
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Patrick Farrell <pfarrell@whamcloud.com>
Reviewed-by: Gu Zheng <gzheng@ddn.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
lustre/obdclass/jobid.c

index 633388b..07a6c57 100644 (file)
@@ -213,6 +213,12 @@ static int jobid_get_from_cache(char *jobid, size_t joblen)
                pidmap->jp_jobid[0] = '\0';
                spin_lock_init(&pidmap->jp_lock);
                INIT_HLIST_NODE(&pidmap->jp_hash);
+               /*
+                * @pidmap might be reclaimed just after it is added into
+                * hash list, init @jp_refcount as 1 to make sure memory
+                * could be not freed during access.
+                */
+               atomic_set(&pidmap->jp_refcount, 1);
 
                /*
                 * Add the newly created map to the hash, on key collision we
@@ -226,8 +232,6 @@ static int jobid_get_from_cache(char *jobid, size_t joblen)
                               pid);
                        OBD_FREE_PTR(pidmap);
                        pidmap = pidmap2;
-               } else {
-                       cfs_hash_get(jobid_hash, &pidmap->jp_hash);
                }
        }