On 2017/6/14 22:26, Jaegeuk Kim wrote:
> On 06/12, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2017/6/12 11:04, Jaegeuk Kim wrote:
>>> This patch resolves kernel panic for xfstests/081, caused by recent f2fs_bug_on
>>>
>>> f2fs: add f2fs_bug_on in __remove_discard_cmd
>>>
>>> Signed-off-by: Jaegeuk Kim <jaegeuk@xxxxxxxxxx>
>>> ---
>>> fs/f2fs/segment.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>> index 86a0c1095939..a6d77388a806 100644
>>> --- a/fs/f2fs/segment.c
>>> +++ b/fs/f2fs/segment.c
>>> @@ -1025,6 +1025,8 @@ static void __wait_discard_cmd(struct f2fs_sb_info *sbi, bool wait_cond)
>>> list_for_each_entry_safe(dc, tmp, wait_list, list) {
>>> if (!wait_cond || (dc->state == D_DONE && !dc->ref)) {
>>> wait_for_completion_io(&dc->wait);
>>> + if (dc->state == D_DONE && dc->ref)
>>> + dc->ref--;
>>
>> Should set dc->ref to 0 to avoid panic once we add other referrers?
>
> Sorry, could you please explain this in more detail?
Oh, I just assume later we may add another referrer for some reason
which will make dc->ref = 2, so dc->ref-- is not enough to avoid the
bug_on in __remove_discard_cmd. I think reseting dc->ref is more safe
here, how do you think?
Thanks,
>
> Thanks,
>
>>
>> Thanks,
>>
>>> __remove_discard_cmd(sbi, dc);
>>> } else {
>>> dc->ref++;
>>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
