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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08E5FC433E1 for ; Sat, 27 Jun 2020 09:33:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A515E208C7 for ; Sat, 27 Jun 2020 09:33:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dLwG+3iU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A515E208C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 04D726B00A2; Sat, 27 Jun 2020 05:33:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F412F6B00A3; Sat, 27 Jun 2020 05:33:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2F4C6B00A4; Sat, 27 Jun 2020 05:33:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id C7F226B00A2 for ; Sat, 27 Jun 2020 05:33:19 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 845462DFD for ; Sat, 27 Jun 2020 09:33:19 +0000 (UTC) X-FDA: 76974478518.10.pin25_4d14f2126e5d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 588A116A0D1 for ; Sat, 27 Jun 2020 09:33:19 +0000 (UTC) X-HE-Tag: pin25_4d14f2126e5d X-Filterd-Recvd-Size: 5577 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Sat, 27 Jun 2020 09:33:18 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id a12so12303433ion.13 for ; Sat, 27 Jun 2020 02:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ffLQuJygGbq4RaYKN898b4cD/qHH2O6tm/Zb6p2WV+4=; b=dLwG+3iUi4OZtTX3/qfZ9iPPiOZsMB5ZU3D7Cqg4ZmmBAkoL/jgX3MlqDeKCkj7VGv BOJ+Zrfw3AL2ECEaU8neH+nTTC7hIXDBOD+Mt0FE5+Gfc12cbAGQD+hpllFvb6EEYXO6 ayr5LNsBY9ntu78FTOgPh6uRn6K2jFonK2IDRikVy/hbj1358XggNyM2bqAkaNO57nmI BwVlDNjphmD7dQuaV9bKlPLapFGE0hgyunvtO6IhtNImCPBVGrWgMl1lnyZXOWM2eQo4 uYmS1nRErBrH455hElDvQ1o8XS0C1DvLBtTz/Ld9MG0ugFqa/tIjXjduxBuYpfQqwzSJ t1uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ffLQuJygGbq4RaYKN898b4cD/qHH2O6tm/Zb6p2WV+4=; b=fFU23PSw1XpoZHyxxKuIJxdI1ehKOW4jxQeqoZFtlKafBEbIrWuaAjELDdisf7z5In q/P0DAOnNPWL3zzJEj+uNJ+19fpXyMclg5y02TFFqYcFa+sJx07LLFWYi5SFKhybPY55 +12ZG2CJIlrsWuIla3mXkoJur4li9o2rNoPoqJsxfNvde+UhYWQFHDlj4ut04migxxLO CApc8LB2IfrLO0ETLIxPYt7VbImQ+lziV5sDMVZuK9LwrCUB3140/VjsGtejriw3agfU AF2NjuJVV8qeGNO0wBqk1F37EuNP4PzqEpK/BWcQAojK2rc8OjJAu43LLLtPW7LnJ/oj ttfw== X-Gm-Message-State: AOAM5335EKNLmyltkO7J7tKvcwGtazlPEwbtvAsdOPffJmRUgfx6ggEG Rbgvq84U9ourJJKjHPPnj5Gwa78IyBMZrL3uOdM= X-Google-Smtp-Source: ABdhPJwOotjqrBwXrGGAK19+x5rTZhFfEmNnDKCdzD15DVR1Uj4IPHoQ24FfPMq47bdkWhRaLtQgSX7481+BpJyrkQs= X-Received: by 2002:a6b:780d:: with SMTP id j13mr7883984iom.66.1593250398101; Sat, 27 Jun 2020 02:33:18 -0700 (PDT) MIME-Version: 1.0 References: <1593011142-10209-1-git-send-email-laoar.shao@gmail.com> <20200626090250.GC30103@infradead.org> In-Reply-To: <20200626090250.GC30103@infradead.org> From: Yafang Shao Date: Sat, 27 Jun 2020 17:32:42 +0800 Message-ID: Subject: Re: [PATCH v2] xfs: reintroduce PF_FSTRANS for transaction reservation recursion protection To: Christoph Hellwig Cc: Dave Chinner , Michal Hocko , "Darrick J. Wong" , Andrew Morton , Brian Foster , Vlastimil Babka , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Linux MM , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 588A116A0D1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Fri, Jun 26, 2020 at 5:02 PM Christoph Hellwig wrote: > > On Wed, Jun 24, 2020 at 11:05:42AM -0400, Yafang Shao wrote: > > PF_FSTRANS which is used to avoid transaction reservation recursion, is > > dropped since commit 9070733b4efa ("xfs: abstract PF_FSTRANS to > > PF_MEMALLOC_NOFS") and commit 7dea19f9ee63 ("mm: introduce > > memalloc_nofs_{save,restore} API") and replaced by PF_MEMALLOC_NOFS which > > means to avoid filesystem reclaim recursion. That change is subtle. > > Let's take the exmple of the check of WARN_ON_ONCE(current->flags & > > PF_MEMALLOC_NOFS)) to explain why this abstraction from PF_FSTRANS to > > PF_MEMALLOC_NOFS is not proper. > > > > Bellow comment is quoted from Dave, > > > It wasn't for memory allocation recursion protection in XFS - it was for > > > transaction reservation recursion protection by something trying to flush > > > data pages while holding a transaction reservation. Doing > > > this could deadlock the journal because the existing reservation > > > could prevent the nested reservation for being able to reserve space > > > in the journal and that is a self-deadlock vector. > > > IOWs, this check is not protecting against memory reclaim recursion > > > bugs at all (that's the previous check [1]). This check is > > > protecting against the filesystem calling writepages directly from a > > > context where it can self-deadlock. > > > So what we are seeing here is that the PF_FSTRANS -> > > > PF_MEMALLOC_NOFS abstraction lost all the actual useful information > > > about what type of error this check was protecting against. > > > > [1]. Bellow check is to avoid memory reclaim recursion. > > if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) == > > PF_MEMALLOC)) > > goto redirty; > > > > Suggested-by: Dave Chinner > > Signed-off-by: Yafang Shao > > Cc: Michal Hocko > > This generally looks sane, but: > > - adds a bunch of overly long lines for no good reason > - doesn't really hide this behind a useful informatin, e.g. a > xfs_trans_context_start/end helpers for the normal case, plus > an extra helper with kswapd in the name for that case. > Good point. I will try to think about it. > The latter should also help to isolate a bit against the mm-area > changes to the memalloc flags proposed. I have read the patchset from Matthew. Agree with you that we should do it the same way. [adding Matthew to cc] -- Thanks Yafang