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 B173CC4332F for ; Thu, 9 Nov 2023 22:14:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D61B9280013; Thu, 9 Nov 2023 17:14:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D13AD280009; Thu, 9 Nov 2023 17:14:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDA1B280013; Thu, 9 Nov 2023 17:14:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AA9DE280009 for ; Thu, 9 Nov 2023 17:14:10 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 548ACB5F71 for ; Thu, 9 Nov 2023 22:14:10 +0000 (UTC) X-FDA: 81439819860.19.5A955A4 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf18.hostedemail.com (Postfix) with ESMTP id 03A0A1C0008 for ; Thu, 9 Nov 2023 22:14:07 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kTEO7rgE; dmarc=none; spf=pass (imf18.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699568048; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5N3g6L9ZUjyhMKhQQdOz+kKkSsDqd4jP0CN8/sGAxFc=; b=WTYJg14tolkuP9a/PVAsIecjdufnFThNO1JE+bXB5e8kCkNcxPX20EIHtlRSG5reG2N2AE xP3XEbbaNlvEEEXSAo5o40MHLM9WdVN2Xydkq3KsHXoL/TLymQs73E9WIzURkPz4XFkyHf w0rmiQKz//K5cVBJPsdjWhrRyFXy9xA= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kTEO7rgE; dmarc=none; spf=pass (imf18.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699568048; a=rsa-sha256; cv=none; b=Wpdi/nVtVmZVTxpTiW2k+RZrRwj77EE4BeYpXHveUmRYSwpglaWaetgSvbcDWR0nLVULrE gDo/cbQ5Jn+ufjnw7rE1fRMjhZpVp0NjuWtcm0yoZotj85K6koz4Pu/mxLLerB3zrgE6Tu tHx6L3TX50PHSk4c3KidUYv/8WeXuRk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9539CCE10D1; Thu, 9 Nov 2023 22:14:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0890C433C7; Thu, 9 Nov 2023 22:14:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1699568043; bh=I6BvnQkMNjyMELc/F4h2vOUAiBMi+6ICmcsjmFpUbxo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kTEO7rgELxOEzYhJPireWKiC1ovWouhACF38DYn/EqhgKdWBNewMtwe8VaHdHJzfj Su2mTYV4XCEacGg/yxafgOwRP6EHgYOdJUd7svwDXaqTB1qBssPsA2xVFCIQMTa/CA Ji+KTVxnzmbH9AMMbACohM23GCX/kajZhTAVwUvk= Date: Thu, 9 Nov 2023 14:14:02 -0800 From: Andrew Morton To: "Matthew Wilcox (Oracle)" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] gfp: Include __GFP_NOWARN in GFP_NOWAIT Message-Id: <20231109141402.11f951a83a742465f5306ba2@linux-foundation.org> In-Reply-To: <20231109211507.2262419-1-willy@infradead.org> References: <20231109211507.2262419-1-willy@infradead.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 03A0A1C0008 X-Stat-Signature: jhgsbk9ypkbih4pqyxsaw5ti9kiixx4f X-HE-Tag: 1699568047-156828 X-HE-Meta: U2FsdGVkX19tu3FIK0f4FSOi5nKxmvKhER1egUcA7VK+fQzw5zvA2csS/7URpeil0Ik8iOFO0EeRQlnLCKNsQBh9J4E/ZgehMDmVbWj4e2nIV4QPRAOSnvVhQIMwbSP+KxKUS/CiDzgsGhTmmrtKOCUhdztKyrt0pHL050lQrGzh0jyyxZkgi7tA4vZ02Dw+YGeV5Maybrk900bMNDfs6ienKjUWl2gE17Z+3pLbnjWLZdIJ9jTcvJ8FN6NRjh81CRTpJj1xdZUysz4EDoaBwS2lTQC3flSWUg5w83QtmF4zLErGp+gCM50udubg6MR20Iitzxfs4v3WyF9Qr/w5lISVt8UjItzsfdKVPS4pz0i5C5C1UrvhFWpappN3WMq0tQdh5LGmONkijnp4zu/+08OxcxyR4l6be7DOwJ7faMgGo1g3CD3zkdVXxXxorsBiOCIPm70XMvbhN2FtjdkL9ezGXh1NWHXGY8MxywDwYCSzxDTJzBufQdXbqz7ImVoQMnXtUIkOpOrRfORbmywKsfYShPrIaqMaD/p+xNtryfxnKJTH4JFMzFMz1bvbN+xKz3O0E6SnXf+TFCYKtydVpF0GOobbitKRmPA82EPOQS3VQUSZcy+4rtGmG1RqxVXTraIbkjt9z4T7p2I1H9MbshpIAIWiJkItwLS8y/0UZZEc7BrbZ6prNHrpHoRQ/I53O7Lcd4uE/LE0IgqaE/eYSCwyG9wZM4MaMahEHRuiRVrVQ43KQm/qDIXXwQ6SdSGDMwKQvr4DfN3wafmmMNtiiZyZO8fZHPi0coYeZpJcgKZYuPaWfYgP34pSMzOlRGP+KgMu0U10Hi5on9cQzblcRterLNaHE/cp0XUEgFBQ59rCAB9BXP8WOXzS2lo1mV9AQt/HBFBeFblGc09ZgtklGyvjoyJBU9+t7UBCIl1gqHdMSUmsNTcxmVFF7X3HVKayfPG6A+RIooBPNOmWTaW qLZYXcY8 ZLkc/tKv5dnKLWTqRjY8vhI//tORF8hPnZQEY9imqit/8bvLHyMgTAE99MQPAsyfO9LYLBoIbVCeI6oULFDvlZvN/s675Mb7B41Dj2SsBO+iq73sGWh2iYD8DA51LlO+wvvIGy50Cvm2caAzcSblO7WNDzV+YTZ/ZMesceOlFRBn+zCWGMHZjyNECeESShdjBVJ7eXo5jH2j+CkZ3iVPrmVv2ywGS5AjzHu9HtBIn1ga6++VgcL8xKBWRXcD72/hSTGbG5eahxx7edC+4xdCdkz37b6abZesHiqlCVqk1SPxLQH5Ha6avGBWOs/+gYRmNRaR2t0iyqLRZhrQ= 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 Thu, 9 Nov 2023 21:15:07 +0000 "Matthew Wilcox (Oracle)" wrote: > GFP_NOWAIT callers are always prepared for their allocations to fail > because they fail so frequently. Forcing the callers to remember to add > __GFP_NOWARN is just annoying and leads to an endless stream of patches > for the places where we forgot to add it. A possible problem is call sites where the developers were relying upon the core MM's warning, so they chose to omit __GFP_NOWARN rather than adding a local printk. We're now silencing core MM's warning so those developers might lose some diagnostic information. Random example, arch/s390/pci/pci_clp.c:clp_refresh_fh(). After this change, the pci_clp developers won't see (or be told about) allocation failures in this function. If they know about this change, they may now choose to add a local printk. It's not the end of the world by any means. One possible way to prevent this change in behavior is to add a new __GFP_WARN and go add it to all the sites which use bare __GFP_NOWAIT and which do not have a local printk for the allocation failure.