<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/tty, branch v3.18.51</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.51</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.51'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-04-30T03:49:16Z</updated>
<entry>
<title>tty: nozomi: avoid a harmless gcc warning</title>
<updated>2017-04-30T03:49:16Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-01-25T21:54:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c59bad247c60bb54c09c771ef06ba7a434bff7be'/>
<id>urn:sha1:c59bad247c60bb54c09c771ef06ba7a434bff7be</id>
<content type='text'>
commit a4f642a8a3c2838ad09fe8313d45db46600e1478 upstream.

The nozomi wireless data driver has its own helper function to
transfer data from a FIFO, doing an extra byte swap on big-endian
architectures, presumably to bring the data back into byte-serial
order after readw() or readl() perform their implicit byteswap.

This helper function is used in the receive_data() function to
first read the length into a 32-bit variable, which causes
a compile-time warning:

drivers/tty/nozomi.c: In function 'receive_data':
drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]

The problem is that gcc is unsure whether the data was actually
read or not. We know that it is at this point, so we can replace
it with a single readl() to shut up that warning.

I am leaving the byteswap in there, to preserve the existing
behavior, even though this seems fishy: Reading the length of
the data into a cpu-endian variable should normally not use
a second byteswap on big-endian systems, unless the hardware
is aware of the CPU endianess.

There appears to be a lot more confusion about endianess in this
driver, so it probably has not worked on big-endian systems in
a long time, if ever, and I have no way to test it. It's well
possible that this driver has not been used by anyone in a while,
the last patch that looks like it was tested on the hardware is
from 2008.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: 8250_pci: Detach low-level driver during PCI error recovery</title>
<updated>2017-04-22T05:15:06Z</updated>
<author>
<name>Gabriel Krisman Bertazi</name>
<email>krisman@linux.vnet.ibm.com</email>
</author>
<published>2016-11-28T21:34:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c7293aedb4990eef20cdf74c5b51b6f351ddf025'/>
<id>urn:sha1:c7293aedb4990eef20cdf74c5b51b6f351ddf025</id>
<content type='text'>
commit f209fa03fc9d131b3108c2e4936181eabab87416 upstream.

During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed.  Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device.  Those end up
racing with the EEH recovery, crashing it.  Similar races were also
observed when opening the device and when shutting it down during
recovery.

This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards.  Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery.  This is similar to the solution used by the JSM serial
driver.

I thank Peter Hurley &lt;peter@hurleysoftware.com&gt; for valuable input on
this one over one year ago.

Signed-off-by: Gabriel Krisman Bertazi &lt;krisman@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty/serial: atmel: fix race condition (TX+DMA)</title>
<updated>2017-04-22T05:15:01Z</updated>
<author>
<name>Richard Genoud</name>
<email>richard.genoud@gmail.com</email>
</author>
<published>2017-03-20T10:52:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=de3596d3a3ea0cbb9ddd85a7491e766582b1dacc'/>
<id>urn:sha1:de3596d3a3ea0cbb9ddd85a7491e766582b1dacc</id>
<content type='text'>
commit 31ca2c63fdc0aee725cbd4f207c1256f5deaabde upstream.

If uart_flush_buffer() is called between atmel_tx_dma() and
atmel_complete_tx_dma(), the circular buffer has been cleared, but not
atmel_port-&gt;tx_len.
That leads to a circular buffer overflow (dumping (UART_XMIT_SIZE -
atmel_port-&gt;tx_len) bytes).

Tested-by: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Signed-off-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cards</title>
<updated>2017-04-18T05:55:49Z</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2017-02-03T20:25:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f98482143a7bc0eb35ce7d46e5b783a14c707a40'/>
<id>urn:sha1:f98482143a7bc0eb35ce7d46e5b783a14c707a40</id>
<content type='text'>
commit 1c9c858e2ff8ae8024a3d75d2ed080063af43754 upstream.

The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta
Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports,
respectively.  The first 4 ports are implemented by an OX16PCI954 chip,
and the second 4 ports are implemented by an OX16C954 chip on a local
bus, bridged by the second PCI function of the OX16PCI954.  The ports
are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a
non-standard oscillator frequency of 20 MHz (base_baud = 1250000).

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: n_hdlc: get rid of racy n_hdlc.tbuf</title>
<updated>2017-04-18T05:55:48Z</updated>
<author>
<name>Alexander Popov</name>
<email>alex.popov@linux.com</email>
</author>
<published>2017-02-28T16:54:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=477f7e81b30f70d45659c2c6e6aef4f79fbd15b7'/>
<id>urn:sha1:477f7e81b30f70d45659c2c6e6aef4f79fbd15b7</id>
<content type='text'>
commit 82f2341c94d270421f383641b7cd670e474db56b upstream.

Currently N_HDLC line discipline uses a self-made singly linked list for
data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
an error.

The commit be10eb7589337e5defbe214dae038a53dd21add8
("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
one data buffer to tx_free_buf_list twice. That causes double free in
n_hdlc_release().

Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
in case of tx error put current data buffer after the head of tx_buf_list.

Signed-off-by: Alexander Popov &lt;alex.popov@linux.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>TTY: n_hdlc, fix lockdep false positive</title>
<updated>2017-04-18T05:55:48Z</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2015-11-26T18:28:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7ad02ff185daef1281213f7cdba8a29f59ca5b1a'/>
<id>urn:sha1:7ad02ff185daef1281213f7cdba8a29f59ca5b1a</id>
<content type='text'>
commit e9b736d88af1a143530565929390cadf036dc799 upstream.

The class of 4 n_hdls buf locks is the same because a single function
n_hdlc_buf_list_init is used to init all the locks. But since
flush_tx_queue takes n_hdlc-&gt;tx_buf_list.spinlock and then calls
n_hdlc_buf_put which takes n_hdlc-&gt;tx_free_buf_list.spinlock, lockdep
emits a warning:
=============================================
[ INFO: possible recursive locking detected ]
4.3.0-25.g91e30a7-default #1 Not tainted
---------------------------------------------
a.out/1248 is trying to acquire lock:
 (&amp;(&amp;list-&gt;spinlock)-&gt;rlock){......}, at: [&lt;ffffffffa01fd020&gt;] n_hdlc_buf_put+0x20/0x60 [n_hdlc]

but task is already holding lock:
 (&amp;(&amp;list-&gt;spinlock)-&gt;rlock){......}, at: [&lt;ffffffffa01fdc07&gt;] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&amp;(&amp;list-&gt;spinlock)-&gt;rlock);
  lock(&amp;(&amp;list-&gt;spinlock)-&gt;rlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by a.out/1248:
 #0:  (&amp;tty-&gt;ldisc_sem){++++++}, at: [&lt;ffffffff814c9eb0&gt;] tty_ldisc_ref_wait+0x20/0x50
 #1:  (&amp;(&amp;list-&gt;spinlock)-&gt;rlock){......}, at: [&lt;ffffffffa01fdc07&gt;] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
...
Call Trace:
...
 [&lt;ffffffff81738fd0&gt;] _raw_spin_lock_irqsave+0x50/0x70
 [&lt;ffffffffa01fd020&gt;] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
 [&lt;ffffffffa01fdc24&gt;] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc]
 [&lt;ffffffff814c25c1&gt;] tty_ioctl+0x3f1/0xe40
...

Fix it by initializing the spin_locks separately. This removes also
reduntand memset of a freshly kzallocated space.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: vt, fix bogus division in csi_J</title>
<updated>2017-04-18T05:55:45Z</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2016-10-03T09:00:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fd60b9007c0c5b6e7a03116398f4cb885f9b3a91'/>
<id>urn:sha1:fd60b9007c0c5b6e7a03116398f4cb885f9b3a91</id>
<content type='text'>
commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream.

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 &lt;jslaby@suse.cz&gt;
Cc: Petr Písař &lt;ppisar@redhat.com&gt;
Fixes: f8df13e0a9 (tty: Clean console safely)
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vt: clear selection before resizing</title>
<updated>2016-11-24T03:49:36Z</updated>
<author>
<name>Scot Doyle</name>
<email>lkml14@scotdoyle.com</email>
</author>
<published>2016-10-13T17:12:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0b2a0a58ad22f9d6dfc641bc5ec46057493f22a5'/>
<id>urn:sha1:0b2a0a58ad22f9d6dfc641bc5ec46057493f22a5</id>
<content type='text'>
[ Upstream commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 ]

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 &lt;dvyukov@google.com&gt;
Signed-off-by: Scot Doyle &lt;lkml14@scotdoyle.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>tty: limit terminal size to 4M chars</title>
<updated>2016-11-24T03:49:30Z</updated>
<author>
<name>Dmitry Vyukov</name>
<email>dvyukov@google.com</email>
</author>
<published>2016-10-14T13:18:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=78ad6d4ce21be9409c0c5d8ddb9e3833819ee421'/>
<id>urn:sha1:78ad6d4ce21be9409c0c5d8ddb9e3833819ee421</id>
<content type='text'>
[ Upstream commit 32b2921e6a7461fe63b71217067a6cf4bddb132f ]

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 &lt;dvyukov@google.com&gt;
CC: David Rientjes &lt;rientjes@google.com&gt;
Cc: One Thousand Gnomes &lt;gnomes@lxorguk.ukuu.org.uk&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Jiri Slaby &lt;jslaby@suse.com&gt;
Cc: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>serial: samsung: Fix ERR pointer dereference on deferred probe</title>
<updated>2016-08-22T16:23:00Z</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>k.kozlowski@samsung.com</email>
</author>
<published>2016-06-16T06:27:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d918a2e1b06e38855c8ecb15c00f39d6528353e2'/>
<id>urn:sha1:d918a2e1b06e38855c8ecb15c00f39d6528353e2</id>
<content type='text'>
[ Upstream commit e51e4d8a185de90424b03f30181b35f29c46a25a ]

When the clk_get() of "uart" clock returns EPROBE_DEFER, the next re-probe
finishes with success but uses invalid (ERR_PTR) values.  This leads to
dereferencing of ERR_PTR stored under ourport-&gt;clk:

	12c30000.serial: Controller clock not found
	(...)
	12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10
	Unable to handle kernel paging request at virtual address fffffdfb

	(clk_prepare) from [&lt;c039f7d0&gt;] (s3c24xx_serial_pm+0x20/0x128)
	(s3c24xx_serial_pm) from [&lt;c0395414&gt;] (uart_change_pm+0x38/0x40)
	(uart_change_pm) from [&lt;c039689c&gt;] (uart_add_one_port+0x31c/0x44c)
	(uart_add_one_port) from [&lt;c03a035c&gt;] (s3c24xx_serial_probe+0x2a8/0x418)
	(s3c24xx_serial_probe) from [&lt;c03ee110&gt;] (platform_drv_probe+0x50/0xb0)
	(platform_drv_probe) from [&lt;c03ecb44&gt;] (driver_probe_device+0x1f4/0x2b0)
	(driver_probe_device) from [&lt;c03eb0c0&gt;] (bus_for_each_drv+0x44/0x8c)
	(bus_for_each_drv) from [&lt;c03ec8c8&gt;] (__device_attach+0x9c/0x100)
	(__device_attach) from [&lt;c03ebf54&gt;] (bus_probe_device+0x84/0x8c)
	(bus_probe_device) from [&lt;c03ec388&gt;] (deferred_probe_work_func+0x60/0x8c)
	(deferred_probe_work_func) from [&lt;c012fee4&gt;] (process_one_work+0x120/0x328)
	(process_one_work) from [&lt;c0130150&gt;] (worker_thread+0x2c/0x4ac)
	(worker_thread) from [&lt;c0135320&gt;] (kthread+0xd8/0xf4)
	(kthread) from [&lt;c0107978&gt;] (ret_from_fork+0x14/0x3c)

The first unsuccessful clk_get() causes s3c24xx_serial_init_port() to
exit with failure but the s3c24xx_uart_port is left half-configured
(e.g. port-&gt;mapbase is set, clk contains ERR_PTR).  On next re-probe,
the function s3c24xx_serial_init_port() will exit early with success
because of configured port-&gt;mapbase and driver will use old values,
including the ERR_PTR as clock.

Fix this by cleaning the port-&gt;mapbase on error path so each re-probe
will initialize all of the port settings.

Fixes: 60e93575476f ("serial: samsung: enable clock before clearing pending interrupts during init")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Tested-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Tested-by: Kevin Hilman &lt;khilman@baylibre.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
</feed>
