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 377E2C4320A for ; Tue, 31 Aug 2021 18:53:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 17E3361075 for ; Tue, 31 Aug 2021 18:53:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238688AbhHaSya (ORCPT ); Tue, 31 Aug 2021 14:54:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236898AbhHaSy2 (ORCPT ); Tue, 31 Aug 2021 14:54:28 -0400 Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A4EAC061760 for ; Tue, 31 Aug 2021 11:53:33 -0700 (PDT) Received: by mail-oo1-xc34.google.com with SMTP id k20-20020a4ad114000000b0029133123994so51400oor.4 for ; Tue, 31 Aug 2021 11:53:33 -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=K3WeVuI2Ie18d37UDwbFXiRTN6XtflUPlbndkkdnihc=; b=Fw6KBtGLD/jWglWRhsR/o4BZqgoEc6axGzFW2v+o9w0LIHT39bt8YL7h3Tz9WrzHj5 wuClhCt0Mzh//bdKhWPGY4xZ9lq2K6S68RrqL+OGdRWe+DbyoWNmBh4Ld1LF03AkCDkh 5eJBtcldjtHzWuPfbKf8QouJRnOZuVyzn3Dbw= 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=K3WeVuI2Ie18d37UDwbFXiRTN6XtflUPlbndkkdnihc=; b=AdcyR79IQ5GiJdV+45NXXsfx7zz66rVnCXod/1DBCwb/h61aJ3VktoNYo3/fVAtxrw NEW3WEOfiZ1J2rmkodxrY0KcD/WB0LrOZHQBnfWVSR+LW3hgbs14XjwZ3kZ9gfu0oNoN 4bT4nBh5UYJNoF0eOCtiZ9UIQyJ+7X0/BIEPuzBP3VK4XkMLBbKzPc0D69ImqtfDh4/E 2nRBfuz8PaClpkXSpOiBlVoE9Z6AvOZSspMu7G0U9EyB/nTDg6NxfAfB5F+7NuTrNy+5 bepo98PH3MIaK+h09TMhndDBaqAAAzyRKGqGTqix8MdW2yF5r+fcV3c2HTo3NaqP6cTt 3RWA== X-Gm-Message-State: AOAM533pW3Jpy0viX/kX/YEYUixBZFMS8QPIAYCjpDuOrx9q7lnmN+nD 0BXtNm8wxbkGK/X/BLSlZEId1fradgcbLDYaj8dkaQ== X-Google-Smtp-Source: ABdhPJyxNK7E5I3v65z4yphp0rFW9SBfjaG5Qv+6XKkbHiElJJdCebdvqr57TPyZWckcm3owXCsKyPmjeB6gUqbBBbg= X-Received: by 2002:a4a:2549:: with SMTP id v9mr15539279ooe.28.1630436012777; Tue, 31 Aug 2021 11:53:32 -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 20:53:21 +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 7:19 PM Geert Uytterhoeven wrote: > > Hi Handa-san, > > 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. Thanks, 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 4D281C4320E for ; Tue, 31 Aug 2021 18:53:36 +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 AEB0F6108B for ; Tue, 31 Aug 2021 18:53:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AEB0F6108B 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 D9E5189568; Tue, 31 Aug 2021 18:53:34 +0000 (UTC) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7DD1C89568 for ; Tue, 31 Aug 2021 18:53:33 +0000 (UTC) Received: by mail-oo1-xc33.google.com with SMTP id z1-20020a4a2241000000b0028e8dfb83b4so35078ooe.13 for ; Tue, 31 Aug 2021 11:53:33 -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=K3WeVuI2Ie18d37UDwbFXiRTN6XtflUPlbndkkdnihc=; b=Fw6KBtGLD/jWglWRhsR/o4BZqgoEc6axGzFW2v+o9w0LIHT39bt8YL7h3Tz9WrzHj5 wuClhCt0Mzh//bdKhWPGY4xZ9lq2K6S68RrqL+OGdRWe+DbyoWNmBh4Ld1LF03AkCDkh 5eJBtcldjtHzWuPfbKf8QouJRnOZuVyzn3Dbw= 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=K3WeVuI2Ie18d37UDwbFXiRTN6XtflUPlbndkkdnihc=; b=phFNtcz0jlNXgBlK84yZVCPkK1/1Unt0ZkC1EBb6boM+q04sNKg/QW7TLPqVBU4oms 0XYDmiR2qe8AWRBkJUbmSWaRk/Y8MzW53tg6Fu/TfG/bSW/SAdMw8UkLGwUx/r1hM9wv VTpLUUcpUvY567DqujwdKXqOpio5juIkcc0/Fj7JUQXocZYCOPNDxcs8zsJbacY45K+E B3TQ65imXAs3dk0k3mI66gdm5fEoGkYqnL1bOG73mkBPrv9ln1c1vZedXzORSeXHbzmd 1nXET2inEHyb2ya34YeUxNScZLGjggSF9dMXC4bEpfJcSOLS+Cbf28UktDJ2XijKVHBA f4LQ== X-Gm-Message-State: AOAM530eiwkOnn1bTuVhB2zcWNjoAqMotgawSaLdD8Rv8iDKmp6tNXcp bJvjoONw9zPQ5f4UO/rim3mcdHgDBXuEqpPe4OQD+A== X-Google-Smtp-Source: ABdhPJyxNK7E5I3v65z4yphp0rFW9SBfjaG5Qv+6XKkbHiElJJdCebdvqr57TPyZWckcm3owXCsKyPmjeB6gUqbBBbg= X-Received: by 2002:a4a:2549:: with SMTP id v9mr15539279ooe.28.1630436012777; Tue, 31 Aug 2021 11:53:32 -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 20:53:21 +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 7:19 PM Geert Uytterhoeven wrote: > > Hi Handa-san, > > 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. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch