On 2022/10/27 16:05, Michal Koutný wrote: > Hello. > > On Thu, Oct 20, 2022 at 07:47:01AM +0000, "haifeng.xu" <haifeng.xu@xxxxxxxxxx> wrote: >> - lockdep_assert_held(&css_set_lock); >> + if (!cset || cset is either getting the first task or losing the last(cset)) >> + return; > > 1) the guard should be css_set_populated() ^ populated (when unsetting > the populated trait) > > 2) I'd keep the lockdep_assert_held() after it anyway. > > Also the commit message should explain what's the reason to move > css_set_populated() after css_set_move_task(). > > > Thanks, > Michal Hi, Michal. 1) If calls 'css_set_update_populated' , the cset is either getting the first task or losing the last. There is a need to update the populated state of the cset only when 'css_set_populated' returns false. In other words, the last has been deleted from from_cset and the first hasn't been added to to_cset yet. 2) Thanks for your suggestion. I'll keep 'lockdep_assert_held'. 3) In order to update the populated state of to_cset the same way from_cset does, 'css_set_update_populated' is also invoked during the process of moving a task to to_cset. Thanks, Haifeng
