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 F4171D3C92A for ; Sun, 20 Oct 2024 21:57:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83EFF6B007B; Sun, 20 Oct 2024 17:57:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EF456B0082; Sun, 20 Oct 2024 17:57:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6908E6B008C; Sun, 20 Oct 2024 17:57:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4A1786B007B for ; Sun, 20 Oct 2024 17:57:21 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 542CBA0117 for ; Sun, 20 Oct 2024 21:56:54 +0000 (UTC) X-FDA: 82695341736.06.7AF646D Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180]) by imf19.hostedemail.com (Postfix) with ESMTP id 3B04E1A000B for ; Sun, 20 Oct 2024 21:57:00 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OVTKdxr+; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 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=1729461364; 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=BXZIZH1RB87sxa9BBak3KfUIdbvXtJnNAShnXpitbas=; b=4eRCb2N9se6lnEL33nkgsK7EmpzvHS8/iFTF0Qp5qL4wBCFcGGA4ZAA5WHm9EqbNAmfPdr E9Kq2yMheN1LlHNYeypN7DZsgozvhkaGWk3F+qRyiQnmrWLVMTkx+IOeo3hOFovcPHo1Fo VHBNdTqxzdXv7x49HOWc1+S9JMNEZIo= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OVTKdxr+; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 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=1729461364; a=rsa-sha256; cv=none; b=bJWV8CEczyuMOTtDyzlA2zdAh1VajZOJWv0Qu1TjPG5XAUbOOyv+QTWWWT+yfmjYPbBB3P +hBOaSYOrQhviOTQpwiWehwl7J117n+qsoxFHeiDmw0gpBw7d4fd3HKA5ICZ8AP5ZuYgsO O8efhfVqtojQFQ5h2+EdGSKnRyrCnDc= Date: Sun, 20 Oct 2024 17:57:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729461435; 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=BXZIZH1RB87sxa9BBak3KfUIdbvXtJnNAShnXpitbas=; b=OVTKdxr+CZ8a+IT/Cik16l7Py1g91nErkRGXCLXZO4OVAm2/KmMxn6yNPaEu1i4EFL2bEM hk1QspwLSnfubjbuNS+gwTfftIPvhHpwua6AtmgLhJyVj+YFu7AAiPovJlh94U7qCjC2SE n8r0/chWu649SxTo46/tqLITf2Vz6UE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Joshua Ashton Cc: Linus Torvalds , 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: <4pccb6s6rq3mbpthglkqnee3uebhaqdmdj42quryr2jwz55pio@orztt4y3fpve> References: <6eo3gekf6twbnzhpsi2emz2s6sgtof6iba2rvbor7himmejoq5@qbfwtpbpvqoe> <690cd8b8-5095-4560-a555-773a2068305e@froggi.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <690cd8b8-5095-4560-a555-773a2068305e@froggi.es> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 3B04E1A000B X-Stat-Signature: t6kn8z648bhy93utaobjk7w5ba7bofj6 X-HE-Tag: 1729461420-634269 X-HE-Meta: U2FsdGVkX1/sop78XjxKLoTIIvvoZRU1ZHScKK/hjQIWWtcXpoiQNn83X0qqJKc/YcJf+gvqE9TzAcvJRWQaRuDl+Ic3fEh4x0DYLCOzmoBpFo74r7kUd3ssakGNB4zDoHgtHpa34glG28hM2wnf02ZT9K6XfGrqbZX1OZnvAdKhPIMM0dufu6zxSscjtppLLxxEsQ2Lu6tTvyihrZeZf1l6Rf9xoZiQfKm9UyJZve4i3k+Uw395sb/gtvnYx+8LR5acbTO6CTRSe1wRwH5Ah/Q8F5osijZLFWvhprvxZxUrWZys0KwKfSpQo8Dh1UwNLTh9fuevN7zh48L2vy+O3QbLr+yI/MC1kWaXjbEvDaANBC7M7G7W1I0f06n3p+m74erGgYhA+6w3H7KvtiTAxXswVqDaXQ8T99E7Lr6IE8n+FMqONAXxCqJxvRu7KohzxmDE4fSvqM/Um1CHMe0IfUDd87pKEFUQVlIyr9fFt2sUwuwSuzrgRwk60/tTctDzlFF6VLI2Qr6rWkXLkuISzAOvV/XW01q1t4Rl0dodnEbY6ke/y/SMLBidAlPvd5eOCS4qmg/Q1xtoTFWEitQJnwFgzJc2pXiPwP3AtZXx0BvTKBuuhFPIKTref+vpIFQa5DnycPaqrEGc1z47n1Aw2wxqx6it5sQcEJfL0fFOPUUG84hrjr6R9PZFyVI7rrdyNRpQ7q2RU13QGXjCbojxSAa1NQ65Vb96SrdnR64ke2Wvw48l4+Z3fTXg1Caz0yt/3akl5YgROZ/F7y5kh6v7yToN3yJsXbqrIqRsXOgL3aKfxu6imVhhMAkzYTUY/URcdzYBJmXnEkEcCww66FPJooBteoWHLhoL2CZNulTlOSKlkuZw6Vb/aNosOcBXzakKHulzKo/8DJw3Xeh4uSoCHsV/RlfbhwvCtyXS23UZe9gPLKgEsMP9+D/t5NTb7nBA2v1ZhTJ56UcVqYQmP5z Q8gWScgD nJrubs8PcG/AKQKKfQxB7tiEaqkQ5Mwo2c32P5UwhqKovLoMQICYwKeJMnSKSd6BLcVhJpFTpVrlUWBn3e0X9/CA05+hye/LqPRh4kYNEnMudWLhio81/wHLhr842k4FjcA5eqrYMS6TWM8/pA4GuuTUGRsKw43ah+5HqcAf0j2P07WaCLyPPfNJx+vJaws01nuvc 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 10:51:10PM +0100, Joshua Ashton wrote: > > > 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? The journal keys has to exist as a flat sorted array, and it has to contain _all_ the (sorted, deduped) keys that were in the journal.