09 Jan, 2017
1 commit
-
commit 31b5929d533f5183972cf57a7844b456ed996f3c upstream.
There is a disagreement between drivers/tty/vt/keyboard.c and
drivers/input/input-leds.c with regard to what is a Scroll Lock LED
trigger name: input calls it "kbd-scrolllock", but vt calls it
"kbd-scrollock" (two l's).
This prevents Scroll Lock LED trigger from binding to this LED by default.Since it is a scroLL Lock LED, this interface was introduced only about a
year ago and in an Internet search people seem to reference this trigger
only to set it to this LED let's simply rename it to "kbd-scrolllock".Also, it looks like this was supposed to be changed before this code was
merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
the input side.Signed-off-by: Maciej S. Szmigiero
Acked-by: Samuel Thibault
Signed-off-by: Greg Kroah-Hartman
27 Oct, 2016
3 commits
-
When resizing a vt its selection may exceed the new size, resulting in
an invalid memory access [1]. Clear the selection before resizing.[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com
Reported-and-tested-by: Dmitry Vyukov
Signed-off-by: Scot Doyle
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
Size of kmalloc() in vc_do_resize() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Put a reasonable upper bound on terminal size to prevent WARNINGs.Signed-off-by: Dmitry Vyukov
CC: David Rientjes
Cc: One Thousand Gnomes
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Peter Hurley
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is
divided by 2 inappropriatelly. But scr_memsetw expects size, not
count, because it divides the size by 2 on its own before doing actual
memset-by-words.So remove the bogus division.
Signed-off-by: Jiri Slaby
Cc: Petr Písař
Fixes: f8df13e0a9 (tty: Clean console safely)
Signed-off-by: Greg Kroah-Hartman
11 Oct, 2016
1 commit
-
Merge my system logging cleanups, triggered by the broken '\n' patches.
The line continuation handling has been broken basically forever, and
the code to handle the system log records was both confusing and
dubious. And it would do entirely the wrong thing unless you always had
a terminating newline, partly because it couldn't actually see whether a
message was marked KERN_CONT or not (but partly because the LOG_CONT
handling in the recording code was rather confusing too).This re-introduces a real semantically meaningful KERN_CONT, and fixes
the few places I noticed where it was missing. There are probably more
missing cases, since KERN_CONT hasn't actually had any semantic meaning
for at least four years (other than the checkpatch meaning of "no log
level necessary, this is a continuation line").This also allows the combination of KERN_CONT and a log level. In that
case the log level will be ignored if the merging with a previous line
is successful, but if a new record is needed, that new record will now
get the right log level.That also means that you can at least in theory combine KERN_CONT with
the "pr_info()" style helpers, although any use of pr_fmt() prefixing
would make that just result in a mess, of course (the prefix would end
up in the middle of a continuing line).* printk-cleanups:
printk: make reading the kernel log flush pending lines
printk: re-organize log_output() to be more legible
printk: split out core logging code into helper function
printk: reinstate KERN_CONT for printing continuation lines
10 Oct, 2016
1 commit
-
Long long ago the kernel log buffer was a buffered stream of bytes, very
much like stdio in user space. It supported log levels by scanning the
stream and noticing the log level markers at the beginning of each line,
but if you wanted to print a partial line in multiple chunks, you just
did multiple printk() calls, and it just automatically worked.Except when it didn't, and you had very confusing output when different
lines got all mixed up with each other. Then you got fragment lines
mixing with each other, or with non-fragment lines, because it was
traditionally impossible to tell whether a printk() call was a
continuation or not.To at least help clarify the issue of continuation lines, we added a
KERN_CONT marker back in 2007 to mark continuation lines:474925277671 ("printk: add KERN_CONT annotation").
That continuation marker was initially an empty string, and didn't
actuall make any semantic difference. But it at least made it possible
to annotate the source code, and have check-patch notice that a printk()
didn't need or want a log level marker, because it was a continuation of
a previous line.To avoid the ambiguity between a continuation line that had that
KERN_CONT marker, and a printk with no level information at all, we then
in 2009 made KERN_CONT be a real log level marker which meant that we
could now reliably tell the difference between the two cases.5fd29d6ccbc9 ("printk: clean up handling of log-levels and newlines")
and we could take advantage of that to make sure we didn't mix up
continuation lines with lines that just didn't have any loglevel at all.Then, in 2012, the kernel log buffer was changed to be a "record" based
log, where each line was a record that has a loglevel and a timestamp.You can see the beginning of that conversion in commits
e11fea92e13f ("kmsg: export printk records to the /dev/kmsg interface")
7ff9554bb578 ("printk: convert byte-buffer to variable-length record buffer")with a number of follow-up commits to fix some painful fallout from that
conversion. Over all, it took a couple of months to sort out most of
it. But the upside was that you could have concurrent readers (and
writers) of the kernel log and not have lines with mixed output in them.And one particular pain-point for the record-based kernel logging was
exactly the fragmentary lines that are generated in smaller chunks. In
order to still log them as one recrod, the continuation lines need to be
attached to the previous record properly.However the explicit continuation record marker that is actually useful
for this exact case was actually removed in aroundm the same time by commit61e99ab8e35a ("printk: remove the now unnecessary "C" annotation for KERN_CONT")
due to the incorrect belief that KERN_CONT wasn't meaningful. The
ambiguity between "is this a continuation line" or "is this a plain
printk with no log level information" was reintroduced, and in fact
became an even bigger pain point because there was now the whole
record-level merging of kernel messages going on.This patch reinstates the KERN_CONT as a real non-empty string marker,
so that the ambiguity is fixed once again.But it's not a plain revert of that original removal: in the four years
since we made KERN_CONT an empty string again, not only has the format
of the log level markers changed, we've also had some usage changes in
this area.For example, some ACPI code seems to use KERN_CONT _together_ with a log
level, and now uses both the KERN_CONT marker and (for example) a
KERN_INFO marker to show that it's an informational continuation of a
line.Which is actually not a bad idea - if the continuation line cannot be
attached to its predecessor, without the log level information we don't
know what log level to assign to it (and we traditionally just assigned
it the default loglevel). So having both a log level and the KERN_CONT
marker is not necessarily a bad idea, but it does mean that we need to
actually iterate over potentially multiple markers, rather than just a
single one.Also, since KERN_CONT was still conceptually needed, and encouraged, but
didn't actually _do_ anything, we've also had the reverse problem:
rather than having too many annotations it has too few, and there is bit
rot with code that no longer marks the continuation lines with the
KERN_CONT marker.So this patch not only re-instates the non-empty KERN_CONT marker, it
also fixes up the cases of bit-rot I noticed in my own logs.There are probably other cases where KERN_CONT will be needed to be
added, either because it is new code that never dealt with the need for
KERN_CONT, or old code that has bitrotted without anybody noticing.That said, we should strive to avoid the need for KERN_CONT. It does
result in real problems for logging, and should generally not be seen as
a good feature. If we some day can get rid of the feature entirely,
because nobody does any fragmented printk calls, that would be lovely.But until that point, let's at mark the code that relies on the hacky
multi-fragment kernel printk's. Not only does it avoid the ambiguity,
it also annotates code as "maybe this would be good to fix some day".(That said, particularly during single-threaded bootup, the downsides of
KERN_CONT are very limited. Things get much hairier when you have
multiple threads going on and user level reading and writing logs too).Signed-off-by: Linus Torvalds
22 Sep, 2016
5 commits
-
For now, these fall back to regular (dark) colors.
It'd be tempting to replace blink with bright backgrounds, as permitted by
CGA/VGA -- we already muck with the other programmable bit (foreground
brightness vs 512 character font). This would bring vgacon in line with
fbcon, which doesn't support blink anywhere but on some drivers renders
that bit as bright background. If that is done, this commit should be
amended to be one of ways of setting that bit.Signed-off-by: Adam Borowski
Signed-off-by: Greg Kroah-Hartman -
These codes are supported by all major terminals, thus they occasionally see
some use despite being redundant with \e[38;5;(x+8)m or (less exactly)
\e[1;3(x)m.Signed-off-by: Adam Borowski
Signed-off-by: Greg Kroah-Hartman -
Some guy went on a patching spree, adding 24-bit colour support all around:
https://gist.github.com/XVilka/8346728Signed-off-by: Adam Borowski
Signed-off-by: Greg Kroah-Hartman -
All other uses of vc_npar are inclusive (save for < NPAR) which raises
eyebrows, so let's at least do so consistently.Signed-off-by: Adam Borowski
Signed-off-by: Greg Kroah-Hartman -
This makes it show up on UBSAN:
perl -e 'for (0..15) {my @x=("0")x$_;push @x,qw(38 2 64 128 192 4);printf
"\e[%smAfter %d zeroes.\e[0m\n", join(";",@x[0..($_+5
Signed-off-by: Greg Kroah-Hartman
25 Jul, 2016
1 commit
-
Pull tty/serial driver updates from Greg KH:
"Here is the big tty and serial driver update for 4.8-rc1.Lots of good cleanups from Jiri on a number of vt and other tty
related things, and the normal driver updates. Full details are in
the shortlog.All of these have been in linux-next for a while with no reported
issues"* tag 'tty-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (90 commits)
tty/serial: atmel: enforce tasklet init and termination sequences
serial: sh-sci: Stop transfers in sci_shutdown()
serial: 8250_ingenic: drop #if conditional surrounding earlycon code
serial: 8250_mtk: drop !defined(MODULE) conditional
serial: 8250_uniphier: drop !defined(MODULE) conditional
earlycon: mark earlycon code as __used iif the caller is built-in
tty/serial/8250: use mctrl_gpio helpers
serial: mctrl_gpio: enable API usage only for initialized mctrl_gpios struct
serial: mctrl_gpio: add modem control read routine
tty/serial/8250: make UART_MCR register access consistent
serial: 8250_mid: Read RX buffer on RX DMA timeout for DNV
serial: 8250_dma: Export serial8250_rx_dma_flush()
dmaengine: hsu: Export hsu_dma_get_status()
tty: serial: 8250: add CON_CONSDEV to flags
tty: serial: samsung: add byte-order aware bit functions
tty: serial: samsung: fixup accessors for endian
serial: sirf: make fifo functions static
serial: mps2-uart: make driver explicitly non-modular
serial: mvebu-uart: free the IRQ in ->shutdown()
serial/bcm63xx_uart: use correct alias naming
...
23 Jul, 2016
1 commit
-
Pull input fixes from Dmitry Torokhov:
"A few more fixes for the input subsystem:- restore naming for tsc2005 touchscreens as some userspace match on it
- fix out of bound access in legacy keyboard driver
- fixup in RMI4 driverEverything is tagged for stable as well"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: tsc200x - report proper input_dev name
tty/vt/keyboard: fix OOB access in do_compute_shiftstate()
Input: synaptics-rmi4 - fix maximum size check for F12 control register 8
21 Jul, 2016
1 commit
-
The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
which is currently 256, whereas number of keys/buttons in input device (and
therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
out-of-bound access when we dosym = U(key_maps[0][k]);
with large 'k'.
To fix it we should not attempt iterating beyond smaller of NR_KEYS and
KEY_CNT.Also while at it let's switch to for_each_set_bit() instead of open-coding
it.Reported-by: Sasha Levin
Reviewed-by: Guenter Roeck
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov
04 Jul, 2016
1 commit
-
We want the tty/serial fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
26 Jun, 2016
14 commits
-
We are getting somewhat random soft lockups with this signature:
[ 86.992215] [] el1_irq+0xa0/0x10c
[ 86.997082] [] cursor_timer_handler+0x30/0x54
[ 87.002991] [] call_timer_fn+0x54/0x1a8
[ 87.008378] [] run_timer_softirq+0x1c4/0x2bc
[ 87.014200] [] __do_softirq+0x114/0x344
[ 87.019590] [] irq_exit+0x74/0x98
[ 87.024458] [] __handle_domain_irq+0x98/0xfc
[ 87.030278] [] gic_handle_irq+0x94/0x190This is caused by the vt visual_init() function calling into
fbcon_init() with a vc_cur_blink_ms value of zero. This is a
transient condition, as it is later set to a non-zero value. But, if
the timer happens to expire while the blink rate is zero, it goes into
an endless loop, and we get soft lockup.The fix is to initialize vc_cur_blink_ms before calling the con_init()
function.Signed-off-by: David Daney
Cc: stable@vger.kernel.org
Acked-by: Pavel Machek
Tested-by: Ming Lei
Acked-by: Scot Doyle
Tested-by: Henrique de Moraes Holschuh
Signed-off-by: Greg Kroah-Hartman -
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.Signed-off-by: Muhammad Falak R Wani
Reviewed-by: Samuel Thibault
Signed-off-by: Greg Kroah-Hartman -
vc_deccolm is only set and never read, remove the member from vc_data.
Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
We do not do hashtables for unicode fonts since 1995 (1.3.28). So it
is time to remove the second parameter of con_clear_unimap and ignore
the advice from userspace completely.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
Namely convert:
* IS_FG -> con_is_fg
* DO_UPDATE -> con_should_update
* CON_IS_VISIBLE -> con_is_visibleDO_UPDATE was a weird name for a yes/no answer, so the new name is
con_should_update.Signed-off-by: Jiri Slaby
Cc: Thomas Winischhofer
Cc: Jean-Christophe Plagniol-Villard
Cc: linux-usb@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
Flush the switch cases to be aligned with the switch. Mostly
everything can now fit to the 80-chars terminal.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
Do not opencode max3, use the macro.
Separate commands. Until now, I have not noticed the comma. Make it
one line, one command. And make the code obvious.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
The compiler noticed passing structure over stack. Even though rgb is
a small structure, let us define one and pass that over all the
functions wherever needed.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
The code with T.416 high colors handling is flushed to the right and
hard to read. Move the code to a separate function and remove code
duplication for foreground & background colors.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
It's a macro accessing and changing some local variables. And the code
uses it without appending semicolon which confuses everybody too.Switch from this bad guy to a sane standard function.
Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
It is never defined. And I spent quite some time looking into the
history and cannot find how this was ever used. Given it was not used
in the history, I doubt it currently works as expected after the years
of changes all over the code.So kill it.
Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
* allow NULL consw->con_set_palette (some consoles define an empty
hook)
* => remove empty hooks now
* return value of consw->con_set_palette is never checked => make the
function void
* document consw->con_set_palette a bitSigned-off-by: Jiri Slaby
Cc: Thomas Winischhofer
Cc: linux-usb@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-fbdev@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
* allow NULL consw->con_scrolldelta (some consoles define an empty
hook)
* => remove empty hooks now
* return value of consw->con_scrolldelta is never checked => make the
function void
* document consw->con_scrolldelta a bitSigned-off-by: Jiri Slaby
Cc: Thomas Winischhofer
Cc: linux-usb@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-fbdev@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
It is always called with 0, so remove the parameter and pass the
default down to scrolldelta without checking.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
04 May, 2016
2 commits
-
When the console is already registered, stop crawling the
registered_con_driver array and return an error immediatelly.This makes the code more obvious. And we do not need to initialize
retval anymore.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
When csw->con_startup() fails in do_register_con_driver, we return no
error (i.e. 0). This was changed back in 2006 by commit 3e795de763.
Before that we used to return -ENODEV.So fix the return value to be -ENODEV in that case again.
Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT console")
Signed-off-by: Jiri Slaby
Reported-by: "Dan Carpenter"
Signed-off-by: Greg Kroah-Hartman
01 May, 2016
5 commits
-
Every user of default_red, default_grn, and default_blu treats them as
unsigned char. So make it really unsigned char.And indent the initializers and module_param properly.
This saves ~ 100 bytes of data.
Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
This means all ->con_set_palette have to have the second parameter
const too now.Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
Some code in vc_allocate is indented by 4 spaces. It is inside a
condition. Invert the condition and move the code to the first
indentation level (using \tab). And insert some empty lines to have
logical code blocks separated.Then, instead of freeing in an 'if' false branch, use goto-error
label as fail path.Maybe better to look at this patch with diff -w -b.
Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
MAX_NR_CONSOLES and MAX_NR_USER_CONSOLES are both 63 since they were
introduced in 1.1.54. And since vc_allocate does:if (currcons >= MAX_NR_CONSOLES)
return -ENXIO;if (!vc_cons[currcons].d) {
if (currcons >= MAX_NR_USER_CONSOLES && !capable(CAP_SYS_RESOURCE))
return -EPERM;
}the second check is pointless. Remove both the check and the macro
MAX_NR_USER_CONSOLES.Signed-off-by: Jiri Slaby
Reported-by: Fugang Duan
Signed-off-by: Greg Kroah-Hartman -
Abstract TTY_THROTTLED bit tests with tty_throttled().
Signed-off-by: Peter Hurley
Signed-off-by: Greg Kroah-Hartman
07 Feb, 2016
2 commits
-
add_softcursor() stores the contents of the text buffer position in this
variable before drawing the softcursor, whereas hide_softcursor() writes
the value back. A value of -1 means that no cursor has been drawn and
therefore no character is to be restored. softcursor_original, however,
is only implicitly initialized with 0. Therefore, when hide_softcursor
is called for the first time (console_init -> con_init -> redraw_screen
-> hide_cursor), it wrongly writes 0x0000 in the top left corner of
the text buffer. Normally, this is just as black as the rest of the
screen (vc_video_erase_char) and can't be seen, but it appears as a
black cursor rectangle on non-black backgrounds e.g. with boot option
"vt.global_cursor_default=0 vt.color=0xf0". softcursor_original needs
to be initialized with -1.Signed-off-by: Melchior FRANZ
Signed-off-by: Greg Kroah-Hartman -
use memdup_user rather than duplicating implementation.
found by coccinelleSigned-off-by: Saurabh Sengar
Signed-off-by: Greg Kroah-Hartman
02 Feb, 2016
1 commit
-
We want the tty/serial fixes in here as well to make merges easier.
Signed-off-by: Greg Kroah-Hartman
01 Feb, 2016
1 commit
-
Pull staging fixes from Greg KH:
"Here are some small staging driver fixes for 4.5-rc2.One of them predated 4.4-final, but I missed that merge window due to
the holliday. The others fix reported issues that have come up
recently. The tty change is needed for the speakup driver fix and has
the ack of the tty driver maintainer as well, i.e. myself :)All have been in linux-next with no reported issues"
* tag 'staging-4.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
Staging: speakup: fix read scrolled-back VT
Staging: speakup: Fix getting port information
Revert "Staging: panel: usleep_range is preferred over udelay"
iio: adis_buffer: Fix out-of-bounds memory access