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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 786E8C4332F for ; Mon, 25 Apr 2022 13:16:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91DDB6B0074; Mon, 25 Apr 2022 09:16:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CC146B0075; Mon, 25 Apr 2022 09:16:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 793FA6B0078; Mon, 25 Apr 2022 09:16:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 69E366B0074 for ; Mon, 25 Apr 2022 09:16:07 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 338176181D for ; Mon, 25 Apr 2022 13:16:07 +0000 (UTC) X-FDA: 79395449574.18.2DA5334 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf25.hostedemail.com (Postfix) with ESMTP id DBFA5A0042 for ; Mon, 25 Apr 2022 13:15:59 +0000 (UTC) Received: by mail-ej1-f52.google.com with SMTP id y3so9179804ejo.12 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=2d8oPbspE9/pwOKTOJ+eBWHy3ZzNWXg955jcGw50WmNZHHDEcANS/jSr6yhox180KG Cnqg8ifS68JJf20uWtgP/biBewJXN0JsAZ5guQ1wEuwI08nTPmEEdoeMrHZSYrx3DyPm Qhu7UMwNrOMX23fuis5mvEfxrHTNAfkePHFkOJBVqNuGIkFcVUEmL9E7EFbiuqeAQkV7 oEiVPExCizewsadYs7RJqBZjNQtPCHvnr4QobnZyWRN4DOyRAF3xLApdza8gvIu33iT6 roVt9/3+EMhYLE/x+LJaBvBLsdixTmrBKHiDStLHoziIba47x+R+s/6S06iIysFZxtXJ XTqg== X-Gm-Message-State: AOAM533nEaAdYuiMJipdV1h7Y04nPrNgeyn8ZxEuL4ALXVWXgkU1Xows EPmEnHeWVGa6KMyN2SY4Vwam359Fm/N8cqGSSmIirw== 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" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: DBFA5A0042 X-Stat-Signature: i9rdi8iczydq4teuj5t7rj6bsjf6os5u X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=none ("invalid DKIM record") header.d=szeredi.hu header.s=google header.b=VBGcSS5B; spf=pass (imf25.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.218.52 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=none X-HE-Tag: 1650892559-923227 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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