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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DB90C433FE for ; Mon, 28 Feb 2022 20:41:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229831AbiB1Umd (ORCPT ); Mon, 28 Feb 2022 15:42:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229821AbiB1Um3 (ORCPT ); Mon, 28 Feb 2022 15:42:29 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67EAC17AB2 for ; Mon, 28 Feb 2022 12:41:50 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id iq13-20020a17090afb4d00b001bc4437df2cso259546pjb.2 for ; Mon, 28 Feb 2022 12:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=wer/Oz2nOAI419q72n4sbW/GCj0W5Nx8xz2+Rlt0xdI=; b=EPfWBDQTZQfFwTLJ9+iWGHrZjstF+IJdDCO2XmrpedQZl8eoQHqJA+/JViu23cwxXh 4cMj/vzH9luSjFoMSUEnTyFggS72ppUy5QkoOhB1ZLmlYGZVjojhreHYu2ecNsLh0VEG gCNAXqAhIEMo9kYwHuvCozq3SDVVbHt3LuY2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=wer/Oz2nOAI419q72n4sbW/GCj0W5Nx8xz2+Rlt0xdI=; b=kexXhujcmJyP3jcoruuGRi/83yiYE6sDDmWugAuCImKCEP2KrkAos/HcQUAU+4LuKY LY5r6X5BGi73sOEf8K4fKmKPD3zjAyusyC0lG1D+KtqnRY4gGIW+9MIU9vziD8QDoS2J JNgl9nTMc9ItgvzaQPVtRJxkw32sevbXy2eucEOsUuJ7qMi5z8xP/JdQ0ZD+73gVkTLO aKkr/aEYhCMv5pvNOkIhO2yefF4PvcHAN3PIoKz7Gq2taFbGXnVBKtVMLnlxt6BtvHYT 3vGIgUVt+fR2LGw25R1SpRIKLz35pUm+gMGjkih0PRLrm1rJ40ABs/PtXCUqWa/7t7Te TO3w== X-Gm-Message-State: AOAM533d/aPatAiZDHaZ29yEUKc14EomnyKpbbYPX3D89Ua4FKg4e+IX 8xQWzi+Y2dWcsrzIAZedgA1nRQ== X-Google-Smtp-Source: ABdhPJy3Ync6bess6WVePu+xmx/XAAZ+UJXR4GrnPlEoCAlv3kx6LFgNA1dRDLp+plPQLZbHhc+glA== X-Received: by 2002:a17:903:2482:b0:150:15ed:3cd3 with SMTP id p2-20020a170903248200b0015015ed3cd3mr21772341plw.147.1646080908566; Mon, 28 Feb 2022 12:41:48 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id t38-20020a056a0013a600b004e1a0c14000sm15037898pfg.209.2022.02.28.12.41.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 12:41:48 -0800 (PST) Date: Mon, 28 Feb 2022 12:41:47 -0800 From: Kees Cook To: Magnus =?iso-8859-1?Q?Gro=DF?= Cc: akpm@linux-foundation.org, anthony.yznaga@oracle.com, glaubitz@physik.fu-berlin.de, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, matoro_bugzilla_kernel@matoro.tk, matoro_mailinglist_kernel@matoro.tk, regressions@leemhuis.info, regressions@lists.linux.dev, viro@zeniv.linux.org.uk Subject: Re: regression: Bug 215601 - gcc segv at startup on ia64 Message-ID: <202202281240.8BCFBB47ED@keescook> References: <202202260344.63C15C3356@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 28, 2022 at 11:46:13AM +0100, Magnus Groß wrote: > > When the kernel tries to map these with a combined allocation, it asks > > for a giant mmap of the file, but the file is, of course, not at all > > that large, and the mapping is rejected. > > > So... I'm trying to think about how best to deal with this. If I or > > anyone else can't think of an elegant solution, I'll send a revert for > > the offending patch next week. > > Shouldn't we just be able to patch total_mapping_size() again to instead > sum up all p_memsz fields, instead of comparing minimum and maximum > p_vaddr? I don't think so, and I need to have a "minimal change" to fix this so it's more obviously correct. And, apologies, I failed to Cc you on this patch: https://lore.kernel.org/linux-hardening/20220228194613.1149432-1-keescook@chromium.org/ -- Kees Cook