Forums before death by AOL, social media and spammers... "We can't have nice things"
|    linux.debian.kernel    |    Debian kernel discussions    |    2,884 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,480 of 2,884    |
|    Greg Kroah-Hartman to Barry K. Nathan    |
|    Bug#1123750: [5.10] regression: virtual     |
|    28 Jan 26 15:30:01    |
   
   XPost: linux.debian.bugs.dist   
   From: gregkh@linuxfoundation.org   
      
   On Thu, Jan 15, 2026 at 12:41:10AM -0800, Barry K. Nathan wrote:   
   > On 1/8/26 5:23 AM, Greg Kroah-Hartman wrote:   
   > > On Fri, Jan 02, 2026 at 05:26:22PM +0100, Ben Hutchings wrote:   
   > > > Hello stable maintainers,   
   > > >   
   > > > Several Debian users reported a regression after updating to kernel   
   > > > version 5.10.247.   
   > > >   
   > > > Commit f0982400648a ("fbdev: Add bounds checking in bit_putcs to fix   
   > > > vmalloc-out-of-bounds"), a backport of upstream commit 3637d34b35b2,   
   > > > depends on vc_data::vc_font.charcount being initialised correctly.   
   > > >   
   > > > However, before commit a1ac250a82a5 ("fbcon: Avoid using FNTCHARCNT()   
   > > > and hard-coded built-in font charcount") in 5.11, this member was set   
   > > > to 256 for VTs initially created with a built-in font and 0 for VTs   
   > > > initially created with a user font.   
   > > >   
   > > > Since Debian normally sets a user font before creating VTs 2 and up,   
   > > > those additional VTs became unusable. VT 1 also doesn't work correctly   
   > > > if the user font has > 256 characters, and the bounds check is   
   > > > ineffective if it has < 256 characters.   
   > > >   
   > > > This can be fixed by backporting the following commits from 5.11:   
   > > >   
   > > > 7a089ec7d77f console: Delete unused con_font_copy() callback   
   implementations   
   > > > 259a252c1f4e console: Delete dummy con_font_set() and con_font_default()   
   callback implementations   
   > > > 4ee573086bd8 Fonts: Add charcount field to font_desc   
   > > > 4497364e5f61 parisc/sticore: Avoid hard-coding built-in font charcount   
   > > > a1ac250a82a5 fbcon: Avoid using FNTCHARCNT() and hard-coded built-in   
   font charcount   
   > > >   
   > > > These all apply without fuzz and builds cleanly for x86_64 and parisc64.   
   > > >   
   > > > I tested on x86_64 that:   
   > > >   
   > > > - VT 2 works again   
   > > > - bit_putcs_aligned() is setting charcnt = 256   
   > > > - After loading a font with 512 characters, bit_putcs_aligned() sets   
   > > > charcnt = 512 and is able to display characters at positions >= 256   
   > >   
   > > All now queued up, thanks!   
   > >   
   > > greg k-h   
   >   
   > For what it's worth, now that the above commits are queued up for 5.10.y:   
   > There are two more commits, which were previously applied to 5.15.y, that   
   > now apply to 5.10.y without merge conflicts (also without fuzz, if you apply   
   > the 5.15.y versions of the patches):   
   >   
   >   
   > a5a923038d70   
   > fbdev: fbcon: Properly revert changes when vc_resize() failed   
   > (previously applied to 5.15.64 and 5.19.6)   
   >   
   > 3c3bfb8586f8   
   > fbdev: fbcon: release buffer when fbcon_do_set_font() failed   
   > (previously applied to 5.15.86, 6.0.16, and 6.1.2)   
   >   
   >   
   > After looking at these two commits, it seems to me that they are now   
   > applicable to 5.10.y, and I think they probably should be applied (unless   
   > I'm overlooking or missing something).   
      
   Both now applied, thanks!   
      
   greg k-h   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca