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 27DD1C5321E for ; Mon, 26 Aug 2024 12:10:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF5B56B04A3; Mon, 26 Aug 2024 08:10:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA5486B04E0; Mon, 26 Aug 2024 08:10:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 946326B04E1; Mon, 26 Aug 2024 08:10:53 -0400 (EDT) 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 769506B04A3 for ; Mon, 26 Aug 2024 08:10:53 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1B65541084 for ; Mon, 26 Aug 2024 12:10:53 +0000 (UTC) X-FDA: 82494280386.10.E6B583B Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf14.hostedemail.com (Postfix) with ESMTP id 9746E10000D for ; Mon, 26 Aug 2024 12:10:50 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=nBaNdRWM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=E2DmYrpI; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=nBaNdRWM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=E2DmYrpI; dmarc=none; spf=pass (imf14.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724674181; a=rsa-sha256; cv=none; b=nNHrek/MVYUFtKU/K5LtAEI9PmdG9nWqF+YGW8zcCYjGpNqUPZElXhFZoqWBOSyrf+jmJ9 shOaPEDcnkbdtqBNS82NY70B8A3VL27lHHo5zinBlrubmRkXxQWvNT813r4tnPpzzBEHy4 u4y4cE+ibrlz8fAWU7jB2LhAgroQyl4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=nBaNdRWM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=E2DmYrpI; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=nBaNdRWM; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=E2DmYrpI; dmarc=none; spf=pass (imf14.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724674181; 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=ZCtIjjrAmITyqwuCw1IT7gRKA2nB6TNPwhjXE7+PFBI=; b=RPpxQjv3OGMHXRO5YjSzd2xfx0Ineg3T0M0srxKbfcgkwEtYLYYLv2KfUCs25yH4ZHwJ6s oQtrIaszZI1T1f3vZVZ+2j1ahy6L7/5457cOPPDWgqVIfFQNE+G7RaucBiIy4b5KpS2Yjw Z3NPe7jCX6fudmUXxlcqS9d8k/g8oVk= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B10F21F855; Mon, 26 Aug 2024 12:10:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1724674248; h=from:from:reply-to: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:autocrypt:autocrypt; bh=ZCtIjjrAmITyqwuCw1IT7gRKA2nB6TNPwhjXE7+PFBI=; b=nBaNdRWM3771YAcHzERz9XUa/b0ssoI2rsKs9kj0w++xbn3KeQBmiOr85SrXMDmh28TUYq 2o3/7kqDdeU3ga7W008u89R40rcvCMptwYHlZOHYKWmm4UhI5sWGBKJA5gWl2QnN5XlfOx /SUQ/g8xSKtyUh2bSvRgy6Uyy3xuTw8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1724674248; h=from:from:reply-to: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:autocrypt:autocrypt; bh=ZCtIjjrAmITyqwuCw1IT7gRKA2nB6TNPwhjXE7+PFBI=; b=E2DmYrpIDSUER4bhx9vK+KdQGQZtSIjMrbZuPL1Uumd3D1ZLQPKOFLIxofgWZVCbuyYQYy COPMhPF+QOJBGGBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1724674248; h=from:from:reply-to: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:autocrypt:autocrypt; bh=ZCtIjjrAmITyqwuCw1IT7gRKA2nB6TNPwhjXE7+PFBI=; b=nBaNdRWM3771YAcHzERz9XUa/b0ssoI2rsKs9kj0w++xbn3KeQBmiOr85SrXMDmh28TUYq 2o3/7kqDdeU3ga7W008u89R40rcvCMptwYHlZOHYKWmm4UhI5sWGBKJA5gWl2QnN5XlfOx /SUQ/g8xSKtyUh2bSvRgy6Uyy3xuTw8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1724674248; h=from:from:reply-to: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:autocrypt:autocrypt; bh=ZCtIjjrAmITyqwuCw1IT7gRKA2nB6TNPwhjXE7+PFBI=; b=E2DmYrpIDSUER4bhx9vK+KdQGQZtSIjMrbZuPL1Uumd3D1ZLQPKOFLIxofgWZVCbuyYQYy COPMhPF+QOJBGGBQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8D0EF1398D; Mon, 26 Aug 2024 12:10:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 26K5IchwzGbLJQAAD6G6ig (envelope-from ); Mon, 26 Aug 2024 12:10:48 +0000 Message-ID: Date: Mon, 26 Aug 2024 14:10:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Linus Torvalds , David Hildenbrand Cc: Michal Hocko , Barry Song <21cnbao@gmail.com>, Yafang Shao , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev References: <59e90825-4efa-4384-8286-06c0235304dc@redhat.com> Content-Language: en-US From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9746E10000D X-Stat-Signature: 6chya3odnp1mri7dfe91eb3nxeug95ga X-Rspam-User: X-HE-Tag: 1724674250-615654 X-HE-Meta: U2FsdGVkX193Zp6pMNQS9v9yowoThmrC1At0K4ITL2xc+badIbpuPwpkRQE2l+Hx7HJD2yVFPlAr/N4mMpvC1pdVP0KJ0CNmmuv9PUKDGaOPZjPgv1TUBI0XkXYKiKY5xvPsj4wZaEZQqqAlT4ET4CA+0byzSpSkDP72VJdq5TXzqV/ct4tUmpXK/7opmVN96rVpFcUVHvlrDazgEUQgwf03JsYKwmIrQnMpeHqHP0JFdHwh59YXJQ3qEguYxmPYkhRZuw3jtUew2INOe/BuBWnHtb/YQklx9b2m/ohwrP5fHXQyzVdPezpD/exGs5zt/44L9Ys8gAqQUwtncpcD1nPDdZNRTE4gfcqonFOHT+COlI51bEfWxAFV9J1Akp3iFG5Y412+MGH7BOAKPUfavvxsFeRrl74SL9U1V7kHyXcZauYOQ9P0tB2al0KQLAPg1iRH/c3ORlYGjS4Rw/5d1qQHcizBDOUmsPqU5Z5ox71zsBNt3L6R2FMcfKjR+vvp5iGkREA+NE72DAGMVTeKrvqtTfCCOTb/OL3lX3ngqCOFVCsmjHAzG2EGmuSzlAn6pGEQB9h89Yi6w7WN1TIWKnDbwWRIfHEbk7pXPNNTdiFpznKEq45Z6lCRoGGJg0uvn6M9HdL/EJZ+Du9MMLUgcndMCKAUy980w4jVHgzYveRb0YV7y/04eVEzZzE7gUMhBdHgE+KHdIHyqlDpI0LcoBbPnCyZoG8rJ3ADOIDoSy8m0m5tOPPVB3jhLqkU2mowvYBdl2MNLqFFnyLd/YfZyT4Ny/glxBUl9oDJKY0Zp3gLqWutxrMRqpOKQ8/xPNd11lrtfgLditI14w+fEYS4dbiz2GaHxd3CqSZW6txCWdtMH3fev1xl2vaUaKlBC1vb42l/rXjzkCVqDRD3y9baBbIjAr2PonakgM6G+Vinrfes33lDISx8PW/QCSqr6D0N7k9c8zMIZ8z+pvyH+Mw 6n4pZ8zV kLMA7ntrzAFT6Ez1l88/dC2S9nNbbMfSEWrkaJrDw+3zKdgsT854Yz27kS3b0aC+8QqsGyiX6WBTXrn5cwr1hiN8KqKy6LTceMhQ4t5WSgKt1u+E0qmMjT9yV/DltotW+gsU24XEPTUO55ZaTu002iOJQ+qwwYiK+yqDicW0q5E5h/8QZPMsYlJcGy6GmG3NnHyk/HtSOU8jXg7HUu6NL/e+xnmTvd8coJSLic7vwLrcBLrOp5ip9HJmyYUr398NqxpfWIsgdk55w6NWq/W8I1Tvoxm6U6YOMtt42oHDVngLvwihhRfAQisFHbMkkrsWRkT3NU5azJeB/aD255PLuSMZTSedQQvTC8XTUoX16dK3lEgY= 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 8/22/24 11:34, Linus Torvalds wrote: > On Thu, 22 Aug 2024 at 17:27, David Hildenbrand wrote: >> >> To me, that implies that if you pass in MAX_ORDER+1 the VM will "retry >> infinitely". if that implies just OOPSing or actually be in a busy loop, >> I don't care. It could effectively happen with MAX_ORDER as well, as >> stated. But certainly not BUG_ON. > > No BUG_ON(), but also no endless loop. > > Just return NULL for bogus users. Really. Give a WARN_ON_ONCE() to > make it easy to find offenders, and then let them deal with it. Right now we give the WARN_ON_ONCE() (for !can_direct_reclaim) only when we're about to actually return NULL, so the memory has to be depleted already. To make it easier to find the offenders much more reliably, we should consider doing it sooner, but also not add unnecessary overhead to allocator fastpaths just because of the potentially buggy users. So either always in __alloc_pages_slowpath(), which should be often enough (unless the system never needs to wake up kswapd to reclaim) but with negligible enough overhead, or on every allocation but only with e.g. CONFIG_DEBUG_VM? > Don't take it upon yourself to say "we have to deal with any amount of > stupidity". > > The MM layer is not some slave to users. The MM layer is one of the > most core pieces of code in the kernel, and as such the MM layer is > damn well in charge. > > Nobody has the right to say "I will not deal with allocation > failures". The MM should not bend over backwards over something like > that. > > Seriously. Get a spine already, people. Tell random drivers that claim > that they cannot deal with errors to just f-ck off. > > And you don't do it by looping forever, and you don't do it by killing > the kernel. You do it by ignoring their bullying tactics. > > Then you document the *LIMITED* cases where you actually will try forever. > > This discussion has gone on for too damn long. > > Linus