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 E15BBC47073 for ; Tue, 9 Jan 2024 22:44:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E79828D0022; Tue, 9 Jan 2024 17:44:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E289B8D0020; Tue, 9 Jan 2024 17:44:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA2E98D0022; Tue, 9 Jan 2024 17:44:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B70AF8D0020 for ; Tue, 9 Jan 2024 17:44:25 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8F86A16075B for ; Tue, 9 Jan 2024 22:44:25 +0000 (UTC) X-FDA: 81661252890.18.1CEAEE8 Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by imf26.hostedemail.com (Postfix) with ESMTP id B1FAD140014 for ; Tue, 9 Jan 2024 22:44:23 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=NCMMD5hX; spf=pass (imf26.hostedemail.com: domain of david@fromorbit.com designates 209.85.166.173 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704840263; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L9xTLocbxJtZ/EsVzz8IzAHiTCzUNRLczzpqZlO0pg4=; b=xBtmaMQA0Q89+jNVKoSmXdI/s0R9XlTq/xEvK5PxaCY6FSoHtz8ENXbdg7ZCZCnACiYM6i rTrfDgiPnexKBO93U179JFe2Ly/R6/RFx+OKiD9+rAI/GEQ/ocbV0MDo0dfieZbT66exvD jELwCLEKEJ36q+LGBPPEs3dYia/zlco= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704840263; a=rsa-sha256; cv=none; b=LTexGJ18EGKW2PmQ98MXTyB+pmHOePonQ4y53W3OA7t1BEsV98nLFe99KGddRrmtTgC1LX /aWGiMcz2PPNqDW6QKNjhbeENsVOuGZ+qCnH1doVmj1D/PUjdJxowCMlZ2OqqFdLg/dXDD cvO5sISdrr4j3vx4JJFeLthWsRToN8g= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=NCMMD5hX; spf=pass (imf26.hostedemail.com: domain of david@fromorbit.com designates 209.85.166.173 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com Received: by mail-il1-f173.google.com with SMTP id e9e14a558f8ab-36091f4d8easo9811285ab.2 for ; Tue, 09 Jan 2024 14:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1704840263; x=1705445063; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=L9xTLocbxJtZ/EsVzz8IzAHiTCzUNRLczzpqZlO0pg4=; b=NCMMD5hXLFAFov9enac7suf47GQJTMuLGVGuvSACfPaFPbKw5WF3rZTPb5qFwP++p+ DuQR2w8mRyMueLT54W1V/l1+NBn3ZraVYSNXtLIBP61YhEgxjV/fjCdJyPGYHEOYeU1R uceyoT3p0bhSHQKDqXbI029pjj8Bg10Vbc39qRO1yVGNJDJ2q0p0bERiI0Jhn+V6n82y Vlz43SWKzY3rkCrTXn+JNRnNYHrzmfxLWmEt2DJWkOTVNEy8KmQt4ZA+ZOjiOA8NRuVW sBk9PIeZndvwLb2WZB+cauMY4jTCp/gV24XE7nyn2i8z7aJXjtnJ650ddkkMJ5YJog07 ORCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704840263; x=1705445063; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=L9xTLocbxJtZ/EsVzz8IzAHiTCzUNRLczzpqZlO0pg4=; b=IChDGzRQgk0UaDlosxKTN1J2oqRUdodLf0lTxd6xTfVur0f1vtR0Ida2xjgnaHPhPH 4bUJKDM6m4Z8vTa9cwM6j394Hx2SW2/jwZY8otIHwbwWzpROOR39KFnSAZdRdNVMxJHt oXJRvWoN3zGpVQlA4sbMpDL6M+7oX5/4+QiROdd1kHnYRd2357CsQ+DOfH+ZBSmB4rkg CtyGFLVEc8+55RM5rjEhRSphyQhejYeuhGGJVD4ruW2sYXI1ysZXnae/U1HYBMh8KBsA MukkunXKi4YOQZfGuW/TCvhTBUKwx6w8KPQboXtiPdioRwnbTIqc9xAXGnL1XC3JyjjZ yGPA== X-Gm-Message-State: AOJu0Yw0WDjTbDSoAWo1l8byTZeIRL8Fjv2Pw0lsl64ZTqJqMa5bgAtp BzDE0NchDSFr6OMxd0QIiWtEXluLkvkLiw== X-Google-Smtp-Source: AGHT+IHSKNtjcO8bUbdBcwmcDlNZLFhTfOw5pswdA67ew28nBq3+gGgOSAobh3nBsnKFOjOmUdXBuw== X-Received: by 2002:a05:6e02:1845:b0:35f:bd12:5488 with SMTP id b5-20020a056e02184500b0035fbd125488mr183647ilv.30.1704840262829; Tue, 09 Jan 2024 14:44:22 -0800 (PST) Received: from dread.disaster.area (pa49-180-249-6.pa.nsw.optusnet.com.au. [49.180.249.6]) by smtp.gmail.com with ESMTPSA id o5-20020a634e45000000b0050f85ef50d1sm2059281pgl.26.2024.01.09.14.44.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 14:44:22 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rNKpX-008G6o-07; Wed, 10 Jan 2024 09:44:19 +1100 Date: Wed, 10 Jan 2024 09:44:19 +1100 From: Dave Chinner To: Matthew Wilcox Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [LSF/MM/BPF TOPIC] Removing GFP_NOFS Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B1FAD140014 X-Rspam-User: X-Stat-Signature: oqrq8x9utmjnzgm65ujj9aagqujjn9ib X-Rspamd-Server: rspam03 X-HE-Tag: 1704840263-338342 X-HE-Meta: U2FsdGVkX1+Jmu2thTSxewRnbh9s2YmO88hfvek52ETIgb2PB1ZqL1aO3B76AKdMC1loibLIwVk+ES0BOZ4CmzMDbs2kwq2ExDFXnRFy7MIUysD7aSmh1/SW5QKz51zaRiuKW2t5fXh3sfpvONAYsZAsB/k+14aMLd3XKbgzaos4OlWLlY6F/qQW8tlBJCl7SP6TOXLUFfzswWyNqsSaKPRqPPpXekCmyTDIPsj12mhz2/4iUNqq6z3/Ew+07+inFxfAnK2xrl4C4VhUQqXPKZdAq6s9YdClUYHjMHoU5lrKRHex4K2zRHyCdi36bIYZiKuCYnDD8BRaLaYzjBDfVSI4FCNqPAA25b21iASJCkHaCG+rC2oIovUAAld6X4NprkADj/l5mBJkBLyMacQPPyRwrwXWqxuLf0rIhmKRwDEivBKKMrO9K2dDRSDf2r0Kttle+49B2dwvZwdgkxvxQFU1KfNk3Ur0RCJj6Idm23cNMsEclbqN/BOe/p/vpq8k5mep3WKl1dxskDLN5Xz6lyI6Hc7FW9XJNTY0Rqy0rJfE4hskO76do7k7jzruv9XOeiCuLKQCdfEANUZtqgXIECjJ3J1TQoiY34DAkQTS4ZgCZNhctgzkpAc8epvHMQet0wafkhoqJ9X24yRZgFaGmjino8CrePR17N2Oo3iT1HNfLvBQTUqTezifu4+NJG9Av/slOijbvlTaZjCxFkxWk7oxBksU4qQE6fSfDeLHHqzvSRsRn0C9NaXYfM9McBX1lj6rSqTVXH0tsndriLufUiPFXAJaw49sznENFYtLhzD2pfuayNm2oq3o9RtWdd0kHR+bQJQC2vDsgnbtwMo2WzXN9UV8mR/ZnJkzW99w/B2UotvQPpYgUf4e+UYiicHAUIr4RHEhQjPd57urvMDcR33YWGT5U9H/tt5sdbRPv/P6vEKlofepAWn7srJM2AGqX11ok15+R5v1jaiUzC9 Do/18jnD x4K4c3ML2ain+bYTwiAg12Oc+VlM0q9m62gz+AzcdcunSArlNyiNyOvxLMZeylTaMpdtPj6MiZjzcyGaNS1gq/Pvm8QX0f4rXNdGdOSp7sjhefKSBAfho1/MTIKKbezadP+wlqZ4Pl8u61vJVwKKKccNZTQs0Omq+19ZZeZfos3s2z3FmcCxCh5I0i5lNSMA8Q0AcQduSAqF5iCPibakU9n7fl0DtYl/MdBGeu1b9VMO0Llq0Nklt+Qavnxl7ywXRIb9c44OufpeU+HJky1Zd4bd5REP4/JaurDmF32gs1NbdtkdVmRc6IYTbZke4RO6FUOtZ53r8WqIYKHYSEHtwd7pL3Ml3cegMGZV84kWVLBL7muecS382Fwx3gsYhWzejAzjX21Pb7SDYo31ny2+u9kWn8v1/C8zfZ1v1hpPTEk3ccNnynLwySEh9G+7ckGxsFaleZCwd2XlsbqwCJkIq6XBqlNYGLpX0rKe0FX8RoShaTyToXXNlSsxOY6d18yt+UWWoRlhWvCuMCgZisW/t0ueGJsSF12vP+LbM X-Bogosity: Ham, tests=bogofilter, spamicity=0.082488, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 04, 2024 at 09:17:16PM +0000, Matthew Wilcox wrote: > This is primarily a _FILESYSTEM_ track topic. All the work has already > been done on the MM side; the FS people need to do their part. It could > be a joint session, but I'm not sure there's much for the MM people > to say. > > There are situations where we need to allocate memory, but cannot call > into the filesystem to free memory. Generally this is because we're > holding a lock or we've started a transaction, and attempting to write > out dirty folios to reclaim memory would result in a deadlock. > > The old way to solve this problem is to specify GFP_NOFS when allocating > memory. This conveys little information about what is being protected > against, and so it is hard to know when it might be safe to remove. > It's also a reflex -- many filesystem authors use GFP_NOFS by default > even when they could use GFP_KERNEL because there's no risk of deadlock. Another thing that needs to be considered: GFP_NOFS has been used to avoid lockdep false positives due to GFP_KERNEL allocations also being used as scoped GFP_NOFS allocations via different call chains. That is, if a code path does a GFP_KERNEL allocation by default, lockdep will track this as a "reclaim allowed" allocation context. If that same code is then executed from a scoped NOFS context (e.g. inside a transaction context), then lockdep will see it as a "no reclaim allowed" allocation context. The problem then arises when the next GFP_KERNEL allocation occurs, the code enters direct reclaim, grabs a filesystem lock and lockdep then throws out a warning that filesystem locks are being taken in an allocation context that doesn't allow reclaim to take filesystem locks. These are typically false positives. Prior to __GFP_NOLOCKDEP existing, we used GFP_NOFS unconditionally in these shared context paths to avoid lockdep from seeing a GFP_KERNEL allocation context from this allocation path. Now that we are getting rid of GFP_NOFS and replacing these instances with GFP_KERNEL and scoped constraints, we're removing the anti-lockdep false positive mechanism. IOWs, we have to replace GFP_NOFS with GFP_KERNEL | __GFP_NOLOCKDEP in these cases to prevent false positive reclaim vs lock inversion detections. There's at least a dozen of these cases in XFS and we generally know where they are, but this will likely be an ongoing issue for filesystems as we switch over to using scoped memory allocation contexts. I'm not sure there's a good solution to this. However, we need to make sure people are aware that GFP_NOFS will need to be converted to GFP_KERNEL | __GFP_NOLOCKDEP for allocations that can occur in mixed contexts. -Dave. -- Dave Chinner david@fromorbit.com