Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20210603125242.31699-1-chenguanyou@xiaomi.com>
 <CAJfpegsEkRnU26Vvo4BTQUmx89Hahp6=RTuyEcPm=rqz8icwUQ@mail.gmail.com>
 <1fabb91167a86990f4723e9036a0e006293518f4.camel@mediatek.com>
 <CAJfpegsOSWZpKHqDNE_B489dGCzLr-RVAhimVOsFkxJwMYmj9A@mail.gmail.com>
 <07c5f2f1e10671bc462f88717f84aae9ee1e4d2b.camel@mediatek.com>
 <CAJfpegvAJS=An+hyAshkNcTS8A2TM28V2UP4SYycXUw3awOR+g@mail.gmail.com>
 <YVMz8E1Lg/GZQcjw@miu.piliscsaba.redhat.com> <SI2PR03MB5545E0B76E54013678B9FEEC8BA99@SI2PR03MB5545.apcprd03.prod.outlook.com>
 <07ad7d51d15c7ffc708b55066ded653a4b2c5c98.camel@mediatek.com>
 <CAJfpegsw3NpH6oTU9nxJLPUYMJVmfWhAa6yB8vnDZctP9vHc0g@mail.gmail.com> <490be4e0b984e146c93586507442de3dad8694bb.camel@mediatek.com>
In-Reply-To: <490be4e0b984e146c93586507442de3dad8694bb.camel@mediatek.com>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Mon, 11 Jul 2022 09:49:59 +0200
Message-ID: <CAJfpegsShacuTHvWUnWbdvnN_WcoKGzynsrSnkibAmphsr2kXg@mail.gmail.com>
Subject: Re: [PATCH] [fuse] alloc_page nofs avoid deadlock
To:     Ed Tsai <ed.tsai@mediatek.com>
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>,
        =?UTF-8?B?U3RhbmxleSBDaHUgKOacseWOn+mZnik=?= 
        <stanley.chu@mediatek.com>,
        =?UTF-8?B?WW9uZy14dWFuIFdhbmcgKOeOi+ipoOiQsSk=?= 
        <Yong-xuan.Wang@mediatek.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, 13 Jun 2022 at 11:29, Ed Tsai <ed.tsai@mediatek.com> wrote:
>
> 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.

Is commit 5c791fe1e2a4 ("fuse: make sure reclaim doesn't write the
inode") applied to this kernel?

Thanks,
Miklos