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 324A9C43217 for ; Thu, 2 Dec 2021 21:17:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83B856B0072; Thu, 2 Dec 2021 16:16:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E9F16B0074; Thu, 2 Dec 2021 16:16:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68B0A6B0075; Thu, 2 Dec 2021 16:16:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 5BE256B0072 for ; Thu, 2 Dec 2021 16:16:54 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 203AD181A347D for ; Thu, 2 Dec 2021 21:16:44 +0000 (UTC) X-FDA: 78874113528.13.EEBAAC4 Received: from kadath.azazel.net (wan.azazel.net [81.187.77.20]) by imf20.hostedemail.com (Postfix) with ESMTP id 02030D0000AC for ; Thu, 2 Dec 2021 21:16:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=azazel.net; s=20190108; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0Yc7uTuUXobwOFuqMYK6lgrbotOqoK6CKloGgp2Ox0g=; b=hNOK11THoFabuV+1wx3/5rGI3L hzbNn0gYLNby8pF+IFzpFx9edsXocHy+qE2O8IbgqiIlJ0/+B107biqU652cWnm2mk+9y66xB06fg RrrYa0dMuvTN1d0BXB6coNIhRXjtKq8OhTDl8dF7d//3Ss4fwaILLNs8cSLY6cmNFdK8SvC49dvty UL4DszLRZAaUFwJA/vgUfJu9ZVUBdKxysQ4ifSSzAxCeDg66Yc4NYhr64doHIR1PeWWHSLlsIByB8 nu7dnJVfxr7SKld7J+v6DKQqlCmFSQ4rGqLXFxLjumIEk4V53WczIGlsqFIHcpzMT3tEmT3dobGO0 2kXBNUVw==; Received: from [192.168.96.13] (helo=azazel.net) by kadath.azazel.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mstRV-00DC4R-5u; Thu, 02 Dec 2021 21:16:37 +0000 Date: Thu, 2 Dec 2021 21:16:32 +0000 From: Jeremy Sowden To: Alexei Starovoitov Cc: Andrew Morton , Bixuan Cui , linux-mm , LKML , Linus Torvalds , Leon Romanovsky , Willy Tarreau , Kees Cook , bpf , Network Development , Alexei Starovoitov , Daniel Borkmann , Jakub Kicinski , kvm@vger.kernel.org, netfilter-devel Subject: Re: [PATCH -next] mm: delete oversized WARN_ON() in kvmalloc() calls Message-ID: References: <1638410784-48646-1-git-send-email-cuibixuan@linux.alibaba.com> <20211201192643.ecb0586e0d53bf8454c93669@linux-foundation.org> <10cb0382-012b-5012-b664-c29461ce4de8@linux.alibaba.com> <20211201202905.b9892171e3f5b9a60f9da251@linux-foundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nUPL30MqoHnEoqa0" Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: 192.168.96.13 X-SA-Exim-Mail-From: jeremy@azazel.net X-SA-Exim-Scanned: No (on kadath.azazel.net); SAEximRunCond expanded to false X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 02030D0000AC X-Stat-Signature: nmf6xq9ddzxu47nnqjeuc989yozippwh Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=azazel.net header.s=20190108 header.b=hNOK11TH; dmarc=pass (policy=none) header.from=azazel.net; spf=none (imf20.hostedemail.com: domain of jeremy@azazel.net has no SPF policy when checking 81.187.77.20) smtp.mailfrom=jeremy@azazel.net X-HE-Tag: 1638479802-391198 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: --nUPL30MqoHnEoqa0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-12-02, at 07:34:36 -0800, Alexei Starovoitov wrote: > On Thu, Dec 2, 2021 at 2:38 AM Jeremy Sowden wrote: > > On 2021-12-01, at 20:29:05 -0800, Andrew Morton wrote: > > > On Thu, 2 Dec 2021 12:05:15 +0800 Bixuan Cui wrote: > > > > =E5=9C=A8 2021/12/2 =E4=B8=8A=E5=8D=8811:26, Andrew Morton =E5=86= =99=E9=81=93: > > > > >> Delete the WARN_ON() and return NULL directly for oversized > > > > >> parameter in kvmalloc() calls. > > > > >> Also add unlikely(). > > > > >> > > > > >> Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls= ") > > > > >> Signed-off-by: Bixuan Cui > > > > >> --- > > > > >> There are a lot of oversize warnings and patches about kvmalloc() > > > > >> calls recently. Maybe these warnings are not very necessary. > > > > > > > > > > Or maybe they are. Please let's take a look at these warnings, > > > > > one at a time. If a large number of them are bogus then sure, > > > > > let's disable the runtime test. But perhaps it's the case that > > > > > calling code has genuine issues and should be repaired. > > > > > > > > Such as=EF=BC=9A > > > > > > Thanks, that's helpful. > > > > > > Let's bring all these to the attention of the relevant developers. > > > > > > If the consensus is "the code's fine, the warning is bogus" then let's > > > consider retiring the warning. > > > > > > If the consensus is otherwise then hopefully they will fix their stuf= f! > > > > > > > https://syzkaller.appspot.com/bug?id=3D24452f89446639c901ac07379ccc= 702808471e8e > > > > > > (cc bpf@vger.kernel.org) > > > > > > > https://syzkaller.appspot.com/bug?id=3Df7c5a86e747f9b7ce333e7295875= cd4ede2c7a0d > > > > > > (cc netdev@vger.kernel.org, maintainers) > > > > > > > https://syzkaller.appspot.com/bug?id=3D8f306f3db150657a1f6bbe192746= 7084531602c7 > > > > > > (cc kvm@vger.kernel.org) > > > > > > > https://syzkaller.appspot.com/bug?id=3D6f30adb592d476978777a1125d1f= 680edfc23e00 > > > > > > (cc netfilter-devel@vger.kernel.org) > > > > The netfilter bug has since been fixed: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/lo= g/?id=3D7bbc3d385bd813077acaf0e6fdb2a86a901f5382 > > How is this a "fix" ? > u32 was the limit and because of the new warn the limit > got reduced to s32. > Every subsystem is supposed to do this "fix" now? My intention was only to provide information about what had been done in the ipset case. In that case, there was already a check in place to ensure that the requested hash-table size would not result in integer overflow, and it was adjusted to reflect the limit imposed by the new warning (one imagines that there is not much demand for hash-tables that big). I'm not familiar with the other cases, and so I would not presume to make suggestions about whether those warnings were useful. J. --nUPL30MqoHnEoqa0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEbB20U2PvQDe9VtUXKYasCr3xBA0FAmGpN6kACgkQKYasCr3x BA1DFg/+Op3yh9EB8aITIjFewcU/5ehJujJveseMI0Dhey60wdWRpo9pcOsCqTvO xhJJNW0s8X+31cvl26pxtelcfsiu12t4iEwFztiJSswYajjtvQx2wSP/CB7cE8CD TLjYhZcVoWsJWVONOn9lVwKuA4AOR2lV7r2rybFf6+9YKGzQUaM9ZH6pNDUKqkQd 1ASff5plUkPCvwZBF0SkkJFdPjFLWT3xe3MLfL+IT2vXtDee619DNKUvZu+K8GJ6 fRGqWMpCi40yubOKx/zF7iJ9wMr3zOhoZyIcj7UQYvpIQEqsMp7Lthv3rjnDV8vh WHTxwujs6Gmq/eZt5TCANLaJrATs3veigldNrqYFjjPSDZd1WiqIRD2D/IEZvYyD reVasR8VROsRMmy/ojtj1nWp9SAzi0zQZK9defAZyTp1zSjGTVVrdxMvGtrttfSG BAn/iGm3tEFMu53H0skJAM3TfvG8SCjeTXq4nPQRBsuV+ZiPvkBik38jrDRnNGoH nf4ZYp+iu4Yef6x00qrJPycljZH+m1hWPYvP22L+PHbLt6WZh9i4JroyNqLFbl4y W4eGYyM3kK1GLM1uLCZDrsajdCkN7cpcySHsXdrpND32OeuWgJJpug++GZUblDc8 Md5Yw2c0j3mI8rWwjjibawk40BtgyX1696vfZ5QiJ7o3CtUzAw4= =Gsdm -----END PGP SIGNATURE----- --nUPL30MqoHnEoqa0--