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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00C75C6377B for ; Wed, 21 Jul 2021 20:46:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3DD86101B for ; Wed, 21 Jul 2021 20:46:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229927AbhGUUGM (ORCPT ); Wed, 21 Jul 2021 16:06:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbhGUUFw (ORCPT ); Wed, 21 Jul 2021 16:05:52 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C4EEC061575 for ; Wed, 21 Jul 2021 13:46:28 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id b26so5164523lfo.4 for ; Wed, 21 Jul 2021 13:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHmWOsRJBltjYo7lCFhKzzQm+gRr0aziJWNnsm+aX04=; b=AKrRqb6ZSHyas0lTpEb/OJQ4sS90yqcnp66+16rXaoYcS9JZ1Ft4L/FV31nBUbXqRd ZQVTk8nuT1MLONhdGXvRXJ1/SOVPhaYqRU4JWvyDLFp4E9MvKBl2qDDX/cMEYMIktlX+ 4w9O+vfJH3cBANYWYhDUgZS5akjmCFNy7wctk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHmWOsRJBltjYo7lCFhKzzQm+gRr0aziJWNnsm+aX04=; b=oHtIROqFHhCSYFcRg9K4OiK/G7UZHndyF2qxqAgPIJ1BLvo51pQEVHSp8Z3csv5e8n jIuFm2Ex5nwop9amyt8NB5DF6BxNUL2EpawLc9PX1zDCNi5iYXGW9rbphmAcQtZVEVh9 GFXd8Y/MqIp8ZRGmwx0KnehAxxSHKQxw3inG8pZD5T825GUTHONLr40J4wizgjH7rQHc 5sGh7xqUlqNwf061LEyb7jgceCLkAu//9TzFOtlPtbwW2tPt9EohokaCHJGeBzNE4t31 y+xB339qK1BCSN1TYoKMKWQO+wIdsdksvKMzznnuKMLCV1BSRdssxNMxMXWrepkn8TTA vCLg== X-Gm-Message-State: AOAM531QSQjlXT+hzsr7tSvg06WX+V9J0xEcFC/wN8CG6Ks3twXs69b0 uE1DHoAb7CBAIuCjhISW7KunQBIg2W/EwmKQ X-Google-Smtp-Source: ABdhPJzsdcXWYKov3G5N5yDGfrOsYAvWuQ8dbhpL7O/AtKs0mAslDJoHNe7d8kyt0C0Xa9Om2Nh2iw== X-Received: by 2002:a05:6512:3697:: with SMTP id d23mr27344232lfs.552.1626900386416; Wed, 21 Jul 2021 13:46:26 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id k21sm2822879lji.107.2021.07.21.13.46.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 13:46:26 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id h9so4670407ljm.5 for ; Wed, 21 Jul 2021 13:46:25 -0700 (PDT) X-Received: by 2002:a2e:90cd:: with SMTP id o13mr16148707ljg.465.1626900385724; Wed, 21 Jul 2021 13:46:25 -0700 (PDT) MIME-Version: 1.0 References: <20210721184131.2264356-1-willy@infradead.org> In-Reply-To: <20210721184131.2264356-1-willy@infradead.org> From: Linus Torvalds Date: Wed, 21 Jul 2021 13:46:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: Make kvmalloc refuse to allocate more than 2GB To: "Matthew Wilcox (Oracle)" Cc: Al Viro , Qualys Security Advisory , Eric Sandeen , Linux-MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 21, 2021 at 11:42 AM Matthew Wilcox (Oracle) wrote: > > It's generally dangerous to allocate such large quantities of memory > within the kernel owing to our propensity to use 'int' to represent > a length. If somebody really needs it, we can add a kvmalloc_large() > later, but let's default to "You can't allocate that much memory". I really think that without the WARN_ON_ONCE(), this is just moving that failure point from a known good place ("we know this must not succeed") to a possibly bad place ("this might cause silent and hard-to-understand failures elsewhere"). IOW, in seq_buf_alloc() there's no need to warn. It's clear that a bigger allocation can never be valid. But in kvmalloc(), it needs to warn, because if it ever triggers we need to check what triggered it. So this is not just moving code from one place to another equivalent one. Linus 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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57FA9C6377B for ; Wed, 21 Jul 2021 20:46:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D452060FF3 for ; Wed, 21 Jul 2021 20:46:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D452060FF3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6DC6A6B0036; Wed, 21 Jul 2021 16:46:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 68D226B006C; Wed, 21 Jul 2021 16:46:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57A966B0070; Wed, 21 Jul 2021 16:46:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 3BD1E6B0036 for ; Wed, 21 Jul 2021 16:46:29 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D838D26834 for ; Wed, 21 Jul 2021 20:46:28 +0000 (UTC) X-FDA: 78387778056.08.7FF54C5 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf21.hostedemail.com (Postfix) with ESMTP id 7AC8FD01CA78 for ; Wed, 21 Jul 2021 20:46:28 +0000 (UTC) Received: by mail-lj1-f173.google.com with SMTP id y7so4699794ljm.1 for ; Wed, 21 Jul 2021 13:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHmWOsRJBltjYo7lCFhKzzQm+gRr0aziJWNnsm+aX04=; b=AKrRqb6ZSHyas0lTpEb/OJQ4sS90yqcnp66+16rXaoYcS9JZ1Ft4L/FV31nBUbXqRd ZQVTk8nuT1MLONhdGXvRXJ1/SOVPhaYqRU4JWvyDLFp4E9MvKBl2qDDX/cMEYMIktlX+ 4w9O+vfJH3cBANYWYhDUgZS5akjmCFNy7wctk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHmWOsRJBltjYo7lCFhKzzQm+gRr0aziJWNnsm+aX04=; b=Bs6M1GnVDaw3Vw2pi+cehLcIdFWn+Ae9FNi/AA1vXPwCZWv3QpG0hJ14SpD46m8QA3 PF5eZX33i1lV/R6sOgeJkgMlC7ckhOtSb8S+OBSdpZ9X7a6jnLiayiY2Mvl5Z/Z281D6 Imbnn+F46rcNd5A8MYlwZmGKoMkzSWZtXu5nQ4WvTOth1jzbp9wrx+2nxCrNpdcDOyD1 DAEAAH+/N/w+33O2oZjhUOYkXQzU1ndpUhWavK2QUHoYiICWxgPw6fbyf4rA2ZU9C9Pv FqyQU121OcOkNkCSgjCS8lUWCSbkj0CHWBDn256/GiJ+FguXpltMjPOjyZ+2RtCpoBHr XXjw== X-Gm-Message-State: AOAM53345JiMGN1cnbaF9Y4ehE3ijc7ORF/wzaA9A5Kj4kIIFNuC5Cqs fir3/zG7B6ILAoXnN9LIPZoyp//XMdbYHLru X-Google-Smtp-Source: ABdhPJzNZEESl3IKwkUKmAV7GiRO7fLSp0Y7d4km9aK7SdiJzavcT12CThEJaanlXuorNaMWFQR3CQ== X-Received: by 2002:a2e:a7d4:: with SMTP id x20mr31728783ljp.418.1626900386510; Wed, 21 Jul 2021 13:46:26 -0700 (PDT) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com. [209.85.208.171]) by smtp.gmail.com with ESMTPSA id r6sm932758ljk.76.2021.07.21.13.46.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 13:46:26 -0700 (PDT) Received: by mail-lj1-f171.google.com with SMTP id x24so960290ljm.4 for ; Wed, 21 Jul 2021 13:46:25 -0700 (PDT) X-Received: by 2002:a2e:90cd:: with SMTP id o13mr16148707ljg.465.1626900385724; Wed, 21 Jul 2021 13:46:25 -0700 (PDT) MIME-Version: 1.0 References: <20210721184131.2264356-1-willy@infradead.org> In-Reply-To: <20210721184131.2264356-1-willy@infradead.org> From: Linus Torvalds Date: Wed, 21 Jul 2021 13:46:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: Make kvmalloc refuse to allocate more than 2GB To: "Matthew Wilcox (Oracle)" Cc: Al Viro , Qualys Security Advisory , Eric Sandeen , Linux-MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7AC8FD01CA78 X-Stat-Signature: xdgt9j91hsp5jmnjhorrn4zpgm8xbfnk Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=AKrRqb6Z; spf=pass (imf21.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.173 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1626900388-121742 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: On Wed, Jul 21, 2021 at 11:42 AM Matthew Wilcox (Oracle) wrote: > > It's generally dangerous to allocate such large quantities of memory > within the kernel owing to our propensity to use 'int' to represent > a length. If somebody really needs it, we can add a kvmalloc_large() > later, but let's default to "You can't allocate that much memory". I really think that without the WARN_ON_ONCE(), this is just moving that failure point from a known good place ("we know this must not succeed") to a possibly bad place ("this might cause silent and hard-to-understand failures elsewhere"). IOW, in seq_buf_alloc() there's no need to warn. It's clear that a bigger allocation can never be valid. But in kvmalloc(), it needs to warn, because if it ever triggers we need to check what triggered it. So this is not just moving code from one place to another equivalent one. Linus