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 4D477CD128A for ; Mon, 1 Apr 2024 21:31:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 473DF6B0088; Mon, 1 Apr 2024 17:31:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4249E6B0089; Mon, 1 Apr 2024 17:31:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C8576B008C; Mon, 1 Apr 2024 17:31:04 -0400 (EDT) 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 0FA696B0088 for ; Mon, 1 Apr 2024 17:31:04 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8934540876 for ; Mon, 1 Apr 2024 21:31:03 +0000 (UTC) X-FDA: 81962258406.11.3B9A222 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf05.hostedemail.com (Postfix) with ESMTP id 8C2ED100014 for ; Mon, 1 Apr 2024 21:31:01 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=zAOM8Gli; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf05.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712007061; 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=bYJV0ECVuJqRmfLJwnmV6ZzS780nDs1IJ2uCW4Tldqk=; b=roZH+BuZTQFqdt6WAogjKX8n/q8HQVcOzNL/aLO96aYW/mk5N1fxeUgaLGpB7bI3lxlE8l zHsRKZ7ml8tZPWUC23Zg3flIX4WVz+6IDV0VNbyTUEndOzr+HNPLB9YF5+oPYRy50kkt1h ZorOY9jtECgsg3I2xTXWMb8GEuL+88Q= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=zAOM8Gli; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf05.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712007061; a=rsa-sha256; cv=none; b=G/1ukWcydfv84sIzSKA+2MRkxVMhIcV1R5J2aAS9csSqBIVG5HwVTK5z/y6X+B1I2bq0cM QuhkFwC5vkOWdTuwyWWRfhZffpOnAndH87LZjNP4cy7UE8hcM7Ydfl+QF6anGNw4jS7kOh LTEGDi9XM2LoNb8r109oP66iW8FzPq4= Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1e2178b2cf2so33723775ad.0 for ; Mon, 01 Apr 2024 14:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1712007060; x=1712611860; 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=bYJV0ECVuJqRmfLJwnmV6ZzS780nDs1IJ2uCW4Tldqk=; b=zAOM8GlibOWOVCbpaRdoSYnMXyL6l7ODo4K/jK9WIKB3wf1AZ8zD1h9pFRyGpBgVk3 w+zNhOl3ynI36QpWYG9szQeg4Qcup1Q59kGknRm24k1vFPXCXFmJYKNmuq++5z3d5Osc /hJ/wBaGdBFcO8I0pv1QiCPGxWjQP9Y3/PwKsU52R3Yqu3elofc9IRfIJ+s94h6G5T+X bMZddWR7fddZupDMC+wZFLRf0PZG4u5nos2F12KW2hJ615i2b1OrkRH3Ios91/bzYCg9 4B1V7HsNBwsfbZ00S7JikpjSGw02Hu+2EIkOamKPv846CZPqw9dfUIpgSWw416+cXeno e0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712007060; x=1712611860; 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=bYJV0ECVuJqRmfLJwnmV6ZzS780nDs1IJ2uCW4Tldqk=; b=Sy31FzmBdfWLrylUPIy37FPwN/5uEmrhF+3hCyulmOl1UH3c/37mdi37fKKMB+EIz/ rDLI3pLRuHAJOcFfFjochg7OFonYR566sSsGcdhBjNwP9Z3hWHfFj5hahO8kQ15iyfYX WHvl5EG7d3rGGLESgjp0CdJ57HZdznXSjuSbukMjzXb4bpF++6GZxih60p1/vEog6J4W J5TzGUDmlxF/0avtZAMnVqQtT8pAkv7z3uCswnZWW9qHFeAn3L7fr8ip/vYsfvmPLXFv mf7FTG1lWiJ+WsA3Uwv93TWUjlxuuGXGEjU0oCdowu+P9dhhvkr8QjyPxzxwoqylf1mU l/pg== X-Forwarded-Encrypted: i=1; AJvYcCVgF606D9E+j8gMiY7oE42O+EBxSPdEQWQKIG6ueWitLnJPhkjJa6nhIcoXXzZuBUa1lKuA6bOAiNerXvzYt1qztmQ= X-Gm-Message-State: AOJu0YwLMYLRUb5V/Yph2jE/din+SBg7+ixZlOb34sGQ+3EhiXrIw09p gfel4chR4+DHzc10MkWDXB3CCdHAI6UUoaAK6uQT661jYJL8ZsOZdUvmOGat8MY= X-Google-Smtp-Source: AGHT+IEv9VabAjehGDKqJqk4JIaXF60juLsyC0Jbsmz6MiN7aHC7IPALdWdmtgRI9S2wCPbXukBFkw== X-Received: by 2002:a17:902:6f02:b0:1dd:d0b0:ca86 with SMTP id w2-20020a1709026f0200b001ddd0b0ca86mr10917821plk.59.1712007060120; Mon, 01 Apr 2024 14:31:00 -0700 (PDT) Received: from dread.disaster.area (pa49-181-56-237.pa.nsw.optusnet.com.au. [49.181.56.237]) by smtp.gmail.com with ESMTPSA id l2-20020a170902f68200b001e0a28f61d0sm9402900plg.70.2024.04.01.14.30.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Apr 2024 14:30:59 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rrPF2-000c8I-3B; Tue, 02 Apr 2024 08:30:57 +1100 Date: Tue, 2 Apr 2024 08:30:56 +1100 From: Dave Chinner To: "Pankaj Raghav (Samsung)" Cc: linux-xfs@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org, mcgrof@kernel.org, gost.dev@samsung.com Subject: Re: [PATCH 00/12] xfs: remove remaining kmem interfaces and GFP_NOFS usage Message-ID: References: <20240115230113.4080105-1-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8C2ED100014 X-Stat-Signature: uhw5b9iqxdjubt5uogbt7y1krwc7zc1w X-Rspam-User: X-HE-Tag: 1712007061-95965 X-HE-Meta: U2FsdGVkX1/O74bNRaKNEcyFMY56KnuwdfmQ6nB76zw0TgPNLDi3f8tv07XhMRS8qbxhPecbWajcTJiYYNN9Y1HITV3mngc7EfQ6yNOQXs7Eo1duBrarrwc0WhTM8j7KdibF0BAUig6ARwq2w6zjbu8Tn4SpTH8t+nbiIauPEifFFi4B7HdyaIYF5gySx+RwM6xyDbw8e3nBR5vSVL6w9W1Wfn7SNSNLMnfB06o7WuZDzNmrvrrMdV5PuvV866ASGb/BbylosXZU4QMngPSi2CLAQqx6svhw7hfX/3BZ8lVGrjDFpSBpSYL0TAWH6f2QnhxA5hr+pxsX4iUnh+c+mo8vfOylCrXVWRSAwNYguSwSFCiFkGTKS7vUDCFP9zGXWBdp8fcDW4mmYlY/1Bz1XmsRioV1fyLpWj7VWFealihh3s5SDG/i/s+c3qL0zMsKJjvGFvk+/2tZFmukoj09kjbc+9wX7wCfjQAzBrcgIfS9t3eNzU95j08IbLefG+GeQw3qO793zwqIypJC0HRhjcVzGVJ5tLjIzhwu1N/g0GMvLbySMrpXUfg1NNE8JSck/lU8X3siNcMv2z5j8jMIra6yGxOlhMXnOzj3fLBQ7BWntuarq8Uxwe8qIMQOpE8wIIEAuMVCdi84gO8c1CWw7Inm/BMgCTMFQ9Mjs9mlS3G5DXojNqDOFgjTyNnsFEtjW/l22zyiO4xN3BG0TWkgKKjjd5QoTnOerl/n5lQSqs++eKaAplp8VFvWsgqZ17OL2qkV33sPef1uQCDQNKkKoLa9wkbKmfifMVqcWafLW6f8Rf4w9Jbk9er0v8JhWPxkDAdqUSNlO7xf/bf5piX4KxXprKymJ7h/X4CbKriHK+bd2Wbj+UtLrGPJD9qyRnpX8ESd9/Pp2OrW9mNb1xF8pRoj8gqVBU02ChVgoXBRnrKaftJREhw3lWBKkAJM4GnSsCKQ3NO0bKf6B2XkR81 hBqgwk9e Tk932iackFfaTXNodxHvDv1C/SUW/AZn4HXFzAVxIO8pNeDyfa2T07hFAlx5UtW/P3/tH6JeQqGkZAjGQVQ448V64l78dU1H/KFfoBQoJs5j/iIPLQx8qpxjLPAc6xScZUKvcmcvXhqxcYKYhc5wweJmx8W1B79/M6JW35bCT0MBI50aeJU5N0T3huGXFd4SBkZZN82OBacvVH7iBD7hZGFb9HBt6kC8SFA8Ya76PYd6+zd48HiHHmk3i9I5BBklFBTOhc/XLSmxh/8wNYWT33cuxE2+pDbBy+XkJxWM6ISClToiebLbtooNhpiXTsuVAKLbk9a6NRBlwwqFrr0G2ywmtFomgbSDFNWyRnemKOL6xv2IoFsompO8s42StYckVGCaQTCZOZ5E4zMliOa/w48RE5rshEZIEBdpDSuxecV3YR5JOmy8ojWSfbMyjWHx7XpBNb0sfRtaF2DojIyDdcyVkgX0TC7zEhlFoRLFzhQiPzqFXHVpblAd9sw== 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: List-Subscribe: List-Unsubscribe: On Mon, Mar 25, 2024 at 06:46:29PM +0100, Pankaj Raghav (Samsung) wrote: > > > > 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. > > Definetly a surprise to me. :) > > I rebased my LBS patches with these changes and generic/476 started to > break in page alloc[1]: > > static inline > struct page *rmqueue(struct zone *preferred_zone, > struct zone *zone, unsigned int order, > gfp_t gfp_flags, unsigned int alloc_flags, > int migratetype) > { > struct page *page; > > /* > * We most definitely don't want callers attempting to > * allocate greater than order-1 page units with __GFP_NOFAIL. > */ > WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); > ... Yeah, that warning needs to go. It's just unnecessary noise at this point in time - at minimum should be gated on __GFP_NOWARN. > The reason for this is the call from xfs_attr_leaf.c to allocate memory > with attr->geo->blksize, which is set to 1 FSB. As 1 FSB can correspond > to order > 1 in LBS, this WARN_ON_ONCE is triggered. > > This was not an issue before as xfs/kmem.c retried manually in a loop > without passing the __GFP_NOFAIL flag. Right, we've been doing this sort of "no fail" high order kmalloc thing for a couple of decades in XFS, explicitly to avoid arbitrary noise like this warning..... > As not all calls to kmalloc in xfs_attr_leaf.c call handles ENOMEM > errors, what would be the correct approach for LBS configurations? Use kvmalloc(). -Dave. -- Dave Chinner david@fromorbit.com