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 9E4F4C432BE for ; Tue, 31 Aug 2021 19:05:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8324E61074 for ; Tue, 31 Aug 2021 19:05:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240165AbhHaTGA (ORCPT ); Tue, 31 Aug 2021 15:06:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239918AbhHaTF4 (ORCPT ); Tue, 31 Aug 2021 15:05:56 -0400 Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC467C0617AD for ; Tue, 31 Aug 2021 12:05:00 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id y128so478141oie.4 for ; Tue, 31 Aug 2021 12:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZvHe6WFLlEOY+cnNyJHf8IUGJZtLzfrewOzKEL/ktBI=; b=ACWt0ukBTDTGH9DZcqNb3LHML6ZIXTJi22x9F1+NGl+2yrk61J+GgzScyE3gFTlSlQ x226k4VgR+xl+Mxu1P2nWpexNXNlNb1LiuVItVK2b3hkNGxNhP3j+ea03k66KOk1vptW JM2F8HfiCiSzN9m0fQJeZ3AwirWfftjNbongs= 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=ZvHe6WFLlEOY+cnNyJHf8IUGJZtLzfrewOzKEL/ktBI=; b=b6zCET537VpXVLO5WYM3TCtc+fqrKRjuQ/qYygR31k20nsf4OgYE4ulLXU14fxgkcJ SwwA39FQKB/7e+ZPz1v4rvF7aGpIdGoVvVo4GKG7XM1qZvbi0NPTQIfkWsvGbuB/I8PZ yyQHmGDpj2OSZuGlILHa0N96XOR+Dwxa9MoTM2wvOHzCp8hxpYffavpggvE0fMzD0trN uIHI9cu/gY/I6e5deE8VsWMHxHVRHZUWxnjH6E8Dsd1p+OdnD1Wpo1GYdcRGL9eicNmV cWPYa/2whGXUS/rZiL4nccx74eO4AgZdWdgjfPVNA20B3le11EG0m2pJCOPq1+ZAF4Kh k/ww== X-Gm-Message-State: AOAM5319UncBSV6Gep+Hmky0fecuf2/Bo0Gz/GNJcn623xLG9b4j5Um0 oKoJ8qZcVqySP3WBxqq/Aee1YtDxLa3gtZ8+KVg97g== X-Google-Smtp-Source: ABdhPJzuNvtIttTsikeJhpfgPjZLhIkRqb9ifqIW1nYLm/S07/enaQExtksB0ZnMvf3m4HMYN91Gb9HNmjtQutiTXpc= X-Received: by 2002:a05:6808:1449:: with SMTP id x9mr4264801oiv.14.1630436700262; Tue, 31 Aug 2021 12:05:00 -0700 (PDT) MIME-Version: 1.0 References: <000000000000815b9605c70e74f8@google.com> <131b24e5-ee31-6f7b-42b4-c34583711913@infradead.org> <2fccb5d3-191c-924e-159f-1c9d423e282f@i-love.sakura.ne.jp> <339bfb21-8e80-c7d9-46dd-c416f87c50c0@infradead.org> <535e404d-03bf-8e7a-b296-132a2a98c599@i-love.sakura.ne.jp> <5c6d2b95-31d7-0d59-5e62-2593d9a0e1fe@i-love.sakura.ne.jp> In-Reply-To: From: Daniel Vetter Date: Tue, 31 Aug 2021 21:04:48 +0200 Message-ID: Subject: Re: [PATCH] fbmem: don't allow too huge resolutions To: Geert Uytterhoeven Cc: Tetsuo Handa , syzbot , Andrew Morton , Bartlomiej Zolnierkiewicz , Colin King , DRI Development , Linux Fbdev development list , Linux Kernel Mailing List , Masahiro Yamada , syzkaller-bugs , Randy Dunlap Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 31, 2021 at 8:56 PM Geert Uytterhoeven wrote: > > Hi Daniel, > > On Tue, Aug 31, 2021 at 8:53 PM Daniel Vetter wrote: > > On Tue, Aug 31, 2021 at 7:19 PM Geert Uytterhoeven wrote: > > > On Tue, Aug 31, 2021 at 5:24 PM Tetsuo Handa > > > wrote: > > > > On 2021/08/31 15:48, Geert Uytterhoeven wrote: > > > > > Furthermore, this restricts the virtual frame buffer size on 64-bit, > > > > > too, while graphics cards can have much more than 4 GiB of RAM. > > > > > > > > Excuse me, but do you mean that some hardware allows allocating more than > > > > UINT_MAX bytes of memory for kernel frame buffer drivers? > > > > > > While smem_len is u32 (there have been complaints about such > > > limitations on 64-bit platforms as far as 10 years ago), I see no > > > reason why a graphics card with more than 4 GiB of RAM would not be > > > able to provide a very large virtual screen. > > > > > > Of course e.g. vga16fb cannot, as it is limited to 64 KiB. > > > > The first gpus with 4GB or more memory started shipping in 2012. We're > > not going to have fbdev drivers for these, so let's not invent code > > for use-cases that aren't please. > > This code path is used with fbdev emulation for drm drivers, too, > right? Yeah, you get one buffer, with overallocating 2. That's all, you don't get the entire vram because we can't revoke that for fbdev users. We'd have fixed this long ago if it's a real limitations. 8k at 64bpp is still less than 256MB. Also due to pci bar limitations (which finally get lifted now because windows fixed their pci code, which motivates motherboard manufactures for desktop space to also fix theirs) we're limited to 256MB actually cpu visible anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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 B49A8C432BE for ; Tue, 31 Aug 2021 19:05:03 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3EDE261041 for ; Tue, 31 Aug 2021 19:05:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3EDE261041 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5B6146E051; Tue, 31 Aug 2021 19:05:02 +0000 (UTC) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12E716E051 for ; Tue, 31 Aug 2021 19:05:01 +0000 (UTC) Received: by mail-oi1-x22a.google.com with SMTP id 6so443719oiy.8 for ; Tue, 31 Aug 2021 12:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZvHe6WFLlEOY+cnNyJHf8IUGJZtLzfrewOzKEL/ktBI=; b=ACWt0ukBTDTGH9DZcqNb3LHML6ZIXTJi22x9F1+NGl+2yrk61J+GgzScyE3gFTlSlQ x226k4VgR+xl+Mxu1P2nWpexNXNlNb1LiuVItVK2b3hkNGxNhP3j+ea03k66KOk1vptW JM2F8HfiCiSzN9m0fQJeZ3AwirWfftjNbongs= 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=ZvHe6WFLlEOY+cnNyJHf8IUGJZtLzfrewOzKEL/ktBI=; b=Izzc9pyQSG0QBuTk6N0+f8YawRuyiLyB8J4zKEjtjUkB0wCP0T0T5A1vO2AS3m1TtI fPKnwzNaZxhOeU7GZlrr21IRTnNu5cNmRqX8RnA34oixpgp4MyaW6KbQoBHM92uTUDNS Btwc4EOXuazTvC+r0yoNjjjmDJc/SRXqLiU1JQdz2eiA9+ZBJe44Kiwt1KUUYDdbyh1S tC3P678oNqysFJm7UwdlgZbjmEfhFuqxy3cJ2x28N5Br2NTUfEr/RRuyyDbSt1YNl1YP mqf/dvlhW1RZB5XvCsa6ipp15J60wtoMsdm4qoMlbA3Ew2UmNmEhE1zPBhWkq469dGXp Tzaw== X-Gm-Message-State: AOAM531TWYwPMx/XsWfjPBvMTiN+tSkzf8i6cGo2R8zGMuDcKOZj6/qP MF7NXLx3lFq6CgDi/z1n5CjRwTLcMoT97ra67Cr9Jw== X-Google-Smtp-Source: ABdhPJzuNvtIttTsikeJhpfgPjZLhIkRqb9ifqIW1nYLm/S07/enaQExtksB0ZnMvf3m4HMYN91Gb9HNmjtQutiTXpc= X-Received: by 2002:a05:6808:1449:: with SMTP id x9mr4264801oiv.14.1630436700262; Tue, 31 Aug 2021 12:05:00 -0700 (PDT) MIME-Version: 1.0 References: <000000000000815b9605c70e74f8@google.com> <131b24e5-ee31-6f7b-42b4-c34583711913@infradead.org> <2fccb5d3-191c-924e-159f-1c9d423e282f@i-love.sakura.ne.jp> <339bfb21-8e80-c7d9-46dd-c416f87c50c0@infradead.org> <535e404d-03bf-8e7a-b296-132a2a98c599@i-love.sakura.ne.jp> <5c6d2b95-31d7-0d59-5e62-2593d9a0e1fe@i-love.sakura.ne.jp> In-Reply-To: From: Daniel Vetter Date: Tue, 31 Aug 2021 21:04:48 +0200 Message-ID: Subject: Re: [PATCH] fbmem: don't allow too huge resolutions To: Geert Uytterhoeven Cc: Tetsuo Handa , syzbot , Andrew Morton , Bartlomiej Zolnierkiewicz , Colin King , DRI Development , Linux Fbdev development list , Linux Kernel Mailing List , Masahiro Yamada , syzkaller-bugs , Randy Dunlap Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Aug 31, 2021 at 8:56 PM Geert Uytterhoeven wrote: > > Hi Daniel, > > On Tue, Aug 31, 2021 at 8:53 PM Daniel Vetter wrote: > > On Tue, Aug 31, 2021 at 7:19 PM Geert Uytterhoeven wrote: > > > On Tue, Aug 31, 2021 at 5:24 PM Tetsuo Handa > > > wrote: > > > > On 2021/08/31 15:48, Geert Uytterhoeven wrote: > > > > > Furthermore, this restricts the virtual frame buffer size on 64-bit, > > > > > too, while graphics cards can have much more than 4 GiB of RAM. > > > > > > > > Excuse me, but do you mean that some hardware allows allocating more than > > > > UINT_MAX bytes of memory for kernel frame buffer drivers? > > > > > > While smem_len is u32 (there have been complaints about such > > > limitations on 64-bit platforms as far as 10 years ago), I see no > > > reason why a graphics card with more than 4 GiB of RAM would not be > > > able to provide a very large virtual screen. > > > > > > Of course e.g. vga16fb cannot, as it is limited to 64 KiB. > > > > The first gpus with 4GB or more memory started shipping in 2012. We're > > not going to have fbdev drivers for these, so let's not invent code > > for use-cases that aren't please. > > This code path is used with fbdev emulation for drm drivers, too, > right? Yeah, you get one buffer, with overallocating 2. That's all, you don't get the entire vram because we can't revoke that for fbdev users. We'd have fixed this long ago if it's a real limitations. 8k at 64bpp is still less than 256MB. Also due to pci bar limitations (which finally get lifted now because windows fixed their pci code, which motivates motherboard manufactures for desktop space to also fix theirs) we're limited to 256MB actually cpu visible anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch