From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97FB3C433EF for ; Mon, 25 Apr 2022 13:16:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241918AbiDYNT0 (ORCPT ); Mon, 25 Apr 2022 09:19:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229774AbiDYNTO (ORCPT ); Mon, 25 Apr 2022 09:19:14 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2EA318371 for ; Mon, 25 Apr 2022 06:16:05 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id w16so8292186ejb.13 for ; Mon, 25 Apr 2022 06:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fc/dEr5pwPMLhoa+YKleCXQFYWS2sX/902+8X3X7DqI=; b=VBGcSS5BAXuONpYWkt67xGVOtQbYl6w2EnQBsZkFutRb2kqi4IzrZc9kaHQs5Dk+Z9 nqI4eHhDRTf8d0EX7rHCmEvIGuJNLCI55gbZaTcpId1oqofcqB6Np6l3vsd1lWkjj8wc 5AexgDjRnfkWZ0XoEuIeJEvOHkGLw8WeqKocU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fc/dEr5pwPMLhoa+YKleCXQFYWS2sX/902+8X3X7DqI=; b=kUJJD1vMbc82xTbVdyETxoIwf4CpVnSuXLkIl4luSGPzdNq8uCKxeZT5zw5yXxouVy 1ErNtz8pStqZBxQNxGLQdEVdguK+hm7vopxNF2pulw/zioYkmFU9y/rK63goGxCDV+K9 wM40DBh13LOZ2H9zFNcXvfnt+MKHg0+M/dZ+A6xL4GPY1qcJ/CMhiPTmsEowKdr3/8xG aO1aesTxKwW61Mit7JVISDCSFmX6vMf2R/0Ca3yqVBjwe+AJhiHjmQ8IwRvTk2g9ceie vHZ5nFeSPAe65fMRf4Ek2HST+0z09FeSjvlwmfpbhPWqYNitTHUzg5teX1LL91hKvo9B tMQw== X-Gm-Message-State: AOAM533xC3UN6sYHZnWOVsEMDK1iGDqcwPAWBzWrb+YCb8EVh02RaG0n Zt2NPSqqTTtKUnWfERzmqQd+bJS8h+YPKgvgTF9OJg== X-Google-Smtp-Source: ABdhPJwNzf9snapdCoGQnnUDVd4WNGEHAAkVfUD+kFSan3W2X/sl+nAPQNQ8wSzU1xYyrNWL3lBjB1yB+FwDgxrkJ3Q= X-Received: by 2002:a17:906:8982:b0:6f3:95f4:4adf with SMTP id gg2-20020a170906898200b006f395f44adfmr4626275ejc.524.1650892564570; Mon, 25 Apr 2022 06:16:04 -0700 (PDT) MIME-Version: 1.0 References: <20220310111026.684924-1-wu-yan@tcl.com> In-Reply-To: <20220310111026.684924-1-wu-yan@tcl.com> From: Miklos Szeredi Date: Mon, 25 Apr 2022 15:15:53 +0200 Message-ID: Subject: Re: [fuse-devel] [PATCH] fuse: avoid deadlock when write fuse inode To: Rokudo Yan Cc: =?UTF-8?B?RWQgVHNhaSAo6JSh5a6X6LuSKQ==?= , guoweichao@oppo.com, Huang Jianan , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm , zhangshiming@oppo.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Mar 2022 at 12:11, Rokudo Yan wrote: > > Hi, Miklos > > The similar issue occurs in our Android device(4G RAM + 3G zram + 8 arm cores + kernel-4.14) too. > Under the monkey test, kswapd and fuse daemon thread deadlocked when free pages is extreme low > (less than 1/2 of the min watermark), the backtrace of the 2 threads is as follows. kswapd > try to evict inode to free some memory(blocked at inode_wait_for_writeback), and fuse daemon thread > handle the fuse inode write request, which is throttled when do direct reclaim in page allocation > slow path(blocked at throttle_direct_reclaim). As the __GFP_FS is set, the thread is throttled until > kswapd free enough pages until watermark ok(check allow_direct_reclaim), which cause the deadlock. > Although the kernel version is 4.14, the same issue exists in the upstream kernel too. > > kswapd0 D 26485194.538158 157 1287917 23577482 0x1a20840 0x0 157 438599862461462 > __switch_to+0x134/0x150 > __schedule+0xd5c/0x1100 > schedule+0x70/0x90 > bit_wait+0x14/0x54 > __wait_on_bit+0x74/0xe0 > inode_wait_for_writeback+0xa0/0xe4 This is the one I don't understand. Fuse inodes must never be dirty on eviction for the reason stated in my previous reply: > > I don't see how it can happen on upstream kernels, since there's a > >"write_inode_now(inode, 1)" call in fuse_release() and nothing can > > dirty the inode after the file has been released. If you could trace the source of this dirtyness I think that would explain this deadlock. Thanks, Miklos