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 EB90FC3DA59 for ; Fri, 19 Jul 2024 08:40:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37E466B0089; Fri, 19 Jul 2024 04:40:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32E5F6B0092; Fri, 19 Jul 2024 04:40:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F6626B0093; Fri, 19 Jul 2024 04:40:23 -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 F418F6B0089 for ; Fri, 19 Jul 2024 04:40:22 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A4A3FA04B7 for ; Fri, 19 Jul 2024 08:40:22 +0000 (UTC) X-FDA: 82355855484.22.5EE8853 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf14.hostedemail.com (Postfix) with ESMTP id A076E100015 for ; Fri, 19 Jul 2024 08:40:20 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Vg45+poL; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.50 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=1721378365; 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=jF8gy/uU8luuF8gCy7lAQQWkUljiBlRrv2KQKNFYTvA=; b=7DEugan9FHcRaySjedUYw1If+aZB+buauJrrFyveooxd1UJJ+4V98ktT7lNGErSZb3MNuK ldCV9bTE5RbRL9vDJn2lD+IRkxzMOiubuVWZktHg8sw7OnxYm4KBGrOM1dFB2wtM+nCUK6 O5zNFLro9eF82aHvIjXzlF3FJYnfLkE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Vg45+poL; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.50 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=1721378365; a=rsa-sha256; cv=none; b=uGI4pjlGjEraM+PncFWqcHNh5/UPc4kp7jDwXU5NNmpoFxSxNo1Fw34GvACMcUHx1EUhIM OR4ud6CSygMTcqp/YGfpitvP14VeBMibCRduBSXO857tcywbCrzrFkQ0BSUy0BvKZEoSEH VyxA7v+WkuKAGFoPciGbOQnOtEsXp4o= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4272738eb9eso10207075e9.3 for ; Fri, 19 Jul 2024 01:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721378419; x=1721983219; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=jF8gy/uU8luuF8gCy7lAQQWkUljiBlRrv2KQKNFYTvA=; b=Vg45+poLF0Hv8ZsI1AQXFSELheJmi7nvNCR9HGdLXc/nbOvy4hrI9uG8x9ehutOc91 6Lx6xmGELWGhe3OjN3DjgpeCxdO1aprRJxO0Xx//XaGjWvf+OjtYdm3cFmmgZ9E+dO0h MdbVrRFfGw8+6t0HAwMlfzvlYreelREuuq7l5yg580/0MyTjoSDYX9dgzych9AMZpfvT eSkHBUHrKzIJiYnD8Tg4iJWxgYgcbPc+maT8icaz/CU/gzLKIvj4BKEoJFw5CO8FWme9 G+vPeyHt36qddY5h3QglBz65/d6mvgErLHBtBwVT9Y14jt+4qhkOyrKJwEj41qgwl4pK L4lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721378419; x=1721983219; h=in-reply-to:content-transfer-encoding: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=jF8gy/uU8luuF8gCy7lAQQWkUljiBlRrv2KQKNFYTvA=; b=S4KWotJQbysVfMTD2XUknZ4D5hiOzANOPLMCLezZww9lprmw+PIJJgnvCeLUfZ5XyK 7hW8NSOl50++NsbqUsg2HnaZvgoFdT9MVRXFHcQd/Dm1BlSYs7X6Jcv78VK8EywZLUHe Fn3V95GL8l3ObN9W2TuYxDx9GExTwFVchbmO4NHrMpsNYsmUM/lY2sWu8oD2/JzxGqhH 0O5wmw9lHzI2Gt2OrL0ZbPzAa9xQUQFb2JngbtTq3FsxX4WonqFx30u6AIueqWR265km gz4x2OeJgjReE5Bw/g8gWKEwJREYPNh27QViR8WFsngfRc79VDqa9Em595Ldb590j82e vp7g== X-Forwarded-Encrypted: i=1; AJvYcCUpcPySlYaUDfZihrkZcBgHxtczJmnPNbE/nqPm4Pc63zs1pj/eczsdyDR7FFDbLAcW64Hwo5+EE5/xyXjPP+/pKME= X-Gm-Message-State: AOJu0YzC87P/dGAKbDTWKOym0YbMAa7xp4I9ZbN8PGL9m7HMwrs3Wy3x yDAYFQl6ajIBz4vrOQ0E0l0D9KvKcacRPBuNB4R4vlekY8bxTXszbjvArr64r4o= X-Google-Smtp-Source: AGHT+IGjo1cgBe3ByYHc/OJ37mbVS7LFAe6dSKLhLzfqiey0Y4DkIFpiRKHPcofRc0nqcZZtzXcudQ== X-Received: by 2002:a05:600c:45d2:b0:426:5b51:109d with SMTP id 5b1f17b1804b1-427c2d100a0mr52387585e9.36.1721378409041; Fri, 19 Jul 2024 01:40:09 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3687868bc91sm980186f8f.45.2024.07.19.01.40.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jul 2024 01:40:08 -0700 (PDT) Date: Fri, 19 Jul 2024 10:40:07 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A076E100015 X-Stat-Signature: gu18yzqkh9grgki7t88m58a63f7t5myh X-Rspam-User: X-HE-Tag: 1721378420-575027 X-HE-Meta: U2FsdGVkX1+30VPn2TqMZXQwAJw0DZnKeusjsVifV2rQoXffQoW5xmcgzVX3rT3ZPEaiGaInOBwbr8EtLT51SgxuZV1iq2sPtcOjFSL+2+HLeENRjqDivXK7DVFYCGOU+9f5TBh2r+Y1uatcAjCylJrGySfcMVhdpV8KouAWAv+xJZdt3JbMVrMaw+jYsograq4kADibI8B1nOHZW1n+mIx03Xm80G62eY7zCpm/DxQPvM5RE6Kjx1Rm9pR44dR6pHcLSvCw0xbXCNasjP7TaAt3GeV2ROsfJY8ZJlUS0Gw5+3Wh740jdgGlyUI66eYXarQgKFdPMFigDP6noa4kM+evaPMI48IfUWTbdwT6mP4TghvmwQ8E+twUW308Nqxnv/ygWHAI/tn2ni07vJTkvk1ujv4ylrg9M3iqkBGjFX4D+R8b1chHSfNYYe2ispsmiBXy1TTF/rgtDQ/SuJUwmzxYX1VUltq3t69gfLbtjhfUhxqJi0HvZzv+JcGG4DIrPkcVBvxKmhjkWKA15e9+P3uXuEHaxCkuOCLlvQNF/2UQmpLwKl3U1VeXLrXR9cMosKBPbLvd8Si98xMNTA5KM+reZq1IqKhd6HFlFoZz0kJ71VJkiFeLzEHKwBjBUN7lJQJetROA6XrGMEOdWkN300V34d7xVmqNwqL0F4qGDeL+nQuoliGr0iNHu+dfc/uJhZJ+YYySkU7kF+VPrR2xfH4EoVZ1YHqHrQtgVqthjutEGtoOVPLu93WZGa5vpfv1FXmVk2WWjw4qLHRyEqbehzDgMQNrGN6SzVHbngHv5eal826r7sCf7cAn5FaKCnHLAl3ximGnf1rw+38F6gtdZthfTlFIMWHMiNDJiGAGgZGrI5Z47cdAU3HEyDqBO5pqqyhHTekHxg/BHkPrWsArovccQ7aXkfPoyappvc4AaWuSCO4CtqyeCydXeLHmZ/ZPBL5tpLYbYKwqRHaJ3G6 ifwv9jiS h9cwa9xQrounTYHjnHl25KxbvMZobJ5DiiLsjS9hXLUi9so0TV3Rz4+W5clBbXlwt2QuEAmQEItUV59YcLvSEuxn/0IqIUEmSkXLaEehxr51QJLEJ9inVIaY10nmHb8hVf0Yy245e7GXHhq6MX7E5Ncpg5/e3CoC4oupoI9JVnaEAQqcH87ScErgk26Ow57sc3NvpIx3Cypl8CWSl1xGpMfNQjiEl0HxFnn6n5vR9Gin9uVppN3Z3vfhXdg03PcGEpFt9o9OBTaiSvy1/gzlRcuey+Dlfcr/CvF7bWl1WTpLafz6gLxwikR90tINDazsF5xKHLKw3LqN6oe+kyQ4Wwnizq5+/ZTsBULqOH2f+0I8q5Qp01VG5d2cCXjWfP3PyVYxG0Z0XC2CwrsDi5vaBw+M2U+2jD8iWbq90q7EeT0+DJbxp01Q23H3DUnc+ywHfXiNj8FpXzAAvoueMiBK4wrx84xbpFSLaHtAUIxn53Ge6g4I= 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 Fri 19-07-24 20:28:41, Barry Song wrote: > On Fri, Jul 19, 2024 at 8:01 PM Michal Hocko wrote: > > > > On Fri 19-07-24 19:51:06, Barry Song wrote: > > > On Fri, Jul 19, 2024 at 7:42 PM Michal Hocko wrote: > > [...] > > > > It cannot reclaim itself and it cannot sleep to wait for the memory so > > > > NOFAIL semantic is simply impossible. We have put a warning in place to > > > > > > this is still "right" behaviour to retry infinitely at least according > > > to the doc of > > > __GFP_NOFAIL. > > > > I do not agree that implementing busy loop in the kernel is the right > > practice! > > > > > I assume getting new memory by many retries is still > > > possibly some other processes might be reclaiming or freeing memory > > > then providing free memory to this one being stuck. > > > > No, I strongly disagree we should even pretend this is a supported > > allocation strategy. NAK to any attempt to legalize it in some form. > > fare enough. > I am not trying to legitimize it, just explaining what the documentation says. > If it is illegal, we should clearly and firmly state that it is > illegal, rather than > pretending it is legal and returning NULL. This is also wrong. Patches to docuementation are always welcome of course. Please keep in mind that our internal interfaces (something that is not directly exported to the userspace) are not really defensive against users. We do expect some level of reasonable expectations from users. Think about it. GFP_NOWAIT| __GFP_NOFAIL or GDP_ATOMIC|__GFP_NOFAIL is simply impossible with a finite amount of memory. Isn't it? You are literally saying that the request _must not_ fail yet it shouldn't resp. cannot wait for any memory to reclaim if it is not ready for use! With our gfp flag interface we have quite some combinations of flags that we do not support. Do we want to document all of them? -- Michal Hocko SUSE Labs