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 169EAC3DA79 for ; Mon, 15 Jan 2024 23:01:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9EC936B0083; Mon, 15 Jan 2024 18:01:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 99AAD6B007E; Mon, 15 Jan 2024 18:01:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 813B16B0083; Mon, 15 Jan 2024 18:01:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 53BB06B007E for ; Mon, 15 Jan 2024 18:01:25 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2B376C017F for ; Mon, 15 Jan 2024 23:01:25 +0000 (UTC) X-FDA: 81683068530.20.6F55945 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf29.hostedemail.com (Postfix) with ESMTP id 62732120018 for ; Mon, 15 Jan 2024 23:01:23 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=vAj6fa0Z; spf=pass (imf29.hostedemail.com: domain of david@fromorbit.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705359683; a=rsa-sha256; cv=none; b=U0j+bbj0/MunkLnCjMr16ySUHrAs6q3ULi7p/KBN4L025zLUbqd7dZ8bl3amgc+K/Gj3U7 fBj8p7E0g0e+3KC79H0qogcYIJ0qz+D2qwZAGF+tstXH99VqZtDmG3u/Y9m7M8jOX8hXim vj3PPlYaz/ZmkkNHIOXvMaIizlWi6sY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=vAj6fa0Z; spf=pass (imf29.hostedemail.com: domain of david@fromorbit.com designates 209.85.167.169 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=1705359683; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=PfagMjm8PzVKMrg+wKZGGhVGZKWxo8fKxsB+lSjhnWs=; b=rEC10iJFE0gRPkIiMrBGztmmTqcStDIC0GYk0YcLw2Cth7E48IPR9m894umFVfLGd86Og8 NZNrHPLvFDqtSbwziddxXbwV2VcslpxxQMX8SrOLfaoncakJ9mVEmQtXY9m2ZUEP2LcU7f zTJSDlFybEoPPPLW41QZbuT24xDc/DY= Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3bd6dc05690so1759932b6e.1 for ; Mon, 15 Jan 2024 15:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1705359682; x=1705964482; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PfagMjm8PzVKMrg+wKZGGhVGZKWxo8fKxsB+lSjhnWs=; b=vAj6fa0Z/mgI1lsP9ohd7qHdXgiAvXFWFR5W3BZDVZk6YYEEN6RMXjL1erLo01HMe1 1TYeJ3a6n/XfGvXXTU10x1o5KYQOaDqFyIpp36irqsrCRTxH32W/tb9cRHBp6mcOTtit mewiOFdfkNAu11qcQuhJI+1RMU4oraqaO2av9EI7j6siHdhE0aY716yiPQ1ft+y12vQn GTwIXDXvxpgumX8WLK2b9u7ba8mp+8nzmv4VlcmckBs3RgNOx2w2H0sFxzZRi2nr66GI SwxQiDBKdk5mO4+7KMkzIlpg/3eY/Nt1t0TJ0cb9XvDSkddLrB1v8BX2EEq2UqUDjIcq s3EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705359682; x=1705964482; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PfagMjm8PzVKMrg+wKZGGhVGZKWxo8fKxsB+lSjhnWs=; b=fEXMA8tb5cCe6jeI6pQBM/CA2OgImqgyFw1VlcEN/BK8epVuau4XEp8tw26nJVQZLn +U9kzja8cMOddEBSG9DNbj7B7v2besmtNQxm2/RGFOPHYLx15RRay1dj232crzoSl8pm dqOzO26KT4dXK4WNj+lOIbXLMvf0tNkEDHMTYJCmJWmIGLuKk74jwrZPhnRHjq8LMJbA Md8WXLdGdQOkBe0szJQ7UUKVf+n8NECVQwoJ1gkMxx4IyjeFRmC46SJUf24JoR635Xc3 oLU6XIanaWkwriMkNWqHKdFrwiwrWioxtrZNQs/8xENbCzLgaWxOoKFOjr015XxtqiO6 PPmQ== X-Gm-Message-State: AOJu0YxN1xadjYFLaD88Q5XUa93kTZJLcWmZgXoeS3nQb/tBGMk76seP ejGeqnUOCRgapzG5uGj5mKsMFrBq0COLkw== X-Google-Smtp-Source: AGHT+IHkhOvev89Uh5PJlnac0EvcFktAeoujulicV1naw18eGcOKMz6cfBXcgmSg1iTx87RfrIm0Rw== X-Received: by 2002:a05:6808:210e:b0:3bd:3530:d051 with SMTP id r14-20020a056808210e00b003bd3530d051mr8141840oiw.6.1705359682649; Mon, 15 Jan 2024 15:01: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 k2-20020aa790c2000000b006d9b32812c2sm8075868pfk.101.2024.01.15.15.01.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 15:01:19 -0800 (PST) Received: from [192.168.253.23] (helo=devoid.disaster.area) by dread.disaster.area with esmtp (Exim 4.96) (envelope-from ) id 1rPVxD-00AtJo-37; Tue, 16 Jan 2024 10:01:15 +1100 Received: from dave by devoid.disaster.area with local (Exim 4.97) (envelope-from ) id 1rPVxD-0000000H8VL-1khK; Tue, 16 Jan 2024 10:01:15 +1100 From: Dave Chinner To: linux-xfs@vger.kernel.org Cc: willy@infradead.org, linux-mm@kvack.org Subject: [PATCH 00/12] xfs: remove remaining kmem interfaces and GFP_NOFS usage Date: Tue, 16 Jan 2024 09:59:38 +1100 Message-ID: <20240115230113.4080105-1-david@fromorbit.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 62732120018 X-Stat-Signature: s56tq694jmnrqkukgzticmi7g4p6kh84 X-Rspam-User: X-HE-Tag: 1705359683-667 X-HE-Meta: U2FsdGVkX18AWcxqwC6uGAnYCQu1eYo5vWo7RDzh0wWozAj5/M8Zx/HlaJ/zENoke3KTW8Ji6jzlvLap02wPvEJpycPd2m1g0tUX0H/o4xA5LenZXtBQpJkx73BvrX7beHBGsSZV3SwTTL2xTesH4mR46p78c1sF81SrgVG7fAwZEzOJzgsMyrTiB24Pe9g2mSZDqU/PFtSklG75LmGXCO2qbspwVxUvMMPhhxttG+3cKz3QNN7hOZHUxTmvkT4SNA+dmoskyhdxG0sshLY6pM0eXyff83z9sjrljz2IoAQnxAI/y5Q7vfnUpf2vebAZdGC+ZyGd5XZkPgUEXDqOow8j7QmrzT4FrUL2cB3CjgS3i1Yga5kQamkWyHxqVCjYp7hVPjlrM+quHUlAlNGt/2ynAUTId8fEpGc9SPNGmWv3OOky/9iB5nzENwakzzRzYA1kJQFlSUZVpNDtoS0367qjFnFLqHF6IBjSHl5WSPjVADnzDJBj9t9LqzfNqgCsEstD8eVS5ttQeCsbK4k77/YYl8k0wpWZOYyHlDrAx9IowEUJNmtbBRy6/EgtSnhH8c7G13C7NiGjBUKPolGsxiThUanMgBITl3oigUFtKDEE8IBLyzobsyG4K6SpE5XFGiTVfLWPVjkY5c60ZVD+NF+OMe9sYAYTlHN3bscLitw7kei5VKGj6uNO6ALYs6UrsBkcjBV0p7ZOhGx2hnDkIQwRPq9phN4XsS9DmsbncA5FlUgSeIn7xuyRknxp0xPSg+iwP747I+Ql4UJJ20phEdeORIQOhZBzK9z28qCpfWVAhx1XnJa1epIKRBVSMMWyvySaPl37VxzWAv7jyX9uPaYkxmKr83gSG39Tsw6sdiwDl3+WPgHkZwnrf7chp0jGIyucxjome8Yue59w5dm7HHRMBDk/gpvVlnXYzk6JOm2c60/YPiO14rBKb1L6vO50Nzi4WFyukdhLDgCyN8V cFCHIqfm 9JgsamHzeUpis9G9tn6eXZN7HKIG1OxqCnYpU06oZRxYBlsW0mC36GeIVIJW9uFjuscrPnWuy8OZ64yq3332/nrIxn6V2o82Oj5YDJh4Zqha2zxeIJ9tRtEAxMgpEnx0ZSI2gHbAa6epIreTkLqBWQ15Iyx9oYgRcwZQ2Z9PHGYeGmqDpjpL+Ylax6BYsBno3Catukugo5gDH3njT7lHc+wA1jxMnYChxzL5Fcf+fBt/4TySM38sbmc+G9mQlFU7TUK9/p1I4yquGvIZCrKJtk1wOvchKHDiN/PQ1NzBha1NCd+HzaKYGe6TF0IIVzfQSWh1lqpCoUn49PDZv4l0cl3CoXWUKmdCLpVPdGuT4epQS6cyRF75c1ypkA1zjeNjI7dBY8WGJODpbLERHOWctVAdo5gqyfQ4aSULwQB6pLexTg0B2p3N6Twow4iPT+yEqCZp2dmC5t84nvhQcPaWUpzY0VFejSyj2ZKotUE1Paw4ToK2tA5hdHVqibCpyTcNPRi7R X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This series does two things. Firstly it removes the remaining XFS specific kernel memory allocation wrappers, converting everything to using GFP flags directly. Secondly, it converts all the GFP_NOFS flag usage to use the scoped memalloc_nofs_save() API instead of direct calls with the GFP_NOFS. The first part of the series (fs/xfs/kmem.[ch] removal) is straight forward. We've done lots of this stuff in the past leading up to the point; this is just converting the final remaining usage to the native kernel interface. The only down-side to this is that we end up propagating __GFP_NOFAIL everywhere into the code. This is no big deal for XFS - it's just formalising the fact that all our allocations are __GFP_NOFAIL by default, except for the ones we explicity mark as able to fail. This may be a surprise of people outside XFS, but we've been doing this for a couple of decades now and the sky hasn't fallen yet. The second part of the series is more involved - in most cases GFP_NOFS is redundant because we are already in a scoped NOFS context (e.g. transactions) so the conversion to GFP_KERNEL isn't a huge issue. However, there are some code paths where we have used GFP_NOFS to prevent lockdep warnings because the code is called from both GFP_KERNEL and GFP_NOFS contexts and so lockdep gets confused when it has tracked code as GFP_NOFS and then sees it enter direct reclaim, recurse into the filesystem and take fs locks from the GFP_KERNEL caller. There are a couple of other lockdep false positive paths that can occur that we've shut up with GFP_NOFS, too. More recently, we've been using the __GFP_NOLOCKDEP flag to signal this "lockdep gives false positives here" condition, so one of the things this patchset does is convert all the GFP_NOFS calls in code that can be run from both GFP_KERNEL and GFP_NOFS contexts, and/or run both above and below reclaim with GFP_KERNEL | __GFP_NOLOCKDEP. This means that some allocations have gone from having KM_NOFS tags to having GFP_KERNEL | __GFP_NOLOCKDEP | __GFP_NOFAIL. There is an increase in verbosity here, but the first step in cleaning all this mess up is consistently annotating all the allocation sites with the correct tags. Later in the patchset, we start adding new scoped NOFS contexts to cover cases where we really need NOFS but rely on code being called to understand that it is actually in a NOFS context. And example of this is intent recovery - allocating the intent structure occurs outside transaction scope, but still needs to be NOFS scope because of all the pending work already queued. The rest of the work is done under transaction context, giving it NOFS context, but these initial allocations aren't inside that scope. IOWs, the entire intent recovery scope should really be covered by a single NOFS context. The patch set ends up putting the entire second phase of recovery (intents, unlnked list, reflink cleanup) under a single NOFS context because we really don't want reclaim to operate on the filesystem whilst we are performing these operations. Hence a single high level NOFS scope is appropriate here. The end result is that GFP_NOFS is completely gone from XFS, replaced by correct annotations and more widely deployed scoped allocation contexts. This passes fstests with lockdep, KASAN and other debuggin enabled without any regressions or new lockdep false positives. Comments, thoughts and ideas? ---- Version 1: - based on v6.7 + linux-xfs/for-next