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 3D5CFEB64DC for ; Mon, 17 Jul 2023 13:53:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD9FE6B0072; Mon, 17 Jul 2023 09:53:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C88BE8D0002; Mon, 17 Jul 2023 09:53:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B50F18D0001; Mon, 17 Jul 2023 09:53:48 -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 A67DC6B0072 for ; Mon, 17 Jul 2023 09:53:48 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4EE3D40372 for ; Mon, 17 Jul 2023 13:53:48 +0000 (UTC) X-FDA: 81021246936.17.C45DF9A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id E49C2A001B for ; Mon, 17 Jul 2023 13:53:45 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=j6+qAp97; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=hLy0WTYy; dmarc=none; spf=pass (imf25.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 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=1689602026; 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=NGhBJDzK/BM5omhjtk3XcApjj6iCqwWj80Nq511FRfU=; b=fw+nf94+9bL1aQEUSG9yQLRjCRqFCFrvmmUQe4pk/F8lBglO+7hWf2vUP5cIoe3BCxjIv7 Fj+37Gi8LdETD6+bcNGa/vXayuN3ZVrcF129l7+iZ4hOm+b3zULUQT64426E/+cy08eB6Z YYj1UumgUW4RWr14BUWHuMpaEg3NQzM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=j6+qAp97; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=hLy0WTYy; dmarc=none; spf=pass (imf25.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689602026; a=rsa-sha256; cv=none; b=Op2GB+I4lVVwV81td9RlZGtlQqsXYjYy9HDAzIo/Ad/9deP2jCMa6i55dvI/y6XaAkU/WB i3eMpBjj4IESYbWyatbLSYVD+smPXGKnF1FnzlmJUrsESMsLS4ZknKvN2q7oXrv02pXah6 MsCBXAwv+nEnwWIA3uh0xgAGFNJd1Dc= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2D363218F8; Mon, 17 Jul 2023 13:53:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1689602024; 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; bh=NGhBJDzK/BM5omhjtk3XcApjj6iCqwWj80Nq511FRfU=; b=j6+qAp97kIaAGQsttxpdrwu3ZJ39DYBPXdkxVXGAbJvQxZlDIvouAicJ0RXcm3EF+W6uXi eCSn+RLmYx06Xc50yJSMbreOfzcXN3VM8ZI0gTlnIFrfGMiX7Vf3IKpImVUO4af6jiLcux A+8LO4/0x2RcIy0/JeEeDnkv/3J6KfM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1689602024; 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; bh=NGhBJDzK/BM5omhjtk3XcApjj6iCqwWj80Nq511FRfU=; b=hLy0WTYyo0GTK85US7wgooIs0L1s1HNxXLN6pkogTg9FgDNeGZdTjwi3lQOqBfmlEcWakj Ui+IIMCp0Rf4tFDw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9DA17138F8; Mon, 17 Jul 2023 13:53:43 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id pM++JOdHtWQ+WwAAMHmgww (envelope-from ); Mon, 17 Jul 2023 13:53:43 +0000 Message-ID: Date: Mon, 17 Jul 2023 15:53:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Fwd: mm/page_alloc.c:4453 with cfg80211_wiphy_work [cfg80211] Content-Language: en-US To: Matthew Wilcox , Bagas Sanjaya Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Rudi Heitbaum , Johannes Berg , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , "Kirill A. Shutemov" , Michael Ellerman , Andrew Morton , Linux Kernel Mailing List , Linux Regressions , Linux Memory Management List , Linux Networking , Linux Wireless References: <51e53417-cfad-542c-54ee-0fb9e26c4a38@gmail.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E49C2A001B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: sfwwcbxphmywhr4ch9xjp56hrikickb5 X-HE-Tag: 1689602025-114531 X-HE-Meta: U2FsdGVkX1+UQKwlNAZw79DIWaCOdDXWZe7L7vHqlaXsNKJqEMkbwB7mJ+71GJ/tjPUg3Dcb9I+FAMZB1GR0K2z8u9rlFHmkQeqn5JmQ0BHDInlbGiID9ivtDcgInh+iARMcQVELh38T0r1KcPtvkkNtoCZM4QAAUMKSh59tqVt2ifSyKOudeCcpzgPVyEUMNFriolBIwGMOy5+u77Yy2k0trwd+ItNTWRT5OcTbcN5hjGa2m1QqGgV83QLH82Diin7Ko1GNWps4It80Ec/ooxnwS1k3GLA+d8vuUH00PoqKtAeDEVm0wDON7W9FbKGa8u20VWegzWC2GVfqeb2LZ3GW2ba2eD2q1l7YrO6S6ZO/75zmRecTTp5uviiVi/aJmeAEBED8HoFtHIxBUZHAK3MtD3s2+Qe0f8Tdd+gxoHQqZsByDr6RkhzThmQJ1cp8i9piq4Qqc0tqH1oXttiOSa3nPldojOjPA6CBI9WJ0XUR5TYBTKpMpPreo/pInwjG+mFrm8FsuPgMq7kGQ+0AGAIq0KuGSbLt5yZ/xtEY5IVjIvsGLbJOlhak6uwIrIvxCytLezCbMKSOrC8gIZy2T3HjGPGf8ytmP0g1cAkkq1qxqYV+Utm7XQmbzWQs51rJpyAY1Xj2+02rjMAC7C4SHiCwlejfvf67edsQFAOuFnkG43JHoO6xVUDJRF8h/as7eap1Jc1uazcpA/mHaJm4/DotMN5wMnXsZAYXYkp+4w78IziH8a6b1tkGk7GXqSXit9+LdnmtzHou88IAMewv9HeazpYfw3TnBECKuHnCg8km1qPZUxQcRrRgN4ZHI0aCw8KUhPXCFA16Web/zGUVOOs1lX5B9cGjOm9SPIzXyMhTkykN58r6ayACJTMF+OiP+8eL0VGsP8JN1PI5bQTxFxYrJdUIiB9HD0/4xAHrZVjSbiafHj2952IcqBo/dhNblvxucyQaoBIGyCuck+T tnVTY+ql g7VWwo+xz9Qqh8kOM9gDpo+k3ZsmyoLEouS6zOFcbaeesjx4xz17MHpIar2/OcTWFdvB/J4MKsb7NKKMCp+pKen/wiCe0Wnc39wyvY4826tQ2B3gXQqveVQkt/3z9iuqZKJM8hhSkUBg3YvG1EXaPgn+IcpOhHSkD22u8KJGU0ZVlzYXnPH+5XDxnO7Lrbi4Oqo/VhKaea0/AsVoJS4WA6UxaF7Uc83aKfRsFwtreYPCXTQwf8ontq4yn3rPmjvb/Zz87HB+lZLr/WY8CcDjPiX6MxJ66rAmaNrkafpa1ZHwqlzl5sMU6P51vcPUTxVYiubDP 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: On 7/16/23 13:28, Matthew Wilcox wrote: > On Sun, Jul 16, 2023 at 06:10:44PM +0700, Bagas Sanjaya wrote: >> Hi, >> >> I notice a regression report on Bugzilla [1]. Quoting from it: > > Maybe you could try doing some work on this bug before just spamming > people with it? > > if (WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp)) > return NULL; > > This is the page allocator telling the caller that they've asked for an > unreasonably large allocation. > > Now, this bug is actually interesting to the MM because the caller > called kmalloc() with a ridiculous size. Arguable kmalloc should > protect callers from themselves (alloc_pages() is more low level > and can presume its users know what they're doing). > > Vlastimil, what do you think? Something like ... Hmm should be more robust to check size > KMALLOC_MAX_SIZE before even doing get_order(size). Ultimately it checks the same limit. But I'm unsure about just returning NULL. I think warn_on_once might be useful even there - in case a bug is introduced/exposed, even a inexperienced user will be easily able to report sufficient information wich a WARN and its stacktrace, even if the callsite's alloc check doesn't provide it in an obvious way? > +++ b/mm/slab_common.c > @@ -1119,6 +1119,8 @@ static void *__kmalloc_large_node(size_t size, gfp_t flags, int node) > void *ptr = NULL; > unsigned int order = get_order(size); > > + if (order > MAX_ORDER) > + return NULL; > if (unlikely(flags & GFP_SLAB_BUG_MASK)) > flags = kmalloc_fix_flags(flags); > > >