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 4F6B8CD3431 for ; Wed, 4 Sep 2024 07:14:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D41C96B0417; Wed, 4 Sep 2024 03:14:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF1286B0418; Wed, 4 Sep 2024 03:14:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B91C46B0419; Wed, 4 Sep 2024 03:14:35 -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 91F286B0417 for ; Wed, 4 Sep 2024 03:14:35 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 30CE6140D67 for ; Wed, 4 Sep 2024 07:14:35 +0000 (UTC) X-FDA: 82526192910.22.6D9B6A5 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf03.hostedemail.com (Postfix) with ESMTP id 0CCB12001E for ; Wed, 4 Sep 2024 07:14:32 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=FmQHNGdV; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725434025; 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=qnMooA7Lbyg6swfN/5rgVwe/kJNmET/0maFcp2nTGY4=; b=uzP8RUVqUkCPNN+1hCOPVMtxDQ7hmgnNUCtlp0fyIZUC2TMeX+S1Nn0SJuAri+NYM4z5l1 8X18NPYpXoKC0C8G/NuAR2quAruYXva+rhVS8U1IJ5gaizcdINhS0f+LN3rzHTIiAvWkZp rOfz5P5JTMZjT4YvYp8kb+n795EsKl8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=FmQHNGdV; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725434025; a=rsa-sha256; cv=none; b=rv0kEmnGipDU/WgxljhoRsldYG0p6JY/X4HfLH+Lx3wfAdAlgWYjhIaCA2FIO14Zq6W9V2 COuvpf0F8AzCUzYbmkFzOrETFgZC53OrZZqpTqLgHitaAFY56zWTTuYQjFtNleqnUmUspa ogC+L7woBR4N/e598M2xtJ2zEx0NDKA= Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-374c3400367so2620374f8f.2 for ; Wed, 04 Sep 2024 00:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725434071; x=1726038871; 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=qnMooA7Lbyg6swfN/5rgVwe/kJNmET/0maFcp2nTGY4=; b=FmQHNGdVvoPry5XYA/Z1KS536SKPRf7B4x7yQy+3jZ3okV4F/f0cPqeBF5g5ztBXpR Wb/4BnxZQbQZuGrj1dPVftxgA3BQLmGZjq76eQeHGQX/Unaz3TbDMd5R0x1uT1BNpNtM LuACrz4slHEN9ReHcguylAAlOGNNYXKzL+ocX+rrBxbHJgi5HIDcN5dhYHl/ltfSx7ag aqlw8sz6nBlp61u2bd+hLgdc02JAZzsxWO72GLq0LrlMpBWdw2LyyajCEzyE9va6VffU wGpHs2HfnNbJ18pkIIXBsbjgYPoEcie01ejELwHA9FF/NfNDwqooqhvuDRlC/GCqD+8s S62w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725434071; x=1726038871; 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=qnMooA7Lbyg6swfN/5rgVwe/kJNmET/0maFcp2nTGY4=; b=BZMBSG4cmWe1DTdc18WMQgQ5nslDpFyT1fwAJxTO1o+aPFnVhU21lqpkmRVFw/TyyW 9jiej+JE7Y7d5Cri+Y82ZsMQtBnv627bapHxMCjCjWoqFmViR9BOh2N4/OIBTKJptPgC y9KVmA5NG860wfc+UcNoYVd1rmfFEj2+vOOrfyT7AW4XoCTjG9hMwaH9caT2S0LdSOxC xWp83i6FsHIHlZ9gekS6YEmAY0KEmMcQJBUQtM41xgJQnOzLptD5xNsAF2aLSr5yM6ZS A3BROi/nhkzu53UvYZr3fusMpiRM8D5dbXZWJKhOUXQkZkxZiEsypT5dvwZ3OrWat7u6 /1mA== X-Forwarded-Encrypted: i=1; AJvYcCWOH5q7tmvqJr5/eBetHpT7xgB7DbM/LkYr9E3h4GMPzfKJlKaMkOBwXMYjL/TWuoH+VTfehyJbTg==@kvack.org X-Gm-Message-State: AOJu0Yx//58x/whnFp+Qax5GywT0m+ZGM9Cc/on1HrJ8RKq/l9YTGesS r/0/jDJar8CYSbfaKvTwE3+xOY/OZLbRai8txUd5ZXBFoZn7XlOE2J6EkTJug5U= X-Google-Smtp-Source: AGHT+IF8I6pFlzOU3p9D8agMKGZIZoWQQ9AW1+2AmZCmzaC0dDVMGKQ/M7w2avm8V9SBZGoK10RrWg== X-Received: by 2002:a05:6000:124c:b0:374:c29a:a0d6 with SMTP id ffacd0b85a97d-374c29aa194mr9448975f8f.2.1725434071394; Wed, 04 Sep 2024 00:14:31 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a89891a3eb4sm774269866b.133.2024.09.04.00.14.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 00:14:31 -0700 (PDT) Date: Wed, 4 Sep 2024 09:14:29 +0200 From: Michal Hocko To: Kent Overstreet Cc: Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, Vlastimil Babka , Dave Chinner , Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Message-ID: References: <20240902095203.1559361-1-mhocko@kernel.org> <20240902145252.1d2590dbed417d223b896a00@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 0CCB12001E X-Stat-Signature: ztdojgop34gd9egdc1a7y4ug7hsadmns X-HE-Tag: 1725434072-640429 X-HE-Meta: U2FsdGVkX19tNJOSO4f80WEjvyp0dp9ci59qhKTCexq0qNllB3BjPbYbLgfF61LvDDf3Lz2VU4QB9N+ELwqc6TjsVDWfM7Y5dzEEGLQpJ8umzR5TJwycYw/MfqC6tK8BR66Q8JHdnlGVTiSgi5CjmtRGGD+p6cHqU48vin0P4SX0ZlbcOZKNcB5AgEuWKcSo2R7UAaMFPPzZo04aklswxbT7GYG23de7uIO4TU6wB83d6ucQc3TjRvpsAR6G9rAlNN4czuLIZu8asij3dF/72lrfEzaON+FfsOgkJc8xu/FdlJPv5RESDfn76OFWaPexEOUlpkPXOc1RlF4devOtxfa5MXbzAZURo9ZBELUPGJWH+YPXzR8XNIl0L/2Jal+4YMCKrXdu4iGcYCM6ULlCOODnNy3MQrwF/sMOFpDdTzwSI1p4gD7kjVw2R5BI2V7qe5H2o8zWe/x5BUR1ISixnx5kEk+q6CJAjKnJfp+QR5/q2cTR0cdt1P0H98yX48ppsboLNuKTDl5vXRv6O+PTW3K+n205Ndeu2VPsjPmeprgdH9ZhA9PK0cmITOTN6KJv7m40OntBa4h2DCnEdb68bg+cHloD3cD77cdJ0LK8P7EMXaZN1KhiPt1P5hhTixYDaVoiBGE9csAcW/muea/Lj+R51iWy6/WFOVpk6HWrKdVt8T4AFB+qZ0Kjt5FvU0avuaQDYIQLHdeqBVspnQggZ8CcGphiT27sYT8HkIkeHz0jhoG7oYFiG8BvUuQ1eC+7Q5wRVxT6N23cuITv1lAH52zsxNvwWRufxWASWSBTdBOnYsxGtv87h8TQyOE3nCag7Fw6FiwCToVkkCnzeRzAczhmDaH8NI1soX4nbWUKeO276nV7ykkSZ3Tysr4w32YzA3G4b2EqxPv+RTO0JNzqDmkFaePDsWtRw/dxrZdKknjqeSE2++M86tVkOAQSGAmZAKzAJYU+HjyOcrPDx/X hLjks2h0 FrfXAhMAqtArzPTlk2MgMp+RnOVzjCoDcFiQ44CuMsdwY6J6R4OI2AisC6AikOf3AfvybUjzga0BBaRgXT55IK/qiyTBdDWF6Tht0Lp5/OB8w9/rtfctfwemQ9dhkotQWElt4nFlyyqTx8r+RM5Kmir2U0TrFQ2Tz7CqFZh3uN1D52+xv4KvUNzDevaRNbVbHJfajRtns195QPoIHVKJBFnCJQqyh9vOPuxoJ6ICgBFLNfAaXnLfPso6j2kFZ0aaaxDdms1doKz4vD2EakeAiQ5gLOOMHudhEZO/5e9tEfHaTzAdWJ155AbHW1nS9w33rLXcWR5Q9BlYE5PuJ+5VNJ+/GGsNAw8G5UdK/ohwQDx7vOwvoXzMh/E0prrQWPgULVURUDjZDJ+Qu5jZM58oWEvYDEC6zoMWRxX3oek75sxucNbwK+HZwg7u1Pw== 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 Tue 03-09-24 19:53:41, Kent Overstreet wrote: [...] > However, if we agreed that GFP_NOFAIL meant "only fail if it is not > possible to satisfy this allocation" (and I have been arguing that that > is the only sane meaning) - then that could lead to a lot of error paths > getting simpler. > > Because there are a lot of places where there's essentially no good > reason to bubble up an -ENOMEM to userspace; if we're actually out of > memory the current allocation is just one out of many and not > particularly special, better to let the oom killer handle it... This is exactly GFP_KERNEL semantic for low order allocations or kvmalloc for that matter. They simply never fail unless couple of corner cases - e.g. the allocating task is an oom victim and all of the oom memory reserves have been consumed. This is where we call "not possible to allocate". > So the error paths would be more along the lines of "there's a bug, or > userspace has requested something crazy, just shut down gracefully". How do you expect that to be done? Who is going to go over all those GFP_NOFAIL users? And what kind of guide lines should they follow? It is clear that they believe they cannot handle the failure gracefully therefore they have requested GFP_NOFAIL. Many of them do not have return value to return. So really what do you expect proper GFP_NOFAIL users to do and what should happen to those that are requesting unsupported size or allocation mode? > While we're at it, the definition of what allocation size is "too big" > is something we'd want to look at. Right now it's hardcoded to INT_MAX > for non GFP_NOFAIL and (I believe) 2 pages for GFP_NOFAL, we might want > to consider doing something based on total memory in the machine and > have the same limit apply to both... Yes, we need to define some reasonable maximum supported sizes. For the page allocator this has been order > 1 and we considering we have a warning about those requests for years without a single report then we can assume we do not have such abusers. for kvmalloc to story is different. Current INT_MAX is just not any practical limit. Past experience says that anything based on the amount of memory just doesn't work (e.g. hash table sizes that used to that scaling and there are other examples). So we should be practical here and look at existing users and see what they really need and put a cap above that. -- Michal Hocko SUSE Labs