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 F18FCD3C92A for ; Sun, 20 Oct 2024 13:00:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0657C6B007B; Sun, 20 Oct 2024 09:00:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 016236B0082; Sun, 20 Oct 2024 09:00:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E46B36B0083; Sun, 20 Oct 2024 09:00:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C58A56B007B for ; Sun, 20 Oct 2024 09:00:16 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D35971A1247 for ; Sun, 20 Oct 2024 12:59:50 +0000 (UTC) X-FDA: 82693988412.23.991172B Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) by imf29.hostedemail.com (Postfix) with ESMTP id 1C0FA12001D for ; Sun, 20 Oct 2024 12:59:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=lcyRAnpo; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.175 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=1729429139; 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=fKTO3aGRhIuhtX4NJIjSDqESRx2aC0y8FrcibKpdSIM=; b=YTnszYFYd3Z7lWE53a0deDwRpdcI2GD1OMJLrJ0h/6DGqcvfRdYmjOGFxkF18tctSjkaTA 1JFCYdach+eDD4Io+M0crdbhjMhfiSQF+7KttDDbaAQObB3nd4ZyLkDEod/orFjRZ1n4jL MpaFbHpRtK91W15ZmmG85FUMZnzbVVk= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=lcyRAnpo; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.175 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=1729429139; a=rsa-sha256; cv=none; b=oXqrEOubmMhMGo+dSAth7nXE2NmIpd7fdlQIsDiGHEVS5TZJwVVdDZeIsSs90rfO2ROIhq JPVcL4l6PgFV+g7Ly6iLbU/2jxW4xQL0r4xiidKIVzSXf8HmOnSAHBCtOM0NxKLhSCxnOZ vcD3D3viR89BneSnu8wMsJ8tegxkeQA= Date: Sun, 20 Oct 2024 09:00:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729429211; 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=fKTO3aGRhIuhtX4NJIjSDqESRx2aC0y8FrcibKpdSIM=; b=lcyRAnpoiBD94/wQMCv0kAfHEnMX3SQPWt2IBwEGpmx2qGIgccHoxOfOCboCLMFBzvjL77 3xG031qTwomz2TWQZA7WszgKxh6u0HUtmFvMiz1ckJabuiax5s+Y/4R1WIpPSqFDrKl+D0 n9RhGcz4maEdiF1HUoc1PG6u80ClriI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Lorenzo Stoakes Cc: linux-bcachefs@vger.kernel.org, linux-mm@kvack.org, Vlastimil Babka , Andrew Morton Subject: Re: [PATCH] mm: Drop INT_MAX limit from kvmalloc() Message-ID: 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: <90bc0794-4cab-415f-a442-4af85a32eed8@lucifer.local> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 1C0FA12001D X-Stat-Signature: kg3f1qdxn4s5toeoyfmpfsa93wo1wdyn X-HE-Tag: 1729429195-76351 X-HE-Meta: U2FsdGVkX1/hTG9SdOLLXvj4lDaESpTjbaDLXFhPfEJrMim3UBjXOcA6ol3HZoe0D3pOz5hXF5Evj8G3WEzC5bFTADsf4d3zCnVqtwzYuXyCvkTbY0SA3U68P85Kawxe/4x40w20/4Su4xNqMc6MF2XJLa13yFBRv2q6en+hXm08B7CCa4A38Is4O7ImYkkdgn6fzZ+3YHJWWeU/jrtGJ16Oo4iLxY+1xRlWjeZiJVsynhyQlNUgwPkGHkwobcZwejD2C+afqEMTNOrccILrcSwWwDBT+J5gI1LbW6iq6jobCZWzelYKk9HXURzBNXESqRIvjZxjhy+GoMo/WWm570qeS3k4j39+DCD3regO+tN73/kzz9E/SrM0a+/+XjuAL4n79cML9TPOOGpY+hQc4sanRc7PQu25vEb4O35t2mgasbuQ9s0hlisRB/8PpRKw0NF2BpbHwKvtYmc20bZBD6WXr9MoCcrvZtCxshs/l3MhJvOrur5Uy2fAwl5fNSitQrtn7H+Z4fSqxooU43tREgAuGRln1XPQCBAk6t3n5KeMY/HHST6AKlFB0ViI9169UojGak+SqbpcgGkFoPD9zVqoX4YRFWo/zGTD81WCe2BujUWqU+sOdEjwCw7fJruewxwfdOiIK28rKvY0fyu9MWeFqwf7tsbg/K3wogaj34XeNlGs0RU8S0oZV+nY7qIGmGxc10qjitk6d9sS7MpyoZmZEVReuD0is8/gJ0/i1XWeS5dMlawJSEHPj4QS5WWmfGPbKuMoCHWSA04gZ33M41oE7XJkRVlhEf14KSfdsvZwI3eXxS7w2NctUs9P2hjm9hzVZllM1LvHxud670gHIzoxn0pAD1OnaRUzn7SoPDje1O0mZgm/w79v3hLsPEte0y2pXo1p59x4tzWxRuZNmBpkJPqCE47gt4YCwKYcUHx67hicpuaUpA99Sn7hd6xz54cIYNvBOc8qsZrdjSc x4x4RFhh JOQCXIST28nKuizv2x9D+zFvCQfIKIadqiGM3k6GKKWssdNLSC3KO1y6JA2MPasZAovW6Bz3RU/s4WXMpJy+0gfbkw2ORc+BNyx3EbM3pCB58+VmYdF+wP2At/5U5KLOUeixDnmZ7JsATyuPJFDmkCl3sIPw8WJfjE60vJnl977qHilAlCF+WD6kdnxqfMq2jGGT+1eIbgboHx/wToBtSBg2ydmoX1rjy8VrPUx8SCLd6VtlbypEib6GC5baPLpoWUnbSw78qjBAr0lQ= 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:45:33PM +0100, Lorenzo Stoakes wrote: > On Sat, Oct 19, 2024 at 05:00:37PM -0400, Kent Overstreet wrote: > > A user with a 75 TB filesystem reported the following journal replay > > error: > > https://github.com/koverstreet/bcachefs/issues/769 > > > > In journal replay we have to sort and dedup all the keys from the > > journal, which means we need a large contiguous allocation. Given that > > the user has 128GB of ram, the 2GB limit on allocation size has become > > far too small. > > > > Cc: Vlastimil Babka > > Cc: Andrew Morton > > Signed-off-by: Kent Overstreet > > --- > > mm/util.c | 6 ------ > > 1 file changed, 6 deletions(-) > > > > diff --git a/mm/util.c b/mm/util.c > > index 4f1275023eb7..c60df7723096 100644 > > --- a/mm/util.c > > +++ b/mm/util.c > > @@ -665,12 +665,6 @@ void *__kvmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, int node) > > if (!gfpflags_allow_blocking(flags)) > > return NULL; > > > > - /* Don't even allow crazy sizes */ > > - if (unlikely(size > INT_MAX)) { > > - WARN_ON_ONCE(!(flags & __GFP_NOWARN)); > > - return NULL; > > - } > > - > > Err, and not replace it with _any_ limit? That seems very unwise. large allocations will go to either the page allocator or vmalloc, and they have their own limits. although I should have a look at that, and make sure we're not triggering the > MAX_ORDER warning in the page allocator unnecessarily w hen we could just call vmalloc().