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 1BD27C3DA59 for ; Fri, 19 Jul 2024 09:36:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 756456B008C; Fri, 19 Jul 2024 05:36:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 706DD6B0092; Fri, 19 Jul 2024 05:36:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CE2F6B0095; Fri, 19 Jul 2024 05:36:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3B9886B008C for ; Fri, 19 Jul 2024 05:36:53 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B85A41C1048 for ; Fri, 19 Jul 2024 09:36:52 +0000 (UTC) X-FDA: 82355997864.16.AE5C2D9 Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by imf18.hostedemail.com (Postfix) with ESMTP id EB4E41C0025 for ; Fri, 19 Jul 2024 09:36:50 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WmvBWRHb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721381779; a=rsa-sha256; cv=none; b=8CciRAajiS9nWABIEdNJUSeWeRshMDMQjwXgAs35N8DaA5Jrf0faX7ecHlAXeNQR+jsjGf qVoIRVfx9g/vTHe7Kv2vlS+Jytq/Vx+0q8siQy8/8+tVF73X6LyF2FU36f6iag/2OSinYB e2lJyBCf31Hac0l2DX5maKku0HeTEAQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WmvBWRHb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721381779; 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=F7Y3FLhvIS+lRShMR0QfW8YWxFa0xWcNA87gXkpa2iY=; b=cFcT/xN6XQKc61i+kCiQBWpZMkTVtgFsoHZYLdYCHNPQ8WB90wVNijIf6lMXzGk/eJSHhD iky8HGOOIgkI4XG77bVrTBLGC5/TPcQjMNrpJ6l2iSNDad/jFkpQ3xhT8wTILfsxMBI5mA +4DWDKaBb4LXFbjiFS3XmkIhCVQoeMU= Received: by mail-vs1-f45.google.com with SMTP id ada2fe7eead31-48ff70394fbso613849137.3 for ; Fri, 19 Jul 2024 02:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721381810; x=1721986610; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F7Y3FLhvIS+lRShMR0QfW8YWxFa0xWcNA87gXkpa2iY=; b=WmvBWRHbXKGXpBvADEwB7nGk7bAWPcwe6jAZc/SwVMhM3MCQwoXDIl1Vh5YIvfTl0s oqqwklQZLIEk7+HN7j3S/ffk+1Zat8DPbg/CB8YXiuMoC6F8/OaPaKUHRNjRN9mNr0xv 090waw4yCaG8bwuAZrplHu9TGJ8wTJH8jNS0Jo0o157rNMX/xFr1fAapPCe5MXttxFxj 6MMnePuEUyKM1UVfCMsebjzfXlOpXe4IZHHMjk38XBCmdOhKD7xO8G5lFMMaWCRkqVjK cLx51ykDGR4wo7auPP1yL/La4T1/yEJI+4CKM1BOhDQx+AVRaR8tI2Iv61YWnXx/EEie J/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721381810; x=1721986610; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F7Y3FLhvIS+lRShMR0QfW8YWxFa0xWcNA87gXkpa2iY=; b=KAFCJAHK3bikK5X9HiTD7E++6qCZH8+k2SyX9FgjPeeKUGSUCW/RrkUyZxNGYSoMWw AscMmuvZRWpKMZLBM/2NXy/byZ1U29JZPwZuh0s4KhiJtR87P9FZJFIUv2CztvtyYChN PxM3uuXGJBMr4OfrkJ1l1t5Q/RjF2i5EVbmOpHyYZprrq5Z7f+yo/3peh/51A4pBT3ls YdXh7jr9n0aP+GJE6xackEMcwWoZ8FELrYAYRqFxW8fm2OqqbWFJaMcwv3y30KKG1613 URfU+ufS5a1fi1iosWBa5kTbIuesRRjMallyjBuFRRXKW+qz+L8IWWMcz8jOyP3GDX0Y O4jg== X-Forwarded-Encrypted: i=1; AJvYcCXRWoUNraiRMy9sEqjoi/c0Wyvz95SpDfme1FP8Wa/VhiuliyJHub3JN6rt4ItogOvf17MtAGK8QtgztGp3rAMxg1A= X-Gm-Message-State: AOJu0YygW8j028aIWcMSB+kBof0JuLBn8bGZUzp0nzyhVFCG56U0NxdO aFJNc0d8agCB5Q/JxsNGDVaoqZGb3yoOJ1zVRm0PH8rmw6mcsI/7wUJSdKsZLsw3+bTeXPVulSr s3eVW58owTCaemtjAEQLypwQhCFA= X-Google-Smtp-Source: AGHT+IFALWEton6zb77V3F9x/ufnCDildQLNmXWA8q6HVBXAnV2Z8mbaNSIUTCEqAxRAP9jUJ7cN2XwAOckKCaz2HO8= X-Received: by 2002:a67:e716:0:b0:492:7675:a394 with SMTP id ada2fe7eead31-4927675a9demr2324453137.2.1721381809818; Fri, 19 Jul 2024 02:36:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 19 Jul 2024 21:36:38 +1200 Message-ID: Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL To: Michal Hocko 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EB4E41C0025 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 4yfqayqu689pg5c7a4e97zbfqkdy7pxu X-HE-Tag: 1721381810-503341 X-HE-Meta: U2FsdGVkX19OP3q7KVWPMv7AIvmN5i+lCJkE2glhjUu01lJUkIXIa1O133rZBjyVV9OZqnfLLkNoa0JYiuUHz4ylfWWn5H5VW5+ZmB4IKwWvuTRnswXPFdRKMCTMMrzP9Zn3gwLxxzEEzN/0WavPVspf9sl5SF0w8Y/gRXFyjAuB+fjBjUa6Ud2DP9aASb03syhjgVN+ZQPpaglIafKMbIxntX51ZocPr1jiPkh9+9PgBWTLw3fSxETmnl6P3+zqX2ANniotYgCpooqYgvoeVU9TrtQ/YZ0RVAXNFMAE9IYW1gfCuL637agL8XJ/Ukx+HOFERh2i6oMiFrC5hdvLOLtI/cnesE7yHmNVIJuRBssFA1W0mYnGn2JCu/LTllKTIDxiHcHjiNYrNlohV1/ENJ3uQXNsPJQoyGUQ45eZiPpFbaoYmcyyuThJ9WcalY5a0Vu168MttgKytM2czcAWYpViw9+Uo04LFP6ExVKDWCQuRqZOa3eCK16v5tHoe71nBQPkVBrIzo4H7WXUmRnZJ08JhzMg954PLLtGe0yVQ79X1ZE5iuDECALVg2iJEPfLgZx//hsBhPQsVyLiXCCqXOLW0JJGNs33/ujZy7V2Kc7BFhf0E5b0efC58DYU69/rTLQ7SkC6Uz/EcLKs+bWoSBxxn+4W/vAYLKyRCifohL5rjFrvcG0UWQuTGy5kDOpLStA/2wdxNS6hSXxA6DRpUY5423po37VVLt4HXhIHROFO7CxEvF/tNCSYxScrjm9p4nPkdTobQai9Mc4N6FzoFE+r1EUs6maZi+i7h6wDaeWlRmnTfHf0nSxwEt+vPhFf4anysJGQjJ1xxxAx/xPSdIA3xJQGJwSgSsvy9FTzG9kuwCDSEKfYChgow0sEHuSgpJHnzcQEe4TTt28wlUi/Wuu6UEwBqND9++3dnpCnvO5Jt3vUfVzdhEjDmEQUg/RIkPaTueRnIUzKaaMkWv/ FQ34aRUk jMkXVWyatiTYYPuoImTbvGT9Yiq6fWNzTg6qPlHkiae9AB+WJ1pzk2McjWeZzAYlHvdu6t7+44BNNFBtW2s4oV7IdTgkMWB4LXGjZ3+pMNnIkgKqTpZBD67AHHU3D2jda46IjQ44adBDrj32tWrJcY3obiyTz0Lkoy0+/frJMilw58a0gHoWWNDPmfjAWi+HNYyVxonreHxm6P4GSL/N15NKZ+KSbxJhJ3KRBwwkpY06hb9eNRv7TIRJpIWCrkPG09Gf7NEsenB/+enPpM4K2nIfSxPk54KNNSSKbbqtoZXryfi/bmT2lzzDyaROzpUJ05dKAIAzu7Vt0Mm4VEbUmHCZJ+AbYvVN5h0YN5ZBjKA6ok5FHZ/sWCrzIDshTvdmYmzI0A5zJjLUkeTShwhjOfudEb7sB7aWDy2saV7nXYq9aLFGyU07v2g77yrP5NVPLoMSM4YtmtZO3sGms8A8V7qNZMHrjOruLwhf9 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, Jul 19, 2024 at 8:40=E2=80=AFPM Michal Hocko wrot= e: > > On Fri 19-07-24 20:28:41, Barry Song wrote: > > On Fri, Jul 19, 2024 at 8:01=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Fri 19-07-24 19:51:06, Barry Song wrote: > > > > On Fri, Jul 19, 2024 at 7:42=E2=80=AFPM Michal Hocko wrote: > > > [...] > > > > > It cannot reclaim itself and it cannot sleep to wait for the memo= ry so > > > > > NOFAIL semantic is simply impossible. We have put a warning in pl= ace to > > > > > > > > this is still "right" behaviour to retry infinitely at least accord= ing > > > > 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 documentatio= n 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? I don't see why not, at least for GFP_NOFAIL, because its current documentation strongly states that it will loop infinitely even if it can't get memory. It never mentions the potential for a NULL return. Not everyone is an MM expert, especially considering we have hundreds of driver developers who are simply calling APIs. We shouldn't rely on specialized MM knowledge to implement a driver. And I believe that even most MM experts have no idea when GFP_NOFAIL will fail. This is so bad to keep it as is. > -- > Michal Hocko > SUSE Labs Thanks Barry