From: Ed Tsai <ed.tsai@mediatek.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
chenguanyou <chenguanyou9338@gmail.com>,
"Stanley Chu (朱原陞)" <stanley.chu@mediatek.com>,
"Yong-xuan Wang (王詠萱)" <Yong-xuan.Wang@mediatek.com>
Subject: Re: [PATCH] [fuse] alloc_page nofs avoid deadlock
Date: Mon, 13 Jun 2022 17:29:06 +0800 [thread overview]
Message-ID: <490be4e0b984e146c93586507442de3dad8694bb.camel@mediatek.com> (raw)
In-Reply-To: <CAJfpegsw3NpH6oTU9nxJLPUYMJVmfWhAa6yB8vnDZctP9vHc0g@mail.gmail.com>
On Mon, 2022-06-13 at 16:45 +0800, Miklos Szeredi wrote:
> On Fri, 10 Jun 2022 at 09:48, Ed Tsai <ed.tsai@mediatek.com> wrote:
>
> > Recently, we get this deadlock issue again.
> > fuse_flush_time_update()
> > use sync_inode_metadata() and it only write the metadata, so the
> > writeback worker could still be blocked becaused of file data.
> >
> > I try to use write_inode_now() instead of sync_inode_metadata() and
> > the
> > writeback thread will not be blocked anymore. I don't think this is
> > a
> > good solution, but this confirm that there is still a potential
> > deadlock because of file data. WDYT.
>
> I'm not sure how that happens. Normally writeback doesn't
> block. Can
> you provide the stack traces of all related tasks in the deadlock?
>
> Thanks,
> Miklos
The writeback worker
ppid=22915 pid=22915 S cpu=6 prio=120 wait=3614s kworker/u16:21
vmlinux request_wait_answer + 64
vmlinux __fuse_request_send + 328
vmlinux fuse_request_send + 60
vmlinux fuse_simple_request + 376
vmlinux fuse_flush_times + 276
vmlinux fuse_write_inode + 104 (inode=0xFFFFFFD516CC4780, ff=0)
vmlinux write_inode + 384
vmlinux __writeback_single_inode + 960
vmlinux writeback_sb_inodes + 892
vmlinux __writeback_inodes_wb + 156
vmlinux wb_writeback + 512
vmlinux wb_check_background_flush + 600
vmlinux wb_do_writeback + 644
vmlinux wb_workfn + 756
vmlinux process_one_work + 628
vmlinux worker_thread + 708
vmlinux kthread + 376
vmlinux ret_from_fork + 16
Thread-11
ppid=3961 pid=26057 D cpu=4 prio=120 wait=3614s Thread-11
vmlinux __inode_wait_for_writeback + 108
vmlinux inode_wait_for_writeback + 156
vmlinux evict + 160
vmlinux iput_final + 292
vmlinux iput + 600
vmlinux dentry_unlink_inode + 212
vmlinux __dentry_kill + 228
vmlinux shrink_dentry_list + 408
vmlinux prune_dcache_sb + 80
vmlinux super_cache_scan + 272
vmlinux do_shrink_slab + 944
vmlinux shrink_slab + 1104
vmlinux shrink_node + 712
vmlinux shrink_zones + 188
vmlinux do_try_to_free_pages + 348
vmlinux try_to_free_pages + 848
vmlinux __perform_reclaim + 64
vmlinux __alloc_pages_direct_reclaim + 64
vmlinux __alloc_pages_slowpath + 1296
vmlinux __alloc_pages_nodemask + 2004
vmlinux __alloc_pages + 16
vmlinux __alloc_pages_node + 16
vmlinux alloc_pages_node + 16
vmlinux __read_swap_cache_async + 172
vmlinux read_swap_cache_async + 12
vmlinux swapin_readahead + 328
vmlinux do_swap_page + 844
vmlinux handle_pte_fault + 268
vmlinux __handle_speculative_fault + 548
vmlinux handle_speculative_fault + 44
vmlinux do_page_fault + 500
vmlinux do_translation_fault + 64
vmlinux do_mem_abort + 72
vmlinux el0_sync + 1032
ppid=3961 is com.google.android.providers.media.module, and it is the
android fuse daemon.
So, the daemon and wb worker were wait for each other.
Best,
Ed Tsai
next prev parent reply other threads:[~2022-06-13 9:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 12:52 [PATCH] [fuse] alloc_page nofs avoid deadlock chenguanyou
2021-06-08 14:54 ` Re:[PATCH] fuse: " chenguanyou
2021-06-08 15:30 ` [PATCH] [fuse] " Miklos Szeredi
2021-06-11 12:14 ` Re:[PATCH] fuse: " chenguanyou
2021-07-13 2:42 ` [PATCH] [fuse] " Ed Tsai
2021-08-18 9:24 ` Miklos Szeredi
2021-09-24 3:52 ` Ed Tsai
2021-09-24 7:52 ` Miklos Szeredi
2021-09-28 15:25 ` Miklos Szeredi
2021-09-29 3:31 ` Re:[PATCH] fuse: " chenguanyou
2021-12-14 9:25 ` [PATCH] [fuse] " Ed Tsai
2021-12-14 9:38 ` Greg Kroah-Hartman
2021-12-15 8:22 ` Ed Tsai
2021-12-15 13:52 ` Greg Kroah-Hartman
[not found] ` <SI2PR03MB5545E0B76E54013678B9FEEC8BA99@SI2PR03MB5545.apcprd03.prod.outlook.com>
2022-06-10 7:48 ` Ed Tsai
2022-06-13 8:45 ` Miklos Szeredi
2022-06-13 9:29 ` Ed Tsai [this message]
2022-07-05 8:53 ` [PATCH 1/1] fuse: add fuse_d_iput to postponed the iput Ed Tsai
2022-07-18 13:57 ` Miklos Szeredi
2022-07-11 7:49 ` [PATCH] [fuse] alloc_page nofs avoid deadlock Miklos Szeredi
2022-07-12 1:16 ` Ed Tsai
-- strict thread matches above, loose matches on Subject: below --
2021-06-03 12:41 chenguanyou
2021-06-03 12:56 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=490be4e0b984e146c93586507442de3dad8694bb.camel@mediatek.com \
--to=ed.tsai@mediatek.com \
--cc=Yong-xuan.Wang@mediatek.com \
--cc=chenguanyou9338@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stanley.chu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox