linux-dev/drivers/tty/vt, branch master

Merge 6.0-rc4 into tty-next

2022-09-05T05:59:28Z

We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman

tty/vt: Add console_lock check to vt_console_print()

2022-09-01T14:58:08Z

I'm scratching my head why we have this printing_lock. Digging through historical git trees shows that: - Added in 1.1.73, and I found absolutely no reason why. - Converted to atomic bitops in 2.1.125pre2, I guess as part of SMP enabling/bugfixes. - Converted to a proper spinlock in b0940003f25d ("vt: bitlock fix") because the hand-rolled atomic version lacked necessary memory barriers. Digging around in lore for that time period did also not shed further light. The only reason I think this might still be relevant today is that (to my understanding at least, ymmv) during an oops we might be printing without console_lock held. See console_flush_on_panic() and the comments in there - we flush out the console buffers irrespective of whether we managed to acquire the right locks. The strange thing is that this reason is fairly recent, because the console flushing was historically done without oops_in_progress set. This only changed in c7c3f05e341a ("panic: avoid deadlocks in re-entrant console drivers"), which removed the call to bust_spinlocks(0) (which decrements oops_in_progress again) before flushing out the console (which back then was open coded as a console_trylock/unlock pair). Note that this entire mess should be properly fixed in the printk/console layer, and not inflicted on each implementation. For now just document what's going on and check that in all other cases callers obey the locking rules. v2: WARN_CONSOLE_UNLOCKED already checks for oops_in_progress (something else that should be fixed I guess), hence remove the open-coded check I've had. Signed-off-by: Daniel Vetter Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: "Ilpo Järvinen" Cc: Daniel Vetter Cc: Xuezhi Zhang Cc: Yangxi Xiang Cc: Tetsuo Handa Cc: nick black Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: John Ogness Reviewed-by: Sam Ravnborg Link: https://lore.kernel.org/r/20220830144945.430528-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman

kernel/panic: Drop unblank_screen call

2022-09-01T14:55:35Z

console_unblank() does this too (called in both places right after), and with a lot more confidence inspiring approach to locking. Reconstructing this story is very strange: In b61312d353da ("oops handling: ensure that any oops is flushed to the mtdoops console") it is claimed that a printk(" "); flushed out the console buffer, which was removed in e3e8a75d2acf ("[PATCH] Extract and use wake_up_klogd()"). In todays kernels this is done way earlier in console_flush_on_panic with some really nasty tricks. I didn't bother to fully reconstruct this all, least because the call to bust_spinlock(0); gets moved every few years, depending upon how the wind blows (or well, who screamed loudest about the various issue each call site caused). Before that commit the only calls to console_unblank() where in s390 arch code. The other side here is the console->unblank callback, which was introduced in 2.1.31 for the vt driver. Which predates the console_unblank() function by a lot, which was added (without users) in 2.4.14.3. So pretty much impossible to guess at any motivation here. Also afaict the vt driver is the only (and always was the only) console driver implementing the unblank callback, so no idea why a call to console_unblank() was added for the mtdooops driver - the action actually flushing out the console buffers is done from console_unlock() only. Note that as prep for the s390 users the locking was adjusted in 2.5.22 (I couldn't figure out how to properly reference the BK commit from the historical git trees) from a normal semaphore to a trylock. Note that a copy of the direct unblank_screen() call was added to panic() in c7c3f05e341a ("panic: avoid deadlocks in re-entrant console drivers"), which partially inlined the bust_spinlocks(0); call. Long story short, I have no idea why the direct call to unblank_screen survived for so long (the infrastructure to do it properly existed for years), nor why it wasn't removed when the console_unblank() call was finally added. But it makes a ton more sense to finally do that than not - it's just better encapsulation to go through the console functions instead of doing a direct call, so let's dare. Plus it really does not make much sense to call the only unblank implementation there is twice, once without, and once with appropriate locking. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Daniel Vetter Cc: "Ilpo Järvinen" Cc: Tetsuo Handa Cc: Xuezhi Zhang Cc: Yangxi Xiang Cc: nick black Cc: Petr Mladek Cc: Andrew Morton Cc: Luis Chamberlain Cc: "Guilherme G. Piccoli" Cc: Marco Elver Cc: John Ogness Cc: Sebastian Andrzej Siewior Cc: David Gow Cc: tangmeng Cc: Tiezhu Yang Cc: Chris Wilson Reviewed-by: Petr Mladek Acked-by: Sebastian Andrzej Siewior Signed-off-by: Daniel Vetter Signed-off-by: Andrew Morton Link: https://lore.kernel.org/r/20220830145004.430545-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman

vt: Clear selection before changing the font

2022-08-30T12:30:52Z

When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-of-bounds accesses to graphics memory if the selection is removed in vc_do_resize(). Prevent such out-of-memory accesses by dropping the selection before the various con_font_set() console handlers are called. Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com Cc: stable Tested-by: Khalid Masum Signed-off-by: Helge Deller Link: https://lore.kernel.org/r/YuV9apZGNmGfjcor@p100 Signed-off-by: Greg Kroah-Hartman

tty/vt: Remove printable variable

2022-08-30T12:15:57Z

Every since the 0.99.7A release when console_register() was introduced it's become impossible to call vt_console_print (called console_print() back then still) directly. Which means the initialization issue this variable protected against is no more. Give it a send off with style and let it rest in peace. Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: "Ilpo Järvinen" Cc: nick black Cc: Daniel Vetter Cc: Tetsuo Handa Cc: Yangxi Xiang Cc: Xuezhi Zhang Reviewed-by: Jiri Slaby Signed-off-by: Daniel Vetter Link: https://lore.kernel.org/r/20220826202419.198535-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman

Merge tag 'tty-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2022-08-08T18:31:40Z

Pull tty / serial driver updates from Greg KH: "Here is the big set of tty and serial driver changes for 6.0-rc1. It was delayed from last week as I wanted to make sure the last commit here got some good testing in linux-next and elsewhere as it seemed to show up only late in testing for some reason. Nothing major here, just lots of cleanups from Jiri and Ilpo to make the tty core cleaner (Jiri) and the rs485 code simpler to use (Ilpo). Also included in here is the obligatory n_gsm updates from Daniel Starke and lots of tiny driver updates and minor fixes and tweaks for other smaller serial drivers. All of these have been in linux-next for a while with no reported problems" * tag 'tty-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (186 commits) tty: serial: qcom-geni-serial: Fix %lu -> %u in print statements tty: amiserial: Fix comment typo tty: serial: document uart_get_console() tty: serial: serial_core, reformat kernel-doc for functions Documentation: serial: link uart_ops properly Documentation: serial: move GPIO kernel-doc to the functions Documentation: serial: dedup kernel-doc for uart functions Documentation: serial: move uart_ops documentation to the struct dt-bindings: serial: snps-dw-apb-uart: Document Rockchip RV1126 serial: mvebu-uart: uart2 error bits clearing tty: serial: fsl_lpuart: correct the count of break characters serial: stm32: make info structs static to avoid sparse warnings serial: fsl_lpuart: zero out parity bit in CS7 mode tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate. serial: 8250_bcm2835aux: Add missing clk_disable_unprepare() tty: vt: initialize unicode screen buffer serial: remove VR41XX serial driver serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags serial: 8250_dwlib: remove redundant sanity check for RS485 flags dt_bindings: rs485: Correct delay values ...

tty: vt: initialize unicode screen buffer

2022-07-19T12:18:27Z

syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read immediately after resize operation. Initialize buffer using kzalloc(). ---------- #include #include #include #include int main(int argc, char *argv[]) { struct fb_var_screeninfo var = { }; const int fb_fd = open("/dev/fb0", 3); ioctl(fb_fd, FBIOGET_VSCREENINFO, &var); var.yres = 0x21; ioctl(fb_fd, FBIOPUT_VSCREENINFO, &var); return read(open("/dev/vcsu", O_RDONLY), &var, sizeof(var)) == -1; } ---------- Link: https://syzkaller.appspot.com/bug?extid=31a641689d43387f05d3 [1] Cc: stable Reported-by: syzbot Reviewed-by: Jiri Slaby Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/4ef053cf-e796-fb5e-58b7-3ae58242a4ad@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman

vt: fix memory overlapping when deleting chars in the buffer

2022-06-30T15:17:40Z

A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. Fixes: 81732c3b2fed ("tty vt: Fix line garbage in virtual console on command line edition") Cc: stable Signed-off-by: Yangxi Xiang Link: https://lore.kernel.org/r/20220628093322.5688-1-xyangxi5@gmail.com Signed-off-by: Greg Kroah-Hartman

tty/vt: consolemap: use E_TABSZ for the translations size

2022-06-27T12:17:12Z

The code expects "translations" to have 256 (E_TABSZ) values. Use the macro instead of the constant to be explicit about this. Suggested-by: Ilpo Järvinen Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220614090537.15557-8-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman

tty/vt: consolemap: remove dflt reset from con_do_clear_unimap()

2022-06-27T12:17:12Z

con_do_clear_unimap() sets dflt to NULL and then calls con_release_unimap() which does the very same as the first thing. So remove the former as it is apparently superfluous. Suggested-by: Ilpo Järvinen Reviewed-by: Ilpo Järvinen Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220614090537.15557-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman