Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2260672pxb; Mon, 12 Apr 2021 19:55:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2rsfSAhg5oaOnKrEGyQQJCKy2zgYoQg8oSNB2nQ9shYAWs58xnaJ++pxb2QVGeuRlc8O+ X-Received: by 2002:a17:906:7257:: with SMTP id n23mr30288594ejk.412.1618282551706; Mon, 12 Apr 2021 19:55:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618282551; cv=none; d=google.com; s=arc-20160816; b=s7KSRWP16uCdTWcz93IGA92MoNK6BBB+Ek1FM29ZZkXbdD+jOgO7/Hfe1qeoDVbVUz E9LezXHdmlnDSUnCJuSirafb8lNVfD1xInVhN4ldyzJ3Y7tGAJEqckq7dA06MAJ7Cemy 3XWE6vcGESDISKCBiqMXomUwSwm3sq2Gl74HvFls+aCZj9CC6bkZtREpLayTWxFT9Xkz mZiH1dhP0r2XJh8cgg0kGbm6P2wfkfh6gbUcVujuTo84TGVHuQwQNLZ6RxXYBWd4kM8o BgQXJVzfVroMnapg71rSjut0CVx+0adyYmRBfgHzkRqBPxAr31flO6ph8n7VxWoS9RiL f9vQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=/aRqk4oa1319OpojSfEU2AIrRzozp0hH8HAxQhBCsi4=; b=AbbEUPiVqTw0ODAAZ+r52hrsUgmChE/FjRI/1H6JC7tzprlcolcTT3QVzYiqGP5r8T lnRKSbqcrZIelOGfDR9E1mUEndGL1J332x9tBkrAwIpFwqdxFZo8wR6ex7jg1FICGmeR a8ZmXNdLC23liuHCOpc2lPnhJUodh7HfSWWY1E7gCqceogbfjX6Erk5hCTzQ7obW6ppj 9zhQ42TyRoEhQcF1uAmm+C9P4yn5du8tLIQ8qHS1fGXFbOPTg12qtLxWshR52kPYD9Hg 4iGbe9VrUn8WsxW7ZzYgBUq4cbYvMl/AQBRI2qIWLQ3MMUhqqVT/Wf47pctop9EzDOpS dgcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zm9si3901967ejb.180.2021.04.12.19.55.28; Mon, 12 Apr 2021 19:55:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241977AbhDLNam (ORCPT + 99 others); Mon, 12 Apr 2021 09:30:42 -0400 Received: from angie.orcam.me.uk ([157.25.102.26]:38766 "EHLO angie.orcam.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241917AbhDLNah (ORCPT ); Mon, 12 Apr 2021 09:30:37 -0400 Received: by angie.orcam.me.uk (Postfix, from userid 500) id 6059092009C; Mon, 12 Apr 2021 15:30:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 5A1BE92009B; Mon, 12 Apr 2021 15:30:16 +0200 (CEST) Date: Mon, 12 Apr 2021 15:30:16 +0200 (CEST) From: "Maciej W. Rozycki" To: Daniel Vetter cc: Linus Torvalds , syzbot , Linux Fbdev development list , Bartlomiej Zolnierkiewicz , Tetsuo Handa , Greg KH , Helge Deller , syzkaller-bugs , Linux Kernel Mailing List , dri-devel , Martin Hostettler , George Kennedy , Jiri Slaby , Peilin Ye Subject: Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE In-Reply-To: Message-ID: References: <000000000000226d3f05b02dd607@google.com> <47907f77-b14b-b433-45c6-a315193f0c1a@i-love.sakura.ne.jp> <494395bc-a7dd-fdb1-8196-a236a266ef54@i-love.sakura.ne.jp> <20200927092701.GA1037755@PWN> <4933b81b-9b1a-355b-df0e-9b31e8280ab9@i-love.sakura.ne.jp> <20200928175956.GF24673@neutronstar.dyndns.org> <100dfd3f-3415-80ae-a6cf-30d15f7ca49f@i-love.sakura.ne.jp> <20200929105203.GG24673@neutronstar.dyndns.org> <20200929165657.GS438822@phenom.ffwll.local> <20200929171040.GB1351851@kroah.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 12 Apr 2021, Daniel Vetter wrote: > > Note that it's entirely possible that things continue to work well > > despite this warning. It's unclear to me from your email if you > > actually see any difference (and apparently you're not able to see it > > right now due to not being close to the machine). > > Original search didn't turn up any users of VT_RESIZEX, this is the > first. And looking at the source code I think we could outright remove > support for VT_RESIZEX (but make it silent) and everything should keep > working: > > /* > * ALWAYS do a VT_RESIZE, even if we already did a VT_RESIZEX > on a 1.3.3 or higher kernel, > * until those kernel programmers make this unambiguous > */ > > if (do_VT_RESIZE(curr_textmode->cols, curr_textmode->rows, > resize1x1)) sresize=TRUE; > > if (check_kernel_version(1,3,3, "VT_RESIZEX")) > { > /* > * VDisplay must de divided by 2 for DoubleScan modes, > * or VT_RESIZEX will fail -- until someone fixes the kernel > * so it understands about doublescan modes. > */ > if (do_VT_RESIZEX(curr_textmode->cols, > curr_textmode->rows, > curr_textmode->VDisplay / > (MOFLG_ISSET(curr_textmode, ATTR_DOUBLESCAN) ? 2 : 1), > curr_textmode->FontHeight, > curr_textmode->HDisplay/8*curr_textmode->FontWidth, > curr_textmode->FontWidth, resize1x1)) sresize=TRUE; > } > > The functions are just straightforward wrappers. There's also no cvs > repo, changelog or old releases before 2000 that would shed some light > on why this code even exists. I did some archaeology then, using a local copy of the linux-mips.org Linux tree that has historic information imported from the old oss.sgi.com MIPS/Linux CVS repo. According to that the ioctl was added with or shortly before 2.1.14: commit beb116954b9b7f3bb56412b2494b562f02b864b1 Author: Ralf Baechle Date: Tue Jan 7 02:33:00 1997 +0000 Import of Linux/MIPS 2.1.14 and, importantly, it was used to set some parameters: if ( vlin ) video_scan_lines = vlin; if ( clin ) video_font_height = clin; used by `con_adjust_height' in drivers/char/vga.c: `video_scan_lines' to set the vertical display limit (so that it is a whole multiple of the new font height) and `video_font_height' to set the cursor scan lines in the CRTC. The function was used by the PIO_FONTX and PIO_FONTRESET VT ioctls at that point. That code was moved to `vgacon_adjust_height' in drivers/video/vgacon.c and then drivers/video/console/vgacon.c. The code is still there, serving the KDFONTOP ioctl. With: commit 9736a3546de7b6a2b16ad93539e4b3ac72b385bb Author: Ralf Baechle Date: Thu Jun 5 10:06:35 2003 +0000 Merge with Linux 2.5.66. the parameters were moved into `struct vc_data': if (vlin) - video_scan_lines = vlin; + vc->vc_scan_lines = vlin; if (clin) - video_font_height = clin; + vc->vc_font.height = clin; and this piece of code to set them only removed with the change discussed here. So without even looking at the VT, which I'll surely get to eventually, I conclude this change regresses font resizing (KD_FONT_OP_SET) once a new resolution has been set with svgatextmode. I think this change needs to be reverted, especially as the problematic PIO_FONT ioctl referred has been since removed with commit ff2047fb755d ("vt: drop old FONT ioctls"). Maciej