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 2701FD3C92A for ; Sun, 20 Oct 2024 20:11:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A15516B0083; Sun, 20 Oct 2024 16:10:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99DC46B0088; Sun, 20 Oct 2024 16:10:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83E536B0089; Sun, 20 Oct 2024 16:10:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6361D6B0083 for ; Sun, 20 Oct 2024 16:10:59 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 523A6C13A0 for ; Sun, 20 Oct 2024 20:10:43 +0000 (UTC) X-FDA: 82695074070.29.64C9274 Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) by imf02.hostedemail.com (Postfix) with ESMTP id 816D080006 for ; Sun, 20 Oct 2024 20:10:30 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NJVHQ6+v; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729454859; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8+WUrAZeDaIfbm/rwydenH45/8qy5IlgB9W6a1mjdNA=; b=Si8OG6oe3gFSgTc1ZWGFScM0NIAS5Z90v0we0BMxLJbxBJQYAv0ETyCVOJex+u2PHgs2z2 QaRKZPgFuw5OpmzZ7lijglmss/wTrKHAkNy6wkA0esqe7WjwYX8DRfmnSnOUGbLcVCjwFr lPE34RbJBmtBVQJyGQSZqNQiqWdrGUM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NJVHQ6+v; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729454859; a=rsa-sha256; cv=none; b=rp7+jLWINK2vHvsOE2KG+8m7u4GVQpUpUZCAvAkQRyZuqu+iSyH5lDcH+F2Qr3Ks7POMhG bJKuAmalXsM739yVqXGQU5aQRiIaFGb8D7xjUGoDZXcqxSPlK7nIqcsjubKi7hy+Y9MIeO utxkmj177iSinZLRdVB7bmfKlmYrypc= Date: Sun, 20 Oct 2024 16:10:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729455054; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8+WUrAZeDaIfbm/rwydenH45/8qy5IlgB9W6a1mjdNA=; b=NJVHQ6+v6yJzktHOsnTnuF8lJjdzyyIfznULlRHL5+tBOEzTsuVpyoRuIqyNMI90CtcZo/ VfaOefsg9jg47fn19aWId97sxXNosr09NaBbfKLelH5ozJo5HCrIxVc/05qi45YAnCVbyU nOJvHSutEPMZ5WoX1k//rPfz9g1WlMU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Linus Torvalds Cc: Lorenzo Stoakes , linux-bcachefs@vger.kernel.org, linux-mm@kvack.org, Vlastimil Babka , Andrew Morton , Uladzislau Rezki , Christoph Hellwig Subject: Re: [PATCH] mm: Drop INT_MAX limit from kvmalloc() Message-ID: <6eo3gekf6twbnzhpsi2emz2s6sgtof6iba2rvbor7himmejoq5@qbfwtpbpvqoe> References: <20241019210037.146825-1-kent.overstreet@linux.dev> <90bc0794-4cab-415f-a442-4af85a32eed8@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 816D080006 X-Stat-Signature: d65kkt4bjfmsiie9y1k5y47q793ejwfr X-Rspam-User: X-HE-Tag: 1729455030-917829 X-HE-Meta: U2FsdGVkX19B+MyVxeVp0KtnP7jw+klCDoQYTaXkIl9vAXc7ye1hB2UyPPZF6qbRmEqg5+woSBTFortD6Pjz5C8IxhujmtfcvXdnLv03OmnRQr942G6983jPdLYjXj48x0E9mKZFlG2V1xCEfF627KN0FvcHQswhQ+VoinHFcq1+d2fpeDe+PmNXMqDybtJJk9h8Cw09eVTTLJu4bk2CxgTW2CBIaXj3WEgHfOHycTod9twTDoiaKoUo8M3OrAJ5jyKCRupiZiUevuQwR74fJP11XdgrqFQPWpupjWkXyow24+0SvDu5+8BwCTVaP75XGKfjhHJwu+/XmRYtsI6UJVeot5Fwa/iYWdrhYmnkbBSeFgFcwx5bQEjgEELumL/2xD74W33vtLPXXMqwi3BHYBC3frvZFzIcPe7Lx8KqdWhHea4Lf3JBH8ZmLYo4ShH8Pq13Vd8vupeeX/Gf7pYit3MP1TbDJAACyBzuVLa/bKiePcNbjxwLNNMudedyfqZiZgMABQl0nrVvOWZ7SmSDqJPqxUjRj/p9bodDmJv+w2jNzxEcGA42cxomNERzLF1xj73frlZxE6Ns1PEjmF9IyrM+Wah4i4VE1KCc9omWpuydSrWrasMlmbwg0TK189Hjwdsc8nPxN/9QJtLtMDIkCDNgInRnqZGg7E95IpN1tI9YN/JBtcJwaECM1LBH0EVA0KwBQUkjx0LstO6ybdOR6aXkUpKNjhveXrK0ZPWiGLz314r2mzVfc8YakKF2Zr786W+MUDwRhtIBUHxkwubwT5Zm6Fb2hJ1pONXXYZ4Qbbwu4N0ZXbTOzu1uUHfW1p5OiERZTRld5ouJJLgf8RqaGwsa7+TQPBrXP3eBnztFkdQho+ujwifd3sInVM32C1Cbo25vJhv/AEuNNuOojiul1Cwez3lRrHn//andUavAqCrmwNImfLTijxoiYgtVP4jktblp6BDO74FKpiJrimp pLRGWBwq mWMKXZ4joTzxp1MMX1eaaBa2RpQRRFlTUGGM9Bso1j/CKo4rr2JEJez8ZQPUN6oeWthaRvrgv3bY7k0BTfBwyu5VsA/NxARyRcu2w1vcYZHPc4XFZf8wuL1nE34qyCSltzme/S01sIb/zzl9byACCdp4I2mrmadbZbUucmTYcqYGH0TjO85j+WcesvqrwDWRl8QQ9wRw2X1ftRRvan1Sw6A2pEJi324YC3NwuWOJEvLgKd/PRbrCqMEVzGXBOfSjGshLEgVdcBpz+dHhOKNz/yZ0hDw== 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 Sun, Oct 20, 2024 at 12:09:58PM -0700, Linus Torvalds wrote: > On Sun, 20 Oct 2024 at 12:09, Linus Torvalds > wrote: > > > > How about you limit the amount of memory you use in the first place instead? > > .. and to clarify: we're not making other parts of the kernel less > robust because *you* are doing something stupid and odd. But back to the actual topic at hand, the security angle - while we don't have ubsan style checks for integer truncation (the real concern), we do have sysbot + kasan, which does cover this pretty thoroughly. And the INT_MAX check wouldn't catch truncation anyways - it'd only catch integer _underflow_, but allocation size calculations pretty much as a rule never use subtractions, so I don't think this check was ever worth much to begin with.