Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2290858ybv; Mon, 24 Feb 2020 02:42:53 -0800 (PST) X-Google-Smtp-Source: APXvYqx4qMt3VrbbmequVqBcGuYNofpRjc7t+8/X+0TIFXZCTd2j3wUhkNeVGPe9htxnHd5zG5Nw X-Received: by 2002:aca:50cd:: with SMTP id e196mr11811398oib.178.1582540972912; Mon, 24 Feb 2020 02:42:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582540972; cv=none; d=google.com; s=arc-20160816; b=VcRj9fGdwxaw4ztr9wnYOrbImVx97ZGFGl0l7G6bErMXvYXfv21OWo3zmskyVxmEn7 LhCqRfgtzqoVqMYUJ8BFuFoVa12AN8WOSVR8UN0ajUi6kXj3cw0xP4cFGh/WJnPrKv0B HUZOA9RQlxKkshNSw5OIV6xHtyDvC9sNy1iUKFl78Zu2dXbOEEqrWbmyuVjiX6zZ6niw BOUdgeNULs/DZasbbyl0zJDJqDMZodhYV4bH4pKQFsY/zN98ktWL12gJz5Q3P7/QEUFs d9aDCQxn3Ryp9cuAXOBCQ2O1oq40XNsl1DxaWcgtpNoUREfbFAXcFyv5f3Gg7shB4EVR KhHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:to:from:subject; bh=uCgBZP332+B8eJ8SqSNic3/cI/R9UuAv/coJWIpME6s=; b=E39js4d7OIllwfZAu8fgQPYVc8wfPLYsKVZCIij+dZagzR6HlGhjKPW6l/1jQeA+X7 0uN+6zl6EyVNAM9uzqmNbuRL0XvlSlPiZqxmasOlbqZjkHa9osNV6g19POq8FaHlZomu SbkG46l6MJOCAZwKd7J8bBQMW2r948VdoKZt19E/WGcyscX/DvpRIF9k5+M2KG4pvQ9k 9tqs+NsjHh4G7LXl3FGHkz78VT++3eheI+2YaFcOgPyZ/fGsPnhEA/Gik0VDbnFWLKrC OBymqvUUE71+kN5Ow1TL/LGEf2ujIhISE/Nwico9uh91xZsBwgELYTgj2XN0P33hzMkl q6pg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j6si6174069otp.17.2020.02.24.02.42.39; Mon, 24 Feb 2020 02:42:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727229AbgBXKl0 (ORCPT + 99 others); Mon, 24 Feb 2020 05:41:26 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11103 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726509AbgBXKl0 (ORCPT ); Mon, 24 Feb 2020 05:41:26 -0500 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 10C96F9334DF5F66A2DF; Mon, 24 Feb 2020 18:41:08 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.207) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 24 Feb 2020 18:41:04 +0800 Subject: Re: [f2fs-dev] Writes stoped working on f2fs after the compression support was added From: Chao Yu To: Jaegeuk Kim , , References: <20191209222345.1078-1-jaegeuk@kernel.org> <20200222044617.pfrhnz2iavkrtdn6@core.my.home> <20200222181721.tzrrohep5l3yklpf@core.my.home> Message-ID: Date: Mon, 24 Feb 2020 18:41:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/2/24 18:37, Chao Yu wrote: > Hi, > > Thanks for the report. > > On 2020/2/23 2:17, Ondřej Jirman wrote: >> Hello, >> >> I observe hung background f2fs task on 5.6-rc2+ shortly after boot, leading to >> panics. I use f2fs as rootfs. See below for stack trace. The reads continue to >> work (if I disable panic on hung task). But sync blocks, writes block, etc. >> >> It does not happen on all my f2fs filesystems, so it may depend on workload >> or my particular filesystem state. It happens on two separate devices though, >> both 32-bit, and doesn't happen on a 64-bit device. (might be a false lead, >> though) >> >> I went through the f2fs-for-5.6 tag/branch and reverted each patch right >> down to: >> >> 4c8ff7095bef64fc47e996a938f7d57f9e077da3 f2fs: support data compression >> >> I could still reproduce the issue. >> >> After reverting the data compression too, I could no longer reproduce the >> issue. Perhaps not very helpful, since that patch is huge. >> >> I tried to collect some information. Some ftrace logs, etc. Not sure what would >> help debug this. Let me know if I can help debug this more. >> >> Symptoms look the same as this issue: >> >> https://www.mail-archive.com/linux-f2fs-devel@lists.sourceforge.net/msg15298.html >> >> ftrace: https://megous.com/dl/tmp/f2fs-debug-info.txt >> >> longer ftrace: https://megous.com/dl/tmp/f2fs-debug-info-full.txt > > I checked the full trace log, however I didn't find any clue to troubleshot this issue. > > [snip] > >> dmesg: > > Could you dump all other task stack info via "echo "t" > /proc/sysrq-trigger"? > >> >> [ 246.758021] INFO: task kworker/u16:1:58 blocked for more than 122 seconds. >> [ 246.758040] Not tainted 5.6.0-rc2-00590-g9983bdae4974e #11 >> [ 246.758044] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >> [ 246.758052] kworker/u16:1 D 0 58 2 0x00000000 >> [ 246.758090] Workqueue: writeback wb_workfn (flush-179:0) >> [ 246.758099] Backtrace: >> [ 246.758121] [] (__schedule) from [] (schedule+0x78/0xf4) >> [ 246.758130] r10:da644000 r9:00000000 r8:da645a60 r7:da283e10 r6:00000002 r5:da644000 >> [ 246.758132] r4:da4d3600 >> [ 246.758148] [] (schedule) from [] (rwsem_down_write_slowpath+0x24c/0x4c0) >> [ 246.758152] r5:00000001 r4:da283e00 >> [ 246.758161] [] (rwsem_down_write_slowpath) from [] (down_write+0x6c/0x70) >> [ 246.758167] r10:da283e00 r9:da645d80 r8:d9ed0000 r7:00000001 r6:00000000 r5:eff213b0 >> [ 246.758169] r4:da283e00 >> [ 246.758187] [] (down_write) from [] (f2fs_write_single_data_page+0x608/0x7ac) > > I'm not sure what is this semaphore, I suspect this is F2FS_I(inode)->i_sem, in order to make > sure of this, can you help to add below function, and use them to replace > all {down,up}_{write,read}(&.i_sem) invoking? then reproduce this issue and catch the log. Sorry, just forgot attaching below function. void inode_down_write(struct inode *inode) { printk("%s from %pS\n", __func__, __builtin_return_address(0)); down_write(&F2FS_I(inode)->i_sem); } void inode_up_write(struct inode *inode) { up_write(&F2FS_I(inode)->i_sem); printk("%s from %pS\n", __func__, __builtin_return_address(0)); } void inode_down_read(struct inode *inode) { printk("%s from %pS\n", __func__, __builtin_return_address(0)); down_read(&F2FS_I(inode)->i_sem); } void inode_up_read(struct inode *inode) { up_read(&F2FS_I(inode)->i_sem); printk("%s from %pS\n", __func__, __builtin_return_address(0)); } > > Thanks, > >> [ 246.758190] r5:eff213b0 r4:da283c60 >> [ 246.758198] [] (f2fs_write_single_data_page) from [] (f2fs_write_cache_pages+0x2b4/0x7c4) >> [ 246.758204] r10:da645c28 r9:da283d60 r8:da283c60 r7:0000000f r6:da645d80 r5:00000001 >> [ 246.758206] r4:eff213b0 >> [ 246.758214] [] (f2fs_write_cache_pages) from [] (f2fs_write_data_pages+0x344/0x35c) >> [ 246.758220] r10:00000000 r9:d9ed002c r8:d9ed0000 r7:00000004 r6:da283d60 r5:da283c60 >> [ 246.758223] r4:da645d80 >> [ 246.758238] [] (f2fs_write_data_pages) from [] (do_writepages+0x3c/0xd4) >> [ 246.758244] r10:0000000a r9:c0e03d00 r8:00000c00 r7:c0264ddc r6:da645d80 r5:da283d60 >> [ 246.758246] r4:da283c60 >> [ 246.758254] [] (do_writepages) from [] (__writeback_single_inode+0x44/0x454) >> [ 246.758259] r7:da283d60 r6:da645eac r5:da645d80 r4:da283c60 >> [ 246.758266] [] (__writeback_single_inode) from [] (writeback_sb_inodes+0x204/0x4b0) >> [ 246.758272] r10:0000000a r9:c0e03d00 r8:da283cc8 r7:da283c60 r6:da645eac r5:da283d08 >> [ 246.758274] r4:d9dc9848 >> [ 246.758281] [] (writeback_sb_inodes) from [] (__writeback_inodes_wb+0x50/0xe4) >> [ 246.758287] r10:da3797a8 r9:c0e03d00 r8:d9dc985c r7:da645eac r6:00000000 r5:d9dc9848 >> [ 246.758289] r4:da5a8800 >> [ 246.758296] [] (__writeback_inodes_wb) from [] (wb_writeback+0x294/0x338) >> [ 246.758302] r10:fffbf200 r9:da644000 r8:c0e04e64 r7:d9dc9848 r6:d9dc9874 r5:da645eac >> [ 246.758305] r4:d9dc9848 >> [ 246.758312] [] (wb_writeback) from [] (wb_workfn+0x35c/0x54c) >> [ 246.758318] r10:da5f2005 r9:d9dc984c r8:d9dc9948 r7:d9dc9848 r6:00000000 r5:d9dc9954 >> [ 246.758321] r4:000031e6 >> [ 246.758334] [] (wb_workfn) from [] (process_one_work+0x214/0x544) >> [ 246.758340] r10:da5f2005 r9:00000200 r8:00000000 r7:da5f2000 r6:ef044400 r5:da5eb000 >> [ 246.758343] r4:d9dc9954 >> [ 246.758350] [] (process_one_work) from [] (worker_thread+0x4c/0x574) >> [ 246.758357] r10:ef044400 r9:c0e03d00 r8:ef044418 r7:00000088 r6:ef044400 r5:da5eb014 >> [ 246.758359] r4:da5eb000 >> [ 246.758368] [] (worker_thread) from [] (kthread+0x144/0x170) >> [ 246.758374] r10:ec9e5e90 r9:dabf325c r8:da5eb000 r7:da644000 r6:00000000 r5:da5fe000 >> [ 246.758377] r4:dabf3240 >> [ 246.758386] [] (kthread) from [] (ret_from_fork+0x14/0x2c) >> [ 246.758391] Exception stack(0xda645fb0 to 0xda645ff8) >> [ 246.758397] 5fa0: 00000000 00000000 00000000 00000000 >> [ 246.758402] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> [ 246.758407] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 >> [ 246.758413] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c01563b8 >> [ 246.758416] r4:da5fe000 >> . >> > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >