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;
Message-ID: <29577961-be15-3c33-c8db-5a92405a87f8@quicinc.com>
Date:   Tue, 6 Sep 2022 08:29:11 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.0.3
Subject: Re: [PATCH] fuse: fix the deadlock in race of reclaim path with
 kswapd
To:     Miklos Szeredi <miklos@szeredi.hu>
CC:     <linux-fsdevel@vger.kernel.org>, <quic_maow@quicinc.com>,
        <linux-kernel@vger.kernel.org>
References: <20220905071744.8350-1-quic_yingangl@quicinc.com>
 <CAJfpegs6Jbr8eF9ZNycEjfCtJNVQJECjFnOC9-v8WSXHvpWxCg@mail.gmail.com>
Content-Language: en-US
From:   Kassey Li <quic_yingangl@quicinc.com>
In-Reply-To: <CAJfpegs6Jbr8eF9ZNycEjfCtJNVQJECjFnOC9-v8WSXHvpWxCg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 9/5/2022 9:28 PM, Miklos Szeredi wrote:
> On Mon, 5 Sept 2022 at 09:17, Kassey Li <quic_yingangl@quicinc.com> wrote:
>>
>> Task A wait for writeback, while writeback Task B send request to fuse.
>> Task C is expected to serve this request, here it is in direct reclaim
>> path cause deadlock when system is in low memory.
>>
>> without __GFP_FS in Task_C break throttle_direct_reclaim with an
>> HZ timeout.
>>
>> kswpad (Task_A):                    writeback(Task_B):
>>      __switch_to+0x14c                   schedule+0x70
>>      __schedule+0xb5c                    __fuse_request_send+0x154
>>      schedule+0x70                       fuse_simple_request+0x184
>>      bit_wait+0x18                       fuse_flush_times+0x114
>>      __wait_on_bit+0x74                  fuse_write_inode+0x60
>>      inode_wait_for_writeback+0xa4       __writeback_single_inode+0x3d8
>>      evict+0xa8                          writeback_sb_inodes+0x4c0
>>      iput+0x248                          __writeback_inodes_wb+0xb0
>>      dentry_unlink_inode+0xdc            wb_writeback+0x270
>>      __dentry_kill[jt]+0x110             wb_workfn+0x37c
>>      shrink_dentry_list+0x17c            process_one_work+0x284
>>      prune_dcache_sb+0x5c
>>      super_cache_scan+0x11c
>>      do_shrink_slab+0x248
>>      shrink_slab+0x260
>>      shrink_node+0x678
>>      kswapd+0x8ec
>>      kthread+0x140
>>      ret_from_fork+0x10
>>
>> Task_C:
>>      __switch_to+0x14c
>>      __schedule+0xb5c
>>      schedule+0x70
>>      throttle_direct_reclaim
>>      try_to_free_pages
>>      __perform_reclaim
>>      __alloc_pages_direct_reclaim
>>      __alloc_pages_slowpath
>>      __alloc_pages_nodemask
>>      alloc_pages
>>      fuse_copy_fill+0x168
>>      fuse_dev_do_read+0x37c
>>      fuse_dev_splice_read+0x94
> 
> Should already be fixed in v5.16 by commit 5c791fe1e2a4 ("fuse: make
> sure reclaim doesn't write the inode").
   thanks for this info.
> 
> Thanks,
> Miklos