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 F0751D3C92A for ; Sun, 20 Oct 2024 21:51:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A25D6B007B; Sun, 20 Oct 2024 17:51:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 552326B0082; Sun, 20 Oct 2024 17:51:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 419756B0083; Sun, 20 Oct 2024 17:51:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 239E46B007B for ; Sun, 20 Oct 2024 17:51:34 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3D6E8161407 for ; Sun, 20 Oct 2024 21:51:17 +0000 (UTC) X-FDA: 82695327288.22.EF3D137 Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com [136.143.188.12]) by imf28.hostedemail.com (Postfix) with ESMTP id AB91DC001E for ; Sun, 20 Oct 2024 21:51:17 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=froggi.es header.s=mail header.b=HmXpAJmi; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=pass (policy=none) header.from=froggi.es; spf=pass (imf28.hostedemail.com: domain of joshua@froggi.es designates 136.143.188.12 as permitted sender) smtp.mailfrom=joshua@froggi.es ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1729460970; a=rsa-sha256; cv=pass; b=zwM6ICYZZdm8EYc4hPVwz85P+cG+lvS/i5mlWq3kuii7h/w+OiV/IGnYS/ufn97vOwsDm2 b8NTv+OTbUkDn/g7ovSCZMqpAnDpVtyfQrjcmY9K299bfnW/+BqdTqbgjC3wJZ4xF30pOb DvKjwhS9xgcCru9hZ4SmqE55CGV/O6o= ARC-Authentication-Results: i=2; imf28.hostedemail.com; dkim=pass header.d=froggi.es header.s=mail header.b=HmXpAJmi; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=pass (policy=none) header.from=froggi.es; spf=pass (imf28.hostedemail.com: domain of joshua@froggi.es designates 136.143.188.12 as permitted sender) smtp.mailfrom=joshua@froggi.es ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729460970; 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=+8w83Jkn9ES5BzP6kNp7Mqf1NH0mNG2o6IfBlRYom7Q=; b=GJ/WO2hESAvbmJtsu8qfGX/tcfsZ0DIDxTnsyw+n/J2gILUCV/2J/bzhR5rCGbFZdq23Ta gFgygRiHcrLI5VTolZd1bhKwBO8d3oqoE/t6PXC0CBGEdZfVTrC0zTFg9GeQcFiQPCOAhy fgjOfT5sb5breITQVsg738WMLpZJwAU= ARC-Seal: i=1; a=rsa-sha256; t=1729461074; cv=none; d=zohomail.com; s=zohoarc; b=KXwUdGO2sIsnWAIvIuWOcof4lYw3rF7qFO1lFV3eHFeQsRc3680tzNwUn1GNMCdsZyb3tyQtf5uhqPwHA+MD67yJVX5hUGoe0UI4PFmzLTI3pvvHKd3CK3DLKCfZFT+Z+59efw0AGS9FFgalk4nkPs/8Hyfk4vbBwg8vtk9VDpc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1729461074; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=+8w83Jkn9ES5BzP6kNp7Mqf1NH0mNG2o6IfBlRYom7Q=; b=aAExMeujMGSPfT4fE6iojrSQlHrh9dczfyP3PjQqijKvyZiet5MCjfjNfOR2HyFW63EWy6E+0MebulVgKXllA8qnMMvJEx4ZvI3+9n3RSDAk2Xe2XX6Ate3APggC3Y6E7SpFJE1BvVXpP99sRUdBuYnd03FF8OK/nBiQ6eZpYgs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=froggi.es; spf=pass smtp.mailfrom=joshua@froggi.es; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1729461074; s=mail; d=froggi.es; i=joshua@froggi.es; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=+8w83Jkn9ES5BzP6kNp7Mqf1NH0mNG2o6IfBlRYom7Q=; b=HmXpAJmi1oxJkxvo0BfBdfIbY1oVBlFIfhnq7AKrOpFYq/6dCY1fxzQbZr6EflMf Eej3mLkauSV+h6cXA7gc66Egfx6o5gdoedk9KgkD8WVB7/EPLD1i0LnKEchTJ8Tb3h8 LY3kwt8ymYCGN2wmQi23Ft8k+GGkJ2ZgWA8LwLzg= Received: by mx.zohomail.com with SMTPS id 1729461072846891.8886711215888; Sun, 20 Oct 2024 14:51:12 -0700 (PDT) Message-ID: <690cd8b8-5095-4560-a555-773a2068305e@froggi.es> Date: Sun, 20 Oct 2024 22:51:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: Drop INT_MAX limit from kvmalloc() To: Kent Overstreet , Linus Torvalds Cc: Lorenzo Stoakes , linux-bcachefs@vger.kernel.org, linux-mm@kvack.org, Vlastimil Babka , Andrew Morton , Uladzislau Rezki , Christoph Hellwig References: <90bc0794-4cab-415f-a442-4af85a32eed8@lucifer.local> <6eo3gekf6twbnzhpsi2emz2s6sgtof6iba2rvbor7himmejoq5@qbfwtpbpvqoe> Content-Language: en-US From: Joshua Ashton In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: AB91DC001E X-Stat-Signature: c3dypxjgo5jr1yfd3yyp8oe4rjaui7x4 X-Rspam-User: X-HE-Tag: 1729461077-370101 X-HE-Meta: U2FsdGVkX18nV6zkKPu/QURxum56LkOn8wkmxpig+B9p2UvIrJWo67MGFjactrsf9p00rMVmp848cMak9w3V7y8qSMZkoUjueK5PwkkdEFzjppcatwORDpgMHSJqiz9AhXjkvxyx2Ffa6oHaB6zx8jEgeBTXJ2MaPZGiw0vD3SwVnoN8FKoTjl39ku82mir23wDThOFTeqTID4k3bxt0RXiUJJ3UlmOoNh10y7gXil4yd7XAle9FjXtYAVl/KRGegtGd4VTFRBSQv9em7Ylb5eoSlDSpo+y40xhVA7V0uOylnnHoDzg8fg6Uf2OmSTh9DYA5PfHk7XVryBo8eI8P9ybCZpit195TMeZpkd+258S/yYrghotLJJWVmxphmC6Bq+7XosH8sIu6Wu7Ay1rXRE9oS2fGLOVMLH/g+vmcHg9a3vt6cSdAjxbPhf6Y0Hes2YCRBdNUamd1m22MfIodsJ7r0/xkHeavXcJjg1a9IHtXHynno7VcpWjI744H0JGKbL0D7wJzWG+DwBR/2uD6u2R3SM9V2yHJtDhrirkLoMV6P782vOL37txepKVk3gegEBVzSp/agzwWmNEfnKnnnifA4E0pYuWx4k7AQ2tqByaE85hvbrQWNGtnrfHZpEDvus6SrAEfw6eg/EgDU87/sTPv1RTc28X+yaLJMsW+1AVubVYTVPMODmx6cf27wLVcBsG2LNnvsmAgWp6RdbBZcJhYtC0+wdiNYjt+yPnqSPnA6hST2ICHqVRfK8wU8dpQVJx8z/JYRHrV6Tu3SP1bb4Y5r6bePnrZmvY70cKHXClk6kMKXLNam4028a8b/Lwgo/eY5WHa5FImHcXOgtcarfnX4Q7pUXaZ8y1eQK73HSMrZ9Qt3Mbqhw/6Zhzds8BbV5rPsDx7YcVRC2kNBQaQMWfUe5pilIlpqdB2cF7B/tw9cYBH9Z27GzyMEw+x8+AkfLW0evaBXjU46MVFPkY VfTDBGBm qMz0twAqm4kS11tq5cGKWK9aS7yNu6YRLLqtYPCQIqmzVhBKKBwQAeAdYR6WVK3kcAHg1Xt0RyrUKJewRvE5MpaoHJ7ZaIZ+5eaUzjsVzwV6MBvyNRQfnFtGs6JBgg02f3S90Hw5yJDQyesMpxtxOVCRCVTRzSl5c3zsEr5GVp+5faahNvqKex8Vq4jhMX0JHoyZkNBfETrW1Q/Ui46Jn6ML7YYixcq1Tx9hm7eLMkeeufuEery81dX4+2uQZ1M3rW7ZOf0UArp4DUm7Esmf31V4zRadhkAR5K95AQlav2i9Y9hdbV2ieNVlwHbIG/C2a30SxqGcdemCRJiGSYWaWyHn5hIaNbbSeeRnpfcUxCRp4LPw= 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 10/20/24 9:29 PM, Kent Overstreet wrote: > On Sun, Oct 20, 2024 at 01:19:42PM -0700, Linus Torvalds wrote: >> On Sun, 20 Oct 2024 at 13:10, Kent Overstreet wrote: >>> >>> 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. >> >> It fixed a real security issue. > > Which you quite conveniently aren't naming. > >> Enough said, and you're just making shit up to make excuses. >> >> Also, you might want to start look at latency numbers in addition to >> throughput. If your journal replay needs an *index* that is 2G in >> size, you may have other issues. > > Latency for journal replay? > > No, journal replay is only something happens at mount after an unclean > shutdown. We can afford to take some time there, and journal replay > performance hasn't been a concern. Then why are you arguing about there being an "artificial cap on performance", if you can "afford to take some time there"? Am I missing something? - Joshie 🐸✨ > >> Your journal size is insane, and your "artificial cap on performance" >> had better come with numbers. > > I'm not going to run custom benchmarks just for a silly argument, sorry. > > But on a fileserver with 128 GB of ram and a 75 TB filesystem (yes, > that's likely a dedicated fileserver), we can quite easily justify a > btree node cache of perhaps 10GB, and on random update workloads the > journal does need to be that big - otherwise our btree node write size > goes down and throughput suffers. > >> Why do you keep on being the person who creates all these pointless >> arguments? Not just with me, btw. > > That's only going to get the biggest eyeroll ever. >