On 2019-4-2 20:41, Hagbard Celine wrote:
> That seems to have fixed it. No more errors in syslog after extracting
> my stage3 tarball. Also ran a couple of kernel compiles on a partition
> mounted with data_flush and system seems stable.
Thanks a lot for your quick test. :)
Thanks,
>
> 2019-04-01 10:05 GMT+02:00, Chao Yu <yuch...@huawei.com>:
>> On 2019/3/31 2:54, Hagbard Celine wrote:
>>> First, yes it is caused by data_flush, this is what I am trying to
>>> report. Without that option there is no "stack guard page was hit" and
>>> no "kernel stack overflow" and kernel is stable.
>>> This time I was using kernel 5.0.3, as can be seen in the log in my first
>>> mail.
>>> I do not remember exactly what kernel version I tried the first time a
>>> saw this bug, but I believe the mount option data_flush was just added
>>> when I tried it the first time. The option has always lead to crash
>>> here.
>>
>> Sorry, out of mind at that time, data_flush key words slip out of my eye...
>>
>> Could you please try below patch?
>>
>> From 65edbf14a198d0b50765e10340255e2071f7ae75 Mon Sep 17 00:00:00 2001
>> From: Chao Yu <yuch...@huawei.com>
>> Date: Mon, 1 Apr 2019 15:59:16 +0800
>> Subject: [PATCH] f2fs: fix potential recursive call when enabling
>> data_flush
>>
>> Signed-off-by: Chao Yu <yuch...@huawei.com>
>> ---
>> fs/f2fs/checkpoint.c | 6 ++----
>> fs/f2fs/data.c | 3 ++-
>> 2 files changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index a98e1b02279e..935ebdb9cf47 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -1009,13 +1009,11 @@ int f2fs_sync_dirty_inodes(struct f2fs_sb_info *sbi,
>> enum inode_type type)
>> if (inode) {
>> unsigned long cur_ino = inode->i_ino;
>>
>> - if (is_dir)
>> - F2FS_I(inode)->cp_task = current;
>> + F2FS_I(inode)->cp_task = current;
>>
>> filemap_fdatawrite(inode->i_mapping);
>>
>> - if (is_dir)
>> - F2FS_I(inode)->cp_task = NULL;
>> + F2FS_I(inode)->cp_task = NULL;
>>
>> iput(inode);
>> /* We need to give cpu to another writers. */
>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>> index d87dfa5aa112..9d3c11e09a03 100644
>> --- a/fs/f2fs/data.c
>> +++ b/fs/f2fs/data.c
>> @@ -2038,7 +2038,8 @@ static int __write_data_page(struct page *page, bool
>> *submitted,
>> }
>>
>> unlock_page(page);
>> - if (!S_ISDIR(inode->i_mode) && !IS_NOQUOTA(inode))
>> + if (!S_ISDIR(inode->i_mode) && !IS_NOQUOTA(inode) &&
>> + !F2FS_I(inode)->cp_task)
>> f2fs_balance_fs(sbi, need_balance_fs);
>>
>> if (unlikely(f2fs_cp_error(sbi))) {
>> --
>> 2.18.0.rc1
>>
>>
>>
>>>
>>> 2019-03-30 8:29 GMT+01:00, Chao Yu <yuch...@huawei.com>:
>>>> Oh, sorry, it's quite possible that bug is caused by data_flush, could
>>>> remove that mount option first?
>>>>
>>>> Thanks,
>>>>
>>>> On 2019/3/30 11:25, Chao Yu wrote:
>>>>> Hi Hagbard,
>>>>>
>>>>> Sorry for the delay.
>>>>>
>>>>> On 2019/3/27 21:59, Hagbard Celine wrote:
>>>>>> Hi, this is a long standing bug that I've hit before on older kernels,
>>>>>> but I was not able to get the syslog saved because of the nature of
>>>>>> the bug. This time I had booted form a pen-drive, and was able to save
>>>>>> the log to it's efi-partition.
>>>>>
>>>>> Now which version of kernel do you use? and do you remember what is
>>>>> your
>>>>> kernel version when this bug occured at first time?
>>>>>
>>> .
>>>
>>
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
