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 0845CC3DA60 for ; Thu, 18 Jul 2024 08:33:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BE906B0095; Thu, 18 Jul 2024 04:33:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66E416B0096; Thu, 18 Jul 2024 04:33:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55D5F6B0098; Thu, 18 Jul 2024 04:33:55 -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 388306B0095 for ; Thu, 18 Jul 2024 04:33:55 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BA62FA19B1 for ; Thu, 18 Jul 2024 08:33:54 +0000 (UTC) X-FDA: 82352210388.26.60A4E3F Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf11.hostedemail.com (Postfix) with ESMTP id 091DA40017 for ; Thu, 18 Jul 2024 08:33:51 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TzDFZiq4; spf=pass (imf11.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721291611; 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=lv/IlUS1O45kfiFTYYumlX0quizHgELNem89BNCf84c=; b=C9W9QiI8BGndZ1raoZwOCi+L99xkWjplAQLdXeCEL7UOhKGcrVA84G2CAQSmsd1L5TXc3I xgbvghmohxdol7fJA61R/Y90D5WJnbkiwYC/l+OuLnfavp625uzCsFHQ6t5OXFBxJd0RiF 7eV8PU4CWX2PuGC6pBNa67yXoNgJmfc= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TzDFZiq4; spf=pass (imf11.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721291611; a=rsa-sha256; cv=none; b=oj4Lr4OupGpgCGdMPr64tvmhH/lGaNQyvDonTaomzGKVX3GAM04EHRz8cUMRTCxBeqROWr UIAbTVXPWdxuGDQJuyqmpPNELzKVjZnv3BGyN8FSGYaDgho8KQ8hLy5SLEu2Yfbh+iKLO3 MzwCHqr0WT8G7efhqYCoSTy7tXpDBOY= Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-81f01f88e8eso256310241.0 for ; Thu, 18 Jul 2024 01:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721291631; x=1721896431; 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=lv/IlUS1O45kfiFTYYumlX0quizHgELNem89BNCf84c=; b=TzDFZiq4Z12sZKLEVuLDnl07kpuWs37wAHkEqFGSL8DsG2JRa+XC8FZPACV9WBdLfI DnVcAfb13gJdlipHZCp/B4IbNHtLV8pZLNn6osAvtx3IH6Y0ekvOkUAWG0Rmstz0oTry mx/8UYuA7yPUy81tOs24GTWuzWBsfTuMEAEnoxdwMUTuZjvIGV4vQTjqLWeeHagp/OsH GQHSC2KS41w3X7os/D8nz8kXSHkQW3E2A4exDTlQRIR1I6Pm1NrtmYcfDWVtQrEfI1fC wuTC8nXnbVxjjPeCz5NLyc6Nov1Lf9499QS9pghT5pQ3MUz7W+yGbN9l/8qxWrOOPHzx bJQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721291631; x=1721896431; 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=lv/IlUS1O45kfiFTYYumlX0quizHgELNem89BNCf84c=; b=N6UVkxLRA23he9rWObrblEgVaygKQitxXpX1Bx0MtMTFa18VwqIoFs0MtpahAtBKyQ 4WaMjb1Rhpwz77O8BQDYKbpSLaBEMFct90/F+HOhkn0PIHDMPQKEFWGJDGM7B6DqGW9l lZ6raeZElb0iTrl9HTyopfXHc+XsWHMRok7OhmY1s6XW+P8wDv66uu0aMqLPDRitoz+F IepJZIhhb0ikQfEIz05K1tJW51fFryNPIIvIqdwzPYOYch7d5+y4luefLpe5iGQIxrKi 2B0J4NoC9lp+sOd35U6zcr7E2/kPcGp7bAnHwfcTeMwSqjviK4lw1eID7t9bNoXx2Emf JFzg== X-Forwarded-Encrypted: i=1; AJvYcCXKOIoLTQAJ+U1XzLf4ZjIOezc7AR9QVFhQQ3MxA/QL3AQ7aGL/09qQBr7lctB1Ntc5qyO/My6MMBSABwJlNX+ny9Q= X-Gm-Message-State: AOJu0YwPWW/21j6wbvRB30vHkH26zLZUmBrQXkk7WqkI8qqtySIQ01Dd 4pdSQiQ4BwSiro9H0pHpOh5raS9iR75G9p1uvtYq2rRRFzHCLjhTjqq3yDlbIYZpqLi+fStJuSM xil8jEVM+6W0h6GsBOOwxqVbGBIw= X-Google-Smtp-Source: AGHT+IEnopIUVofILe6ef7efmalYkbVSH1qdm7aEKbkaEa2/TyuvhLjBqIRIQGKQzcgGbiLwE9aqQ/45frk4KxLQaWs= X-Received: by 2002:a05:6102:8019:b0:48f:df2c:6d65 with SMTP id ada2fe7eead31-491598296b1mr5898573137.6.1721291630874; Thu, 18 Jul 2024 01:33:50 -0700 (PDT) MIME-Version: 1.0 References: <20240717230025.77361-1-21cnbao@gmail.com> <20240718074816.w7drfptbunkvpukd@oppo.com> In-Reply-To: <20240718074816.w7drfptbunkvpukd@oppo.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 18 Jul 2024 20:33:39 +1200 Message-ID: Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL To: Hailong Liu Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Michal Hocko , 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-Server: rspam11 X-Rspamd-Queue-Id: 091DA40017 X-Stat-Signature: pyfho1i56tph5n6991suioqqh4muu193 X-Rspam-User: X-HE-Tag: 1721291631-182187 X-HE-Meta: U2FsdGVkX1925VvYTjLVFt5UzCJIhRaBoOFnFtJ5WnIeGxD+3hRkLXUhH3lxcCRQe4gUSzOi5AGrAauyMRQMkak6uxnBzNxMJjxISPZBWIPIleQx4yrxtuSUQm3oA4EBMimE4xO2GHOx0cv5e21FltBB3BrwEVuSS8umHUM67CkMuRGC8/HeR7y0h0BR7NNyYw6nEIM6QxkiAOxnix6Obw5E6DKf+0OFA2HfGfAZ/Ts+DATQGXh1sjrgCtJn+5OIH/ljKBqDxCaJL/E6W1/trTsrLmvM7rKf6LuIagkutv/SExsHSKhhKJh1tjZlIFge3fDkHZJUaNprHKgI2Z3pRo2NsNlX6tkvpUt3PRHVrVQNpshtYPz81/p7aXgLHyxxadpfDrnyfb9qGrGGVa4nOsF9hJ9n/JFP0RVvCi1mRfK7F533LNELXD5eMiSs+Bx8YRr4p1BKbxCn/K0xMRdYD9B0mliYd8U2dvMRU4gqgMX9qtm14FDGuxs8bcVHnbtH6rAsP5/Szma/qAmEkQFttYCbH7ejU5eBXCRr3ApjOSxHiM0yCg7ShkKY8rpeY52sjemPGhmyQGfL2ltkvq8rjS4zS9RzuD6JSctUlh06J8L1T8d7VCIvciL9pfI7stDRo4rVk55hBUVxh/rTDQgoohjgTUPscJ8xtl0ywOBHyX6cDh4jxnl18QWfy1dH9A9HGWLvkeQ3sdOzW4czxkfOIUW1FvFjNkurF9NoTEwQl8plKlGlshIjGEGCUdVjEdkvTBhTEAhb7Ztjw2BHsF6mC2lDgoAbMLmxU/shANHEhMIhJ5c+EwyF2dU0816RmHk8Xm9FY4CdDx/O7hDsXrzuYu7r6ov7lj9dsmL8vvYHH2phTWbi0bzQyh3cUkIB9PgAlBTiyFm2SENOz4UbFZXnbEoItBmaZjhxD20rVQo247X6OloDnO+Nf86zGyqhNxoyKVvliGY2PDmczOH8V1m F959b1Y0 2fzD/nq6BrDPRa+RjiLScWsPhAHs+ng2sDLEb0Jzgj7IrhHm2kTxcOixeHP8/VowTBBQ8lsptzqkRol1RIZxAWazBH0LNC64NzRYjjy48a+dqJXW9xabqhqpapAKon8AbJSoK/luLNi0furuFgVm4IFLHVJ/Wfr/o27K4L3AOe3X3yLDTdsNg9UZ9mHTkNfSbXPXph4zwu0OFW4eO2Lwy8GaHsi2eILHh1RKdCHIVUeyd2UOOkyBU8k+JutQ9LSQE5mpDGMRf3tg8qjQ/oTnmWG8njIqXhpoRjTSNPHzq9hf4PEqEZK1rY676H4MI+M1ViOy2KusPIsPRwZDAsOM1OyAjNRODngdt/EbsmG9Od7kxxVokt2lNlrmXQi5ka/UjH66goOLDggGxmxdxPKk63UZj9F+IDX7bIATewF+8BAsSLAL+8vHIMfN1PXfzYyU2DvhuhdKxq65hmQqJ7T8zMPntEDUvow9XVnm1EtpVIQWjfPYHqI5G1I971Ke4eVCLxLo9TvJfqOlJ9PKThwQ3YrQrW7vLHZ+M+EmNYbxvWvIQQ6r43JP6FDNIBO36PgmncvmJdbB8twNu1z35aH6+oZT2qgRyNkW/WRYLYBUuO8AiVdOqHrVy6Wu6bnvlIyw1YwEDn6pvmTSQUd3fT/Lg+02QzWlKOkOWFCWgY4AEkuiN9tW+KVK3w5NLq6Mx1h2uY6mDb4fV3nw1TD8xn3m94y8TcvCQpNO0nUxoWr5FrYxscsWwfZRpD/ef17/cyc4wztlI8z843Hba/gRqW1Az3uYhaDukoezxzOuKzahZOnJ36CFgudoYXU/Bwg== 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, Jul 18, 2024 at 7:48=E2=80=AFPM Hailong Liu = wrote: > > On Thu, 18. Jul 11:00, Barry Song wrote: > > From: Barry Song > > > > Overflow in this context is highly unlikely. However, allocations using > > GFP_NOFAIL are guaranteed to succeed, so checking the return value is > > unnecessary. One option to fix this is allowing memory allocation with > > an overflowed size, but it seems pointless. Let's at least issue a > > warning. Likely BUG_ON() seems better as anyway we can't fix it? > > > > Cc: Michal Hocko > > Cc: Uladzislau Rezki (Sony) > > Cc: Christoph Hellwig > > Cc: Lorenzo Stoakes > > Cc: Christoph Lameter > > Cc: Pekka Enberg > > Cc: David Rientjes > > Cc: Joonsoo Kim > > Cc: Vlastimil Babka > > Cc: Roman Gushchin > > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > Signed-off-by: Barry Song > > --- > > include/linux/slab.h | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/slab.h b/include/linux/slab.h > > index a332dd2fa6cd..c6aec311864f 100644 > > --- a/include/linux/slab.h > > +++ b/include/linux/slab.h > > @@ -692,8 +692,10 @@ static inline __alloc_size(1, 2) void *kmalloc_arr= ay_noprof(size_t n, size_t siz > > { > > size_t bytes; > > > > - if (unlikely(check_mul_overflow(n, size, &bytes))) > > + if (unlikely(check_mul_overflow(n, size, &bytes))) { > > + WARN_ON(flags & __GFP_NOFAIL); > Hi Barry: > > IMO, using __GFP_NOFAIL guarantees success if and only if the parameters = are *correct*. > Maybe we can add here to help callers to find the reason as in mm/page_al= loc.c no, this doesn't make any sense: * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller * cannot handle allocation failures. The allocation could block * indefinitely but will never return with failure. Testing for * failure is pointless. I believe these are two separate things at different layers. > > ``` > if (gfp_mask & __GFP_NOFAIL) { > /* > * All existing users of the __GFP_NOFAIL are blockable, = so warn > * of any new users that actually require GFP_NOWAIT > */ > if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > goto fail; If the code calling this function doesn't have a retry mechanism, it is a BUG that needs to be fixed. even though the above code might return NULL, its wrapper will still retry, for example: while (nr_allocated < nr_pages) { if (!nofail && fatal_signal_pending(current)) break; if (nid =3D=3D NUMA_NO_NODE) page =3D alloc_pages_noprof(alloc_gfp, order); else page =3D alloc_pages_node_noprof(nid, alloc_gfp, or= der); if (unlikely(!page)) { if (!nofail) break; /* fall back to the zero order allocations */ alloc_gfp |=3D __GFP_NOFAIL; order =3D 0; continue; } /* * Higher order allocations must be able to be treated as * indepdenent small pages by callers (as they can with * small-page vmallocs). Some drivers do their own refcount= ing * on vmalloc_to_page() pages, some use page->mapping, * page->lru, etc. */ if (order) split_page(page, order); /* * Careful, we allocate and map page-order pages, but * tracking is done per PAGE_SIZE page so as to keep the * vm_struct APIs independent of the physical/mapped size. */ for (i =3D 0; i < (1U << order); i++) pages[nr_allocated + i] =3D page + i; cond_resched(); nr_allocated +=3D 1U << order; } > > /* > * PF_MEMALLOC request from this context is rather bizarr= e > * because we cannot reclaim anything and only can loop w= aiting > * for somebody to do a work for us > */ > WARN_ON_ONCE_GFP(current->flags & PF_MEMALLOC, gfp_mask); > > /* > * non failing costly orders are a hard requirement which= we > * are not prepared for much so let's warn about these us= ers > * so that we can identify them and convert them to somet= hing > * else. > */ > WARN_ON_ONCE_GFP(costly_order, gfp_mask); > ``` > > > return NULL; > > + } > > if (__builtin_constant_p(n) && __builtin_constant_p(size)) > > return kmalloc_noprof(bytes, flags); > > return kmalloc_noprof(bytes, flags); > > @@ -794,8 +796,10 @@ kvmalloc_array_node_noprof(size_t n, size_t size, = gfp_t flags, int node) > > { > > size_t bytes; > > > > - if (unlikely(check_mul_overflow(n, size, &bytes))) > > + if (unlikely(check_mul_overflow(n, size, &bytes))) { > > + WARN_ON(flags & __GFP_NOFAIL); > > return NULL; > > + } > > > > return kvmalloc_node_noprof(bytes, flags, node); > > } > > -- > > 2.34.1 > > > > > > -- > help you, help me, > Hailong. Thanks Barry