Re: BUG: kernel stack overflow when mounting with data_flush

[Chao Yu <chao@kernel.org>]

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 <yuchao0@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 <yuchao0@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 <yuchao0@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 <yuchao0@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
>