#
95713967 |
|
10-Aug-2023 |
Jiri Slaby (SUSE) <jirislaby@kernel.org> |
tty: make tty_operations::write()'s count size_t Unify with the rest of the code. Use size_t for counts and ssize_t for retval. Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230810091510.13006-30-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
69851e4a |
|
10-Aug-2023 |
Jiri Slaby (SUSE) <jirislaby@kernel.org> |
tty: propagate u8 data to tty_operations::write() Data are now typed as u8. Propagate this change to tty_operations::write(). Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Vaibhav Gupta <vaibhavgupta40@gmail.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Scott Branden <scott.branden@broadcom.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: David Lin <dtwlin@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: David Sterba <dsterba@suse.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Cc: Oliver Neukum <oneukum@suse.com> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Link: https://lore.kernel.org/r/20230810091510.13006-28-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
862d8312 |
|
02-Apr-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
tty: make tty_class a static const structure Now that the driver core allows for struct class to be in read-only memory, move the tty_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/2023040250-landowner-unfitted-11f4@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a8c11c15 |
|
16-Aug-2022 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
tty: Make ->set_termios() old ktermios const There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220816115739.10928-9-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a501ab75 |
|
07-Jul-2022 |
Jiri Slaby <jirislaby@kernel.org> |
tty: use new tty_insert_flip_string_and_push_buffer() in pty_write() There is a race in pty_write(). pty_write() can be called in parallel with e.g. ioctl(TIOCSTI) or ioctl(TCXONC) which also inserts chars to the buffer. Provided, tty_flip_buffer_push() in pty_write() is called outside the lock, it can commit inconsistent tail. This can lead to out of bounds writes and other issues. See the Link below. To fix this, we have to introduce a new helper called tty_insert_flip_string_and_push_buffer(). It does both tty_insert_flip_string() and tty_flip_buffer_commit() under the port lock. It also calls queue_work(), but outside the lock. See 71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in pty_write) for the reasons. Keep the helper internal-only (in drivers' tty.h). It is not intended to be used widely. Link: https://seclists.org/oss-sec/2022/q2/155 Fixes: 71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in pty_write) Cc: 一只狗 <chennbnbnb@gmail.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by: Hillf Danton <hdanton@sina.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220707082558.9250-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f6038cf4 |
|
17-May-2021 |
Yang Yingliang <yangyingliang@huawei.com> |
tty: pty: correct function name pty_resize() Fix the following make W=1 kernel build warning: drivers/tty/pty.c:307: warning: expecting prototype for pty_do_resize(). Prototype was for pty_resize() instead Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210518045353.611017-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4503b1c2 |
|
13-May-2021 |
Colin Ian King <colin.king@canonical.com> |
tty: pty: remove redundant initialization of variable fd The variable fd is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210513221833.137672-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fa7501e5 |
|
05-May-2021 |
Jiri Slaby <jirislaby@kernel.org> |
tty: remove tty_operations::chars_in_buffer for non-buffering The only user of tty_ops::chars_in_buffer is tty_chars_in_buffer. And it considers tty_ops::chars_in_buffer optional. In case it's NULL, zero is returned. So remove all those chars_in_buffer from tty_ops which return zero. (Zero means such driver doesn't buffer.) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Richard Henderson <rth@twiddle.net> Acked-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: Chris Zankel <chris@zankel.net> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Link: https://lore.kernel.org/r/20210505091928.22010-26-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
03b3b1a2 |
|
05-May-2021 |
Jiri Slaby <jirislaby@kernel.org> |
tty: make tty_operations::write_room return uint Line disciplines expect a positive value or zero returned from tty->ops->write_room (invoked by tty_write_room). So make this assumption explicit by using unsigned int as a return value. Both of tty->ops->write_room and tty_write_room. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Acked-by: Alex Elder <elder@linaro.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa Acked-by: David Sterba <dsterba@suse.com> Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Cc: Chris Zankel <chris@zankel.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Cc: Jens Taprogge <jens.taprogge@taprogge.org> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Scott Branden <scott.branden@broadcom.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Lin <dtwlin@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Oliver Neukum <oneukum@suse.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Link: https://lore.kernel.org/r/20210505091928.22010-23-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
64d608db |
|
05-May-2021 |
Jiri Slaby <jirislaby@kernel.org> |
tty: cumulate and document tty_struct::ctrl* members Group the ctrl members under a single struct called ctrl. The new struct contains 'pgrp', 'session', 'pktstatus', and 'packet'. 'pktstatus' and 'packet' used to be bits in a bitfield. The struct also contains the lock protecting them to share the same cache line. Note that commit c545b66c6922b (tty: Serialize tcflow() with other tty flow control changes) added a padding to the original bitfield. It was for the bitfield to occupy a whole 64b word to avoid interferring stores on Alpha (cannot we evaporate this arch with weird implications to C code yet?). But it doesn't work as expected as the padding (tty_struct::ctrl_unused) is aligned to a 8B boundary too and occupies some bytes from the next word. So make it reliable by: 1) setting __aligned of the struct -- that aligns the start, and 2) making 'unsigned long unused[0]' as the last member of the struct -- pads the end. Add a kerneldoc comment for this grouped members. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20210505091928.22010-14-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6e94dbc7 |
|
05-May-2021 |
Jiri Slaby <jirislaby@kernel.org> |
tty: cumulate and document tty_struct::flow* members Group the flow flags under a single struct called flow. The new struct contains 'stopped' and 'tco_stopped' bools which used to be bits in a bitfield. The struct also contains the lock protecting them to potentially share the same cache line. Note that commit c545b66c6922b (tty: Serialize tcflow() with other tty flow control changes) added a padding to the original bitfield. It was for the bitfield to occupy a whole 64b word to avoid interferring stores on Alpha (cannot we evaporate this arch with weird implications to C code yet?). But it doesn't work as expected as the padding (tty_struct::unused) is aligned to a 8B boundary too and occupies some bytes from the next word. So make it reliable by: 1) setting __aligned of the struct -- that aligns the start, and 2) making 'unsigned long unused[0]' as the last member of the struct -- pads the end. This is also the perfect time to start the documentation of tty_struct where all this lives. So we start by documenting what these bools actually serve for. And why we do all the alignment dances. Only the few up-to-date information from the Theodore's comment made it into this new Kerneldoc comment. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: "Maciej W. Rozycki" <macro@orcam.me.uk> Link: https://lore.kernel.org/r/20210505091928.22010-13-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
98602c01 |
|
08-Apr-2021 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
tty: create internal tty.h file There are a number of functions and #defines in include/linux/tty.h that do not belong there as they are private to the tty core code. Create an initial drivers/tty/tty.h file and copy the odd "tty logging" macros into it to seed the file with some initial things that we know nothing outside of the tty core should be calling. Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
202680c7 |
|
02-Apr-2021 |
Xiaofei Tan <tanxiaofei@huawei.com> |
tty: pty: Add a blank line after declarations Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Link: https://lore.kernel.org/r/1617351990-5189-1-git-send-email-tanxiaofei@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c776b77a |
|
04-Mar-2021 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "drivers:tty:pty: Fix a race causing data loss on close" This reverts commit 33d4ae98859873ddd49e22e4ca724387548b3d89. Pierre-Louis writes: Our SOF/audio CI shows an across-the-board regression when we try v5.12-rc1, specifically on pause/resume tests with an interactive terminal running 'aplay -i' commands managed by expect to simulate the user pressing the space bar to pause/unpause. It turns out the processes are not longer killed and the audio devices remain busy (see publicly available test results listed below). git bisect points to commit 33d4ae9885987 ("drivers:tty:pty: Fix a race causing data loss on close"). Reverting the patch fixes the issue on all test devices. Further analysis with Corey Minyard points to a problem where a slave tty will not get a SIGHUP when the master is closed. So revert this for now: Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/00154592-c5ee-aaba-956e-b265473b53bc@linux.intel.com Cc: Corey Minyard <cminyard@mvista.com> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Mark Brown <broonie@kernel.org>, Fixes: 33d4ae988598 ("drivers:tty:pty: Fix a race causing data loss on close") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
33d4ae98 |
|
23-Nov-2020 |
Corey Minyard <cminyard@mvista.com> |
drivers:tty:pty: Fix a race causing data loss on close Remove the tty_vhangup() from the pty code and just release the redirect. The tty_vhangup() results in data loss and data out of order issues. If you write to a pty master an immediately close the pty master, the receiver might get a chunk of data dropped, but then receive some later data. That's obviously something rather unexpected for a user. It certainly confused my test program. It turns out that tty_vhangup() on the slave pty gets called from pty_close(), and that causes the data on the slave side to be flushed, but due to races more data can be copied into the slave side's buffer after that. Consider the following sequence: thread1 thread2 thread3 ------- ------- ------- | |-write data into buffer, | | n_tty buffer is filled | | along with other buffers | |-pty_close(master) | |--tty_vhangup(slave) | |---tty_ldisc_hangup() | |----n_tty_flush_buffer() | |-----reset_buffer_flags() |-n_tty_read() | |--up_read(&tty->termios_rwsem); | |------down_read(&tty->termios_rwsem) | |------clear n_tty buffer contents | |------up_read(&tty->termios_rwsem) |--tty_buffer_flush_work() | |--schedules work calling | | flush_to_ldisc() | | |-flush_to_ldisc() | |--receive_buf() | |---tty_port_default_receive_buf() | |----tty_ldisc_receive_buf() | |-----n_tty_receive_buf2() | |------n_tty_receive_buf_common() | |-------down_read(&tty->termios_rwsem) | |-------__receive_buf() | | copies data into n_tty buffer | |-------up_read(&tty->termios_rwsem) |--down_read(&tty->termios_rwsem) |--copy buffer data to user >From this sequence, you can see that thread2 writes to the buffer then only clears the part of the buffer in n_tty. The n_tty receive buffer code then copies more data into the n_tty buffer. But part of the vhangup, releasing the redirect, is still required to avoid issues with consoles running on pty slaves. So do that. As far as I can tell, that is all that should be required. Signed-off-by: Corey Minyard <cminyard@mvista.com> Link: https://lore.kernel.org/r/20201124004902.1398477-3-minyard@acm.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9bc1b2b9 |
|
05-Jan-2021 |
Jiri Slaby <jirislaby@kernel.org> |
tty: pty, remove BUG_ON from pty_close tty->ops->close is always called with a valid tty, so the BUG_ON cannot trigger. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210105120239.28031-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0b0a66a5 |
|
04-Nov-2020 |
Lee Jones <lee.jones@linaro.org> |
tty: pty: Provide descriptions for the 'file' parameters Fixes the following W=1 kernel build warning(s): drivers/tty/pty.c:710: warning: Function parameter or member 'file' not described in 'ptm_unix98_lookup' drivers/tty/pty.c:726: warning: Function parameter or member 'file' not described in 'pts_unix98_lookup' Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: "C. Scott Ananian" <cananian@alumni.princeton.edu> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201104193549.4026187-17-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
71a174b3 |
|
02-Sep-2020 |
Artem Savkov <asavkov@redhat.com> |
pty: do tty_flip_buffer_push without port->lock in pty_write b6da31b2c07c "tty: Fix data race in tty_insert_flip_string_fixed_flag" puts tty_flip_buffer_push under port->lock introducing the following possible circular locking dependency: [30129.876566] ====================================================== [30129.876566] WARNING: possible circular locking dependency detected [30129.876567] 5.9.0-rc2+ #3 Tainted: G S W [30129.876568] ------------------------------------------------------ [30129.876568] sysrq.sh/1222 is trying to acquire lock: [30129.876569] ffffffff92c39480 (console_owner){....}-{0:0}, at: console_unlock+0x3fe/0xa90 [30129.876572] but task is already holding lock: [30129.876572] ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca [30129.876576] which lock already depends on the new lock. [30129.876577] the existing dependency chain (in reverse order) is: [30129.876578] -> #3 (&pool->lock/1){-.-.}-{2:2}: [30129.876581] _raw_spin_lock+0x30/0x70 [30129.876581] __queue_work+0x1a3/0x10f0 [30129.876582] queue_work_on+0x78/0x80 [30129.876582] pty_write+0x165/0x1e0 [30129.876583] n_tty_write+0x47f/0xf00 [30129.876583] tty_write+0x3d6/0x8d0 [30129.876584] vfs_write+0x1a8/0x650 [30129.876588] -> #2 (&port->lock#2){-.-.}-{2:2}: [30129.876590] _raw_spin_lock_irqsave+0x3b/0x80 [30129.876591] tty_port_tty_get+0x1d/0xb0 [30129.876592] tty_port_default_wakeup+0xb/0x30 [30129.876592] serial8250_tx_chars+0x3d6/0x970 [30129.876593] serial8250_handle_irq.part.12+0x216/0x380 [30129.876593] serial8250_default_handle_irq+0x82/0xe0 [30129.876594] serial8250_interrupt+0xdd/0x1b0 [30129.876595] __handle_irq_event_percpu+0xfc/0x850 [30129.876602] -> #1 (&port->lock){-.-.}-{2:2}: [30129.876605] _raw_spin_lock_irqsave+0x3b/0x80 [30129.876605] serial8250_console_write+0x12d/0x900 [30129.876606] console_unlock+0x679/0xa90 [30129.876606] register_console+0x371/0x6e0 [30129.876607] univ8250_console_init+0x24/0x27 [30129.876607] console_init+0x2f9/0x45e [30129.876609] -> #0 (console_owner){....}-{0:0}: [30129.876611] __lock_acquire+0x2f70/0x4e90 [30129.876612] lock_acquire+0x1ac/0xad0 [30129.876612] console_unlock+0x460/0xa90 [30129.876613] vprintk_emit+0x130/0x420 [30129.876613] printk+0x9f/0xc5 [30129.876614] show_pwq+0x154/0x618 [30129.876615] show_workqueue_state.cold.55+0x193/0x6ca [30129.876615] __handle_sysrq+0x244/0x460 [30129.876616] write_sysrq_trigger+0x48/0x4a [30129.876616] proc_reg_write+0x1a6/0x240 [30129.876617] vfs_write+0x1a8/0x650 [30129.876619] other info that might help us debug this: [30129.876620] Chain exists of: [30129.876621] console_owner --> &port->lock#2 --> &pool->lock/1 [30129.876625] Possible unsafe locking scenario: [30129.876626] CPU0 CPU1 [30129.876626] ---- ---- [30129.876627] lock(&pool->lock/1); [30129.876628] lock(&port->lock#2); [30129.876630] lock(&pool->lock/1); [30129.876631] lock(console_owner); [30129.876633] *** DEADLOCK *** [30129.876634] 5 locks held by sysrq.sh/1222: [30129.876634] #0: ffff8881d3ce0470 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x359/0x650 [30129.876637] #1: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: __handle_sysrq+0x4d/0x460 [30129.876640] #2: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: show_workqueue_state+0x5/0xf0 [30129.876642] #3: ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca [30129.876645] #4: ffffffff92c39980 (console_lock){+.+.}-{0:0}, at: vprintk_emit+0x123/0x420 [30129.876648] stack backtrace: [30129.876649] CPU: 3 PID: 1222 Comm: sysrq.sh Tainted: G S W 5.9.0-rc2+ #3 [30129.876649] Hardware name: Intel Corporation 2012 Client Platform/Emerald Lake 2, BIOS ACRVMBY1.86C.0078.P00.1201161002 01/16/2012 [30129.876650] Call Trace: [30129.876650] dump_stack+0x9d/0xe0 [30129.876651] check_noncircular+0x34f/0x410 [30129.876653] __lock_acquire+0x2f70/0x4e90 [30129.876656] lock_acquire+0x1ac/0xad0 [30129.876658] console_unlock+0x460/0xa90 [30129.876660] vprintk_emit+0x130/0x420 [30129.876660] printk+0x9f/0xc5 [30129.876661] show_pwq+0x154/0x618 [30129.876662] show_workqueue_state.cold.55+0x193/0x6ca [30129.876664] __handle_sysrq+0x244/0x460 [30129.876665] write_sysrq_trigger+0x48/0x4a [30129.876665] proc_reg_write+0x1a6/0x240 [30129.876666] vfs_write+0x1a8/0x650 It looks like the commit was aimed to protect tty_insert_flip_string and there is no need for tty_flip_buffer_push to be under this lock. Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Artem Savkov <asavkov@redhat.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20200902120045.3693075-1-asavkov@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fa441954 |
|
18-Aug-2020 |
Jiri Slaby <jirislaby@kernel.org> |
tty: fix kernel-doc With W=1, the kernel-doc checker complains quite a lot in the tty layer. Over the time, many documented parameters were renamed, removed or switched from tty to tty_port and similar. Some were mistyped in the doc too. So fix all these in the tty core. (But do not add the missing ones which the checker complains about too. Not now.) The rest in the tty layer will follow in the next patches. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200818085655.12071-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0eae4686 |
|
29-Mar-2019 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "tty: pty: Fix race condition between release_one_tty and pty_write" This reverts commit b9ca5f8560af244489b4a1bc1ae88b341f24bc95 as 0-day shows it has a circular locking dependency. Fixes: b9ca5f8560af ("tty: pty: Fix race condition between release_one_tty and pty_write") Reported-by: kernel test robot <lkp@intel.com> Cc: Sahara <keun-o.park@darkmatter.ae> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b9ca5f85 |
|
11-Feb-2019 |
Sahara <keun-o.park@darkmatter.ae> |
tty: pty: Fix race condition between release_one_tty and pty_write Especially when a linked tty is used such as pty, the linked tty port's buf works have not been cancelled while master tty port's buf work has been cancelled. Since release_one_tty and flush_to_ldisc run in workqueue threads separately, when pty_cleanup happens and link tty port is freed, flush_to_ldisc tries to access freed port and port->itty, eventually it causes a panic. This patch utilizes the magic value with holding the tty_mutex to check if the tty->link is valid. Fixes: 2b022ab7542d ("pty: cancel pty slave port buf's work in tty_release") Signed-off-by: Sahara <keun-o.park@darkmatter.ae> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
50f45326 |
|
12-Sep-2018 |
Al Viro <viro@zeniv.linux.org.uk> |
pty: fix compat ioctls pointer-taking ones need compat_ptr(); int-taking one doesn't. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
36ecc148 |
|
19-Jul-2018 |
Matthijs van Duin <matthijsvanduin@gmail.com> |
pty: fix O_CLOEXEC for TIOCGPTPEER It was being ignored because the flags were not passed to fd allocation. Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") Signed-off-by: Matthijs van Duin <matthijsvanduin@gmail.com> Acked-by: Aleksa Sarai <asarai@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b6da31b2 |
|
30-Apr-2018 |
DaeRyong Jeong <threeearcat@gmail.com> |
tty: Fix data race in tty_insert_flip_string_fixed_flag Unlike normal serials, in pty layer, there is no guarantee that multiple threads don't insert input characters at the same time. If it is happened, tty_insert_flip_string_fixed_flag can be executed concurrently. This can lead slab out-of-bounds write in tty_insert_flip_string_fixed_flag. Call sequences are as follows. CPU0 CPU1 n_tty_ioctl_helper n_tty_ioctl_helper __start_tty tty_send_xchar tty_wakeup pty_write n_hdlc_tty_wakeup tty_insert_flip_string n_hdlc_send_frames tty_insert_flip_string_fixed_flag pty_write tty_insert_flip_string tty_insert_flip_string_fixed_flag To fix the race, acquire port->lock in pty_write() before it inserts input characters to tty buffer. It prevents multiple threads from inserting input characters concurrently. The crash log is as follows: BUG: KASAN: slab-out-of-bounds in tty_insert_flip_string_fixed_flag+0xb5/ 0x130 drivers/tty/tty_buffer.c:316 at addr ffff880114fcc121 Write of size 1792 by task syz-executor0/30017 CPU: 1 PID: 30017 Comm: syz-executor0 Not tainted 4.8.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 0000000000000000 ffff88011638f888 ffffffff81694cc3 ffff88007d802140 ffff880114fcb300 ffff880114fcc300 ffff880114fcb300 ffff88011638f8b0 ffffffff8130075c ffff88011638f940 ffff88007d802140 ffff880194fcc121 Call Trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0xb3/0x110 lib/dump_stack.c:51 kasan_object_err+0x1c/0x70 mm/kasan/report.c:156 print_address_description mm/kasan/report.c:194 [inline] kasan_report_error+0x1f7/0x4e0 mm/kasan/report.c:283 kasan_report+0x36/0x40 mm/kasan/report.c:303 check_memory_region_inline mm/kasan/kasan.c:292 [inline] check_memory_region+0x13e/0x1a0 mm/kasan/kasan.c:299 memcpy+0x37/0x50 mm/kasan/kasan.c:335 tty_insert_flip_string_fixed_flag+0xb5/0x130 drivers/tty/tty_buffer.c:316 tty_insert_flip_string include/linux/tty_flip.h:35 [inline] pty_write+0x7f/0xc0 drivers/tty/pty.c:115 n_hdlc_send_frames+0x1d4/0x3b0 drivers/tty/n_hdlc.c:419 n_hdlc_tty_wakeup+0x73/0xa0 drivers/tty/n_hdlc.c:496 tty_wakeup+0x92/0xb0 drivers/tty/tty_io.c:601 __start_tty.part.26+0x66/0x70 drivers/tty/tty_io.c:1018 __start_tty+0x34/0x40 drivers/tty/tty_io.c:1013 n_tty_ioctl_helper+0x146/0x1e0 drivers/tty/tty_ioctl.c:1138 n_hdlc_tty_ioctl+0xb3/0x2b0 drivers/tty/n_hdlc.c:794 tty_ioctl+0xa85/0x16d0 drivers/tty/tty_io.c:2992 vfs_ioctl fs/ioctl.c:43 [inline] do_vfs_ioctl+0x13e/0xba0 fs/ioctl.c:679 SYSC_ioctl fs/ioctl.c:694 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685 entry_SYSCALL_64_fastpath+0x1f/0xbd Signed-off-by: DaeRyong Jeong <threeearcat@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a9a08845 |
|
11-Feb-2018 |
Linus Torvalds <torvalds@linux-foundation.org> |
vfs: do bulk POLL* -> EPOLL* replacement This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b2441318 |
|
01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d01c3289 |
|
17-Jul-2017 |
Masatake YAMATO <yamato@redhat.com> |
pty: show associative slave of ptmx in fdinfo This patch adds "tty-index" field to /proc/PID/fdinfo/N if N specifies /dev/ptmx. The field shows the index of associative slave pts. Though a minor number is given for each pts instance, ptmx is not. It means there is no way in user-space to know the association between file descriptors for pts/n and ptmx. (n = 0, 1, ...) This is different from pipe. About pipe such association can be solved by inode of pipefs. Providing the way to know the association between pts/n and ptmx helps users understand the status of running system. lsof can utilize this field. Signed-off-by: Masatake YAMATO <yamato@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
311fc65c |
|
24-Aug-2017 |
Eric W. Biederman <ebiederm@xmission.com> |
pty: Repair TIOCGPTPEER The implementation of TIOCGPTPEER has two issues. When /dev/ptmx (as opposed to /dev/pts/ptmx) is opened the wrong vfsmount is passed to dentry_open. Which results in the kernel displaying the wrong pathname for the peer. The second is simply by caching the vfsmount and dentry of the peer it leaves them open, in a way they were not previously Which because of the inreased reference counts can cause unnecessary behaviour differences resulting in regressions. To fix these move the ioctl into tty_io.c at a generic level allowing the ioctl to have access to the struct file on which the ioctl is being called. This allows the path of the slave to be derived when opening the slave through TIOCGPTPEER instead of requiring the path to the slave be cached. Thus removing the need for caching the path. A new function devpts_ptmx_path is factored out of devpts_acquire and used to implement a function devpts_mntget. The new function devpts_mntget takes a filp to perform the lookup on and fsi so that it can confirm that the superblock that is found by devpts_ptmx_path is the proper superblock. v2: Lots of fixes to make the code actually work v3: Suggestions by Linus - Removed the unnecessary initialization of filp in ptm_open_peer - Simplified devpts_ptmx_path as gotos are no longer required [ This is the fix for the issue that was reverted in commit 143c97cc6529, but this time without breaking 'pbuilder' due to increased reference counts - Linus ] Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") Reported-by: Christian Brauner <christian.brauner@canonical.com> Reported-and-tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
143c97cc |
|
23-Aug-2017 |
Linus Torvalds <torvalds@linux-foundation.org> |
Revert "pty: fix the cached path of the pty slave file descriptor in the master" This reverts commit c8c03f1858331e85d397bacccd34ef409aae993c. It turns out that while fixing the ptmx file descriptor to have the correct 'struct path' to the associated slave pty is a really good thing, it breaks some user space tools for a very annoying reason. The problem is that /dev/ptmx and its associated slave pty (/dev/pts/X) are on different mounts. That was what caused us to have the wrong path in the first place (we would mix up the vfsmount of the 'ptmx' node, with the dentry of the pty slave node), but it also means that now while we use the right vfsmount, having the pty master open also keeps the pts mount busy. And it turn sout that that makes 'pbuilder' very unhappy, as noted by Stefan Lippers-Hollmann: "This patch introduces a regression for me when using pbuilder 0.228.7[2] (a helper to build Debian packages in a chroot and to create and update its chroots) when trying to umount /dev/ptmx (inside the chroot) on Debian/ unstable (full log and pbuilder configuration file[3] attached). [...] Setting up build-essential (12.3) ... Processing triggers for libc-bin (2.24-15) ... I: unmounting dev/ptmx filesystem W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).)" apparently pbuilder tries to unmount the /dev/pts filesystem while still holding at least one master node open, which is arguably not very nice, but we don't break user space even when fixing other bugs. So this commit has to be reverted. I'll try to figure out a way to avoid caching the path to the slave pty in the master pty. The only thing that actually wants that slave pty path is the "TIOCGPTPEER" ioctl, and I think we could just recreate the path at that time. Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Cc: Eric W Biederman <ebiederm@xmission.com> Cc: Christian Brauner <christian.brauner@canonical.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
c8c03f18 |
|
16-Aug-2017 |
Linus Torvalds <torvalds@linux-foundation.org> |
pty: fix the cached path of the pty slave file descriptor in the master Christian Brauner reported that if you use the TIOCGPTPEER ioctl() to get a slave pty file descriptor, the resulting file descriptor doesn't look right in /proc/<pid>/fd/<fd>. In particular, he wanted to use readlink() on /proc/self/fd/<fd> to get the pathname of the slave pty (basically implementing "ptsname{_r}()"). The reason for that was that we had generated the wrong 'struct path' when we create the pty in ptmx_open(). In particular, the dentry was correct, but the vfsmount pointed to the mount of the ptmx node. That _can_ be correct - in case you use "/dev/pts/ptmx" to open the master - but usually is not. The normal case is to use /dev/ptmx, which then looks up the pts/ directory, and then the vfsmount of the ptmx node is obviously the /dev directory, not the /dev/pts/ directory. We actually did have the right vfsmount available, but in the wrong place (it gets looked up in 'devpts_acquire()' when we get a reference to the pts filesystem), and so ptmx_open() used the wrong mnt pointer. The end result of this confusion was that the pty worked fine, but when if you did TIOCGPTPEER to get the slave side of the pty, end end result would also work, but have that dodgy 'struct path'. And then when doing "d_path()" on to get the pathname, the vfsmount would not match the root of the pts directory, and d_path() would return an empty pathname thinking that the entry had escaped a bind mount into another mount. This fixes the problem by making devpts_acquire() return the vfsmount for the pts filesystem, allowing ptmx_open() to trivially just use the right mount for the pts dentry, and create the proper 'struct path'. Reported-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
6509f309 |
|
20-Jun-2017 |
Arnd Bergmann <arnd@arndb.de> |
tty: hide unused pty_get_peer function TIOCGPTPEER is only used for unix98 PTYs, and we get a warning when those are disabled: drivers/tty/pty.c:466:12: error: 'pty_get_peer' defined but not used [-Werror=unused-function] This moves the respective functions inside of the existing #ifdef. Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Aleksa Sarai <asarai@suse.de> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
54ebbfb1 |
|
03-Jun-2017 |
Aleksa Sarai <asarai@suse.de> |
tty: add TIOCGPTPEER ioctl When opening the slave end of a PTY, it is not possible for userspace to safely ensure that /dev/pts/$num is actually a slave (in cases where the mount namespace in which devpts was mounted is controlled by an untrusted process). In addition, there are several unresolvable race conditions if userspace were to attempt to detect attacks through stat(2) and other similar methods [in addition it is not clear how userspace could detect attacks involving FUSE]. Resolve this by providing an interface for userpace to safely open the "peer" end of a PTY file descriptor by using the dentry cached by devpts. Since it is not possible to have an open master PTY without having its slave exposed in /dev/pts this interface is safe. This interface currently does not provide a way to get the master pty (since it is not clear whether such an interface is safe or even useful). Cc: Christian Brauner <christian.brauner@ubuntu.com> Cc: Valentin Rothberg <vrothberg@suse.com> Signed-off-by: Aleksa Sarai <asarai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5f0f187f |
|
03-Jun-2017 |
Aleksa Sarai <asarai@suse.de> |
tty: add compat_ioctl callbacks In order to avoid future diversions between fs/compat_ioctl.c and drivers/tty/pty.c, define .compat_ioctl callbacks for the relevant tty_operations structs. Since both pty_unix98_ioctl() and pty_bsd_ioctl() are compatible between 32-bit and 64-bit userspace no special translation is required. Signed-off-by: Aleksa Sarai <asarai@suse.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
77dae613 |
|
22-Feb-2017 |
Wang YanQing <udknight@gmail.com> |
tty: pty: Fix ldisc flush after userspace become aware of the data already While using emacs, cat or others' commands in konsole with recent kernels, I have met many times that CTRL-C freeze konsole. After konsole freeze I can't type anything, then I have to open a new one, it is very annoying. See bug report: https://bugs.kde.org/show_bug.cgi?id=175283 The platform in that bug report is Solaris, but now the pty in linux has the same problem or the same behavior as Solaris :) It has high possibility to trigger the problem follow steps below: Note: In my test, BigFile is a text file whose size is bigger than 1G 1:open konsole 1:cat BigFile 2:CTRL-C After some digging, I find out the reason is that commit 1d1d14da12e7 ("pty: Fix buffer flush deadlock") changes the behavior of pty_flush_buffer. Thread A Thread B -------- -------- 1:n_tty_poll return POLLIN 2:CTRL-C trigger pty_flush_buffer tty_buffer_flush n_tty_flush_buffer 3:attempt to check count of chars: ioctl(fd, TIOCINQ, &available) available is equal to 0 4:read(fd, buffer, avaiable) return 0 5:konsole close fd Yes, I know we could use the same patch included in the BUG report as a workaround for linux platform too. But I think the data in ldisc is belong to application of another side, we shouldn't clear it when we want to flush write buffer of this side in pty_flush_buffer. So I think it is better to disable ldisc flush in pty_flush_buffer, because its new hehavior bring no benefit except that it mess up the behavior between POLLIN, and TIOCINQ or FIONREAD. Also I find no flush_buffer function in others' tty driver has the same behavior as current pty_flush_buffer. Fixes: 1d1d14da12e7 ("pty: Fix buffer flush deadlock") CC: stable@vger.kernel.org # v4.0+ Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
3f07c014 |
|
08-Feb-2017 |
Ingo Molnar <mingo@kernel.org> |
sched/headers: Prepare for new header dependencies before moving code to <linux/sched/signal.h> We are going to split <linux/sched/signal.h> out of <linux/sched.h>, which will have to be picked up from other headers and a couple of .c files. Create a trivial placeholder <linux/sched/signal.h> file that just maps to <linux/sched.h> to make this patch obviously correct and bisectable. Include the new header in the files that are going to need it. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
d2ec3f77 |
|
08-Sep-2016 |
Kees Cook <keescook@chromium.org> |
pty: make ptmx file ops read-only after init The ptmx_fops structure is only changed during init, so mark it as such. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5353ed8d |
|
20-Jun-2016 |
Colin Ian King <colin.king@canonical.com> |
devpts: fix null pointer dereference on failed memory allocation An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null pointer dereference in devpts_kill_index because tty->link->driver_data is NULL. The oops was triggered with the pty stressor in stress-ng when in a low memory condition. tty_init_dev tries to clean up a tty_ldisc_setup ENOMEM error by calling release_tty, however, this ultimately tries to clean up the NULL pair'd tty in pty_unix98_remove, triggering the Oops. Add check to pty_unix98_remove to only clean up fsi if it is not NULL. Ooops: [ 23.020961] Oops: 0000 [#1] SMP [ 23.020976] Modules linked in: ppdev snd_hda_codec_generic snd_hda_intel snd_hda_codec parport_pc snd_hda_core snd_hwdep parport snd_pcm input_leds joydev snd_timer serio_raw snd soundcore i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel qxl aes_x86_64 ttm lrw gf128mul glue_helper ablk_helper drm_kms_helper cryptd syscopyarea sysfillrect psmouse sysimgblt floppy fb_sys_fops drm pata_acpi jitterentropy_rng drbg ansi_cprng [ 23.020978] CPU: 0 PID: 1452 Comm: stress-ng-pty Not tainted 4.7.0-rc4+ #2 [ 23.020978] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 23.020979] task: ffff88007ba30000 ti: ffff880078ea8000 task.ti: ffff880078ea8000 [ 23.020981] RIP: 0010:[<ffffffff813f11ff>] [<ffffffff813f11ff>] ida_remove+0x1f/0x120 [ 23.020981] RSP: 0018:ffff880078eabb60 EFLAGS: 00010a03 [ 23.020982] RAX: 4444444444444567 RBX: 0000000000000000 RCX: 000000000000001f [ 23.020982] RDX: 000000000000014c RSI: 000000000000026f RDI: 0000000000000000 [ 23.020982] RBP: ffff880078eabb70 R08: 0000000000000004 R09: 0000000000000036 [ 23.020983] R10: 000000000000026f R11: 0000000000000000 R12: 000000000000026f [ 23.020983] R13: 000000000000026f R14: ffff88007c944b40 R15: 000000000000026f [ 23.020984] FS: 00007f9a2f3cc700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 23.020984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.020985] CR2: 0000000000000010 CR3: 000000006c81b000 CR4: 00000000001406f0 [ 23.020988] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 23.020988] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 23.020988] Stack: [ 23.020989] 0000000000000000 000000000000026f ffff880078eabb90 ffffffff812a5a99 [ 23.020990] 0000000000000000 00000000fffffff4 ffff880078eabba8 ffffffff814f9cbe [ 23.020991] ffff88007965c800 ffff880078eabbc8 ffffffff814eef43 fffffffffffffff4 [ 23.020991] Call Trace: [ 23.021000] [<ffffffff812a5a99>] devpts_kill_index+0x29/0x50 [ 23.021002] [<ffffffff814f9cbe>] pty_unix98_remove+0x2e/0x50 [ 23.021006] [<ffffffff814eef43>] release_tty+0xb3/0x1b0 [ 23.021007] [<ffffffff814f18d4>] tty_init_dev+0xd4/0x1c0 [ 23.021011] [<ffffffff814f9fae>] ptmx_open+0xae/0x190 [ 23.021013] [<ffffffff812254ef>] chrdev_open+0xbf/0x1b0 [ 23.021015] [<ffffffff8121d973>] do_dentry_open+0x203/0x310 [ 23.021016] [<ffffffff81225430>] ? cdev_put+0x30/0x30 [ 23.021017] [<ffffffff8121ee44>] vfs_open+0x54/0x80 [ 23.021018] [<ffffffff8122b8fc>] ? may_open+0x8c/0x100 [ 23.021019] [<ffffffff8122f26b>] path_openat+0x2eb/0x1440 [ 23.021020] [<ffffffff81230534>] ? putname+0x54/0x60 [ 23.021022] [<ffffffff814f6f97>] ? n_tty_ioctl_helper+0x27/0x100 [ 23.021023] [<ffffffff81231651>] do_filp_open+0x91/0x100 [ 23.021024] [<ffffffff81230596>] ? getname_flags+0x56/0x1f0 [ 23.021026] [<ffffffff8123fc66>] ? __alloc_fd+0x46/0x190 [ 23.021027] [<ffffffff8121f1e4>] do_sys_open+0x124/0x210 [ 23.021028] [<ffffffff8121f2ee>] SyS_open+0x1e/0x20 [ 23.021035] [<ffffffff81845576>] entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 23.021044] Code: 63 28 45 31 e4 eb dd 0f 1f 44 00 00 55 4c 63 d6 48 ba 89 88 88 88 88 88 88 88 4c 89 d0 b9 1f 00 00 00 48 f7 e2 48 89 e5 41 54 53 <8b> 47 10 48 89 fb 8d 3c c5 00 00 00 00 48 c1 ea 09 b8 01 00 00 [ 23.021045] RIP [<ffffffff813f11ff>] ida_remove+0x1f/0x120 [ 23.021045] RSP <ffff880078eabb60> [ 23.021046] CR2: 0000000000000010 Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
eedf265a |
|
02-Jun-2016 |
Eric W. Biederman <ebiederm@xmission.com> |
devpts: Make each mount of devpts an independent filesystem. The /dev/ptmx device node is changed to lookup the directory entry "pts" in the same directory as the /dev/ptmx device node was opened in. If there is a "pts" entry and that entry is a devpts filesystem /dev/ptmx uses that filesystem. Otherwise the open of /dev/ptmx fails. The DEVPTS_MULTIPLE_INSTANCES configuration option is removed, so that userspace can now safely depend on each mount of devpts creating a new instance of the filesystem. Each mount of devpts is now a separate and equal filesystem. Reserved ttys are now available to all instances of devpts where the mounter is in the initial mount namespace. A new vfs helper path_pts is introduced that finds a directory entry named "pts" in the directory of the passed in path, and changes the passed in path to point to it. The helper path_pts uses a function path_parent_directory that was factored out of follow_dotdot. In the implementation of devpts: - devpts_mnt is killed as it is no longer meaningful if all mounts of devpts are equal. - pts_sb_from_inode is replaced by just inode->i_sb as all cached inodes in the tty layer are now from the devpts filesystem. - devpts_add_ref is rolled into the new function devpts_ptmx. And the unnecessary inode hold is removed. - devpts_del_ref is renamed devpts_release and reduced to just a deacrivate_super. - The newinstance mount option continues to be accepted but is now ignored. In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed as they are never used. Documentation/filesystems/devices.txt is updated to describe the current situation. This has been verified to work properly on openwrt-15.05, centos5, centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2, ubuntu-14.04.3, ubuntu-15.10, fedora23, magia-5, mint-17.3, opensuse-42.1, slackware-14.1, gentoo-20151225 (13.0?), archlinux-2015-12-01. With the caveat that on centos6 and on slackware-14.1 that there wind up being two instances of the devpts filesystem mounted on /dev/pts, the lower copy does not end up getting used. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Greg KH <greg@kroah.com> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Peter Anvin <hpa@zytor.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Jann Horn <jann@thejh.net> Cc: Jiri Slaby <jslaby@suse.com> Cc: Florian Weimer <fw@deneb.enyo.de> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0f40fbbc |
|
06-Mar-2016 |
Brian Bloniarz <brian.bloniarz@gmail.com> |
Fix OpenSSH pty regression on close OpenSSH expects the (non-blocking) read() of pty master to return EAGAIN only if it has received all of the slave-side output after it has received SIGCHLD. This used to work on pre-3.12 kernels. This fix effectively forces non-blocking read() and poll() to block for parallel i/o to complete for all ttys. It also unwinds these changes: 1) f8747d4a466ab2cafe56112c51b3379f9fdb7a12 tty: Fix pty master read() after slave closes 2) 52bce7f8d4fc633c9a9d0646eef58ba6ae9a3b73 pty, n_tty: Simplify input processing on final close 3) 1a48632ffed61352a7810ce089dc5a8bcd505a60 pty: Fix input race when closing Inspired by analysis and patch from Marc Aurele La France <tsi@tuyoix.net> Reported-by: Volth <openssh@volth.com> Reported-by: Marc Aurele La France <tsi@tuyoix.net> BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52 BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492 Signed-off-by: Brian Bloniarz <brian.bloniarz@gmail.com> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
18900ca6 |
|
09-Apr-2016 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Replace TTY_IO_ERROR bit tests with tty_io_error() Abstract TTY_IO_ERROR status test treewide with tty_io_error(). NB: tty->flags uses atomic bit ops; replace non-atomic bit test with test_bit(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8ead9dd5 |
|
25-Apr-2016 |
Linus Torvalds <torvalds@linux-foundation.org> |
devpts: more pty driver interface cleanups This is more prep-work for the upcoming pty changes. Still just code cleanup with no actual semantic changes. This removes a bunch pointless complexity by just having the slave pty side remember the dentry associated with the devpts slave rather than the inode. That allows us to remove all the "look up the dentry" code for when we want to remove it again. Together with moving the tty pointer from "inode->i_private" to "dentry->d_fsdata" and getting rid of pointless inode locking, this removes about 30 lines of code. Not only is the end result smaller, it's simpler and easier to understand. The old code, for example, depended on the d_find_alias() to not just find the dentry, but also to check that it is still hashed, which in turn validated the tty pointer in the inode. That is a _very_ roundabout way to say "invalidate the cached tty pointer when the dentry is removed". The new code just does dentry->d_fsdata = NULL; in devpts_pty_kill() instead, invalidating the tty pointer rather more directly and obviously. Don't do something complex and subtle when the obvious straightforward approach will do. The rest of the patch (ie apart from code deletion and the above tty pointer clearing) is just switching the calling convention to pass the dentry or file pointer around instead of the inode. Cc: Eric Biederman <ebiederm@xmission.com> Cc: Peter Anvin <hpa@zytor.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Cc: Jann Horn <jann@thejh.net> Cc: Greg KH <greg@kroah.com> Cc: Jiri Slaby <jslaby@suse.com> Cc: Florian Weimer <fw@deneb.enyo.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
67245ff3 |
|
16-Apr-2016 |
Linus Torvalds <torvalds@linux-foundation.org> |
devpts: clean up interface to pty drivers This gets rid of the horrible notion of having that struct inode *ptmx_inode be the linchpin of the interface between the pty code and devpts. By de-emphasizing the ptmx inode, a lot of things actually get cleaner, and we will have a much saner way forward. In particular, this will allow us to associate with any particular devpts instance at open-time, and not be artificially tied to one particular ptmx inode. The patch itself is actually fairly straightforward, and apart from some locking and return path cleanups it's pretty mechanical: - the interfaces that devpts exposes all take "struct pts_fs_info *" instead of "struct inode *ptmx_inode" now. NOTE! The "struct pts_fs_info" thing is a completely opaque structure as far as the pty driver is concerned: it's still declared entirely internally to devpts. So the pty code can't actually access it in any way, just pass it as a "cookie" to the devpts code. - the "look up the pts fs info" is now a single clear operation, that also does the reference count increment on the pts superblock. So "devpts_add/del_ref()" is gone, and replaced by a "lookup and get ref" operation (devpts_get_ref(inode)), along with a "put ref" op (devpts_put_ref()). - the pty master "tty->driver_data" field now contains the pts_fs_info, not the ptmx inode. - because we don't care about the ptmx inode any more as some kind of base index, the ref counting can now drop the inode games - it just gets the ref on the superblock. - the pts_fs_info now has a back-pointer to the super_block. That's so that we can easily look up the information we actually need. Although quite often, the pts fs info was actually all we wanted, and not having to look it up based on some magical inode makes things more straightforward. In particular, now that "devpts_get_ref(inode)" operation should really be the *only* place we need to look up what devpts instance we're associated with, and we do it exactly once, at ptmx_open() time. The other side of this is that one ptmx node could now be associated with multiple different devpts instances - you could have a single /dev/ptmx node, and then have multiple mount namespaces with their own instances of devpts mounted on /dev/pts/. And that's all perfectly sane in a model where we just look up the pts instance at open time. This will eventually allow us to get rid of our odd single-vs-multiple pts instance model, but this patch in itself changes no semantics, only an internal binding model. Cc: Eric Biederman <ebiederm@xmission.com> Cc: Peter Anvin <hpa@zytor.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Cc: Jann Horn <jann@thejh.net> Cc: Greg KH <greg@kroah.com> Cc: Jiri Slaby <jslaby@suse.com> Cc: Florian Weimer <fw@deneb.enyo.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
1f55c718 |
|
14-Jan-2016 |
Herton R. Krzesinski <herton@redhat.com> |
pty: make sure super_block is still valid in final /dev/tty close Considering current pty code and multiple devpts instances, it's possible to umount a devpts file system while a program still has /dev/tty opened pointing to a previosuly closed pty pair in that instance. In the case all ptmx and pts/N files are closed, umount can be done. If the program closes /dev/tty after umount is done, devpts_kill_index will use now an invalid super_block, which was already destroyed in the umount operation after running ->kill_sb. This is another "use after free" type of issue, but now related to the allocated super_block instance. To avoid the problem (warning at ida_remove and potential crashes) for this specific case, I added two functions in devpts which grabs additional references to the super_block, which pty code now uses so it makes sure the super block structure is still valid until pty shutdown is done. I also moved the additional inode references to the same functions, which also covered similar case with inode being freed before /dev/tty final close/shutdown. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Cc: stable@vger.kernel.org # 2.6.29+ Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2831c89f |
|
10-Jan-2016 |
Herton R. Krzesinski <herton@redhat.com> |
pty: fix possible use after free of tty->driver_data This change fixes a bug for a corner case where we have the the last release from a pty master/slave coming from a previously opened /dev/tty file. When this happens, the tty->driver_data can be stale, due to all ptmx or pts/N files having already been closed before (and thus the inode related to these files, which tty->driver_data points to, being already freed/destroyed). The fix here is to keep a reference on the opened master ptmx inode. We maintain the inode referenced until the final pty_unix98_shutdown, and only pass this inode to devpts_kill_index. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Cc: <stable@vger.kernel.org> # 2.6.29+ Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9db276f8 |
|
10-Jan-2016 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Use termios c_*flag macros Expressions of the form "tty->termios.c_*flag & FLAG" are more clearly expressed with the termios flags macros, I_FLAG(), C_FLAG(), O_FLAG(), and L_FLAG(). Convert treewide. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c1e33af1 |
|
09-Jan-2016 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Remove pty_unix98_shutdown() The tty core invokes the optional driver shutdown() just before the optional driver remove() (shutdown() has access to the termios and remove() does not). Because pty drivers must prevent the default remove() action, the Unix98 pty drivers define a dummy remove() function. Instead, release the slave index in the remove() method and delete the optional shutdown() method. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a3123fd0 |
|
09-Jan-2016 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Fix tty_init_termios() declaration tty_init_termios() never returns an error; re-declare as void. Remove unnecessary error handling from callers. Remove extern declarations of tty_free_termios() and free_tty_struct() and re-declare in file scope. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c8b710b3 |
|
09-Jan-2016 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Fix ldisc leak in failed tty_init_dev() release_tty() leaks the ldisc instance when called directly (rather than when releasing the file descriptor from tty_release()). Since tty_ldisc_release() clears tty->ldisc, releasing the ldisc instance at tty teardown if tty->ldisc is non-null is not in danger of double-releasing the ldisc. Remove deinitialize_tty_struct() now that free_tty_struct() always performs the tty_ldisc_deinit(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d435cefe |
|
08-Nov-2015 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Remove __func__ from tty_debug() macro Now that tty_debug() macro uses pr_debug(), the function name can be printed when using dynamic debug; printing the function name within the format string is redundant. Remove the __func__ parameter and print specifier from the format string. Add context to messages for when the function name is not printed by dynamic debug, or when dynamic debug is not enabled. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7154988f |
|
19-Aug-2015 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
drivers/tty: make pty.c slightly more explicitly non-modular The Kconfig currently controlling compilation of this code is: drivers/tty/Kconfig:config LEGACY_PTYS drivers/tty/Kconfig: bool "Legacy (BSD) PTY support" ...and: drivers/tty/Kconfig:config UNIX98_PTYS drivers/tty/Kconfig: bool "Unix98 PTY support" if EXPERT combined with this: obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o ...meaning that it currently is not being built as a module by anyone. Lets remove the traces of modularity we can so that when reading the driver there is less doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We don't delete the module.h include since other parts of the file are using content from there. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d6847793 |
|
12-Jul-2015 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Add debug message for ptmx open Opens of /dev/ptmx don't use tty_open() so debug messages are not printed for those opens; print a debug message with the open count (which must always be 1) if TTY_DEBUG_HANGUP is defined. NB: Each tty core source file undefs support for debug messages. The relevant source file must be patched/edited to enable these messages. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1a48632f |
|
13-Apr-2015 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Fix input race when closing A read() from a pty master may mistakenly indicate EOF (errno == -EIO) after the pty slave has closed, even though input data remains to be read. For example, pty slave | input worker | pty master | | | | n_tty_read() pty_write() | | input avail? no add data | | sleep schedule worker --->| | . |---> flush_to_ldisc() | . pty_close() | fill read buffer | . wait for worker | wakeup reader --->| . | read buffer full? |---> input avail ? yes |<--- yes - exit worker | copy 4096 bytes to user TTY_OTHER_CLOSED <---| |<--- kick worker | | **** New read() before worker starts **** | | n_tty_read() | | input avail? no | | TTY_OTHER_CLOSED? yes | | return -EIO Several conditions are required to trigger this race: 1. the ldisc read buffer must become full so the input worker exits 2. the read() count parameter must be >= 4096 so the ldisc read buffer is empty 3. the subsequent read() occurs before the kicked worker has processed more input However, the underlying cause of the race is that data is pipelined, while tty state is not; ie., data already written by the pty slave end is not yet visible to the pty master end, but state changes by the pty slave end are visible to the pty master end immediately. Pipeline the TTY_OTHER_CLOSED state through input worker to the reader. 1. Introduce TTY_OTHER_DONE which is set by the input worker when TTY_OTHER_CLOSED is set and either the input buffers are flushed or input processing has completed. Readers/polls are woken when TTY_OTHER_DONE is set. 2. Reader/poll checks TTY_OTHER_DONE instead of TTY_OTHER_CLOSED. 3. A new input worker is started from pty_close() after setting TTY_OTHER_CLOSED, which ensures the TTY_OTHER_DONE state will be set if the last input worker is already finished (or just about to exit). Remove tty_flush_to_ldisc(); no in-tree callers. Fixes: 52bce7f8d4fc ("pty, n_tty: Simplify input processing on final close") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96311 BugLink: http://bugs.launchpad.net/bugs/1429756 Cc: <stable@vger.kernel.org> # 3.19+ Reported-by: Andy Whitcroft <apw@canonical.com> Reported-by: H.J. Lu <hjl.tools@gmail.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d2b6f447 |
|
17-Jan-2015 |
Peter Hurley <peter@hurleysoftware.com> |
n_tty: Fix signal handling flushes BRKINT and ISIG requires input and output flush when a signal char is received. However, the order of operations is significant since parallel i/o may be ongoing. Merge the signal handling for BRKINT with ISIG handling. Process the signal first. This ensures any ongoing i/o is aborted; without this, a waiting writer may continue writing after the flush occurs and after the signal char has been echoed. Write lock the termios_rwsem, which excludes parallel writers from pushing new i/o until after the output buffers are flushed; claiming the write lock is necessary anyway to exclude parallel readers while the read buffer is flushed. Subclass the termios_rwsem for ptys since the slave pty performing the flush may appear to reorder the termios_rwsem->tty buffer lock lock order; adding annotation clarifies that slave tty_buffer lock-> slave termios_rwsem -> master tty_buffer lock is a valid lock order. Flush the echo buffer. In this context, the echo buffer is 'output'. Otherwise, the output will appear discontinuous because the output buffer was cleared which contains older output than the echo buffer. Open-code the read buffer flush since the input worker does not need kicking (this is the input worker). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1d1d14da |
|
17-Jan-2015 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Fix buffer flush deadlock The pty driver does not clear its write buffer when commanded. This is to avoid an apparent deadlock between parallel flushes from both pty ends; specifically when handling either BRK or INTR input. However, parallel flushes from this source is not possible since the pty master can never be set to BRKINT or ISIG. Parallel flushes from other sources are possible but these do not threaten deadlocks. Annotate the tty buffer mutex for lockdep to represent the nested tty_buffer locking which occurs when the pty slave is processing input (its buffer mutex held) and receives INTR or BRK and acquires the linked tty buffer mutex via tty_buffer_flush(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c81622ac |
|
16-Jan-2015 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Fix overlimit memory use The pty_space() computation is broken; the space already consumed in the tty buffer is not accounted for. Use tty_buffer_set_limit(), which enforces the limit automatically. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
37480a05 |
|
19-Jan-2015 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Prevent untrappable signals from malicious program Commit 26df6d13406d1a5 ("tty: Add EXTPROC support for LINEMODE") allows a process which has opened a pty master to send _any_ signal to the process group of the pty slave. Although potentially exploitable by a malicious program running a setuid program on a pty slave, it's unknown if this exploit currently exists. Limit to signals actually used. Cc: Theodore Ts'o <tytso@mit.edu> Cc: Howard Chu <hyc@symas.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Jiri Slaby <jslaby@suse.cz> Cc: <stable@vger.kernel.org> # 2.6.36+ Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
52bce7f8 |
|
04-Nov-2014 |
Peter Hurley <peter@hurleysoftware.com> |
pty, n_tty: Simplify input processing on final close When releasing one end of a pty pair, that end may just have written to the other, which the input processing worker, flush_to_ldisc(), is still working on but has not completed the copy to the other end's read buffer. So input may not appear to be available to a waiting reader but yet TTY_OTHER_CLOSED is now observed. The n_tty line discipline has worked around this by waiting for input processing to complete and then re-checking if input is available before exiting with -EIO. Since the tty/ldisc lock reordering, the wait for input processing to complete can now occur during final close before setting TTY_OTHER_CLOSED. In this way, a waiting reader is guaranteed to see input available (if any) before observing TTY_OTHER_CLOSED. Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1bb95415 |
|
04-Nov-2014 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Don't drop pty master tty lock to hangup slave With the revised tty lock order and lockdep annotation, claiming the pty slave lock is now safe while still holding the pty master lock. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2febdb63 |
|
04-Nov-2014 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Preset lock subclass for nested tty locks Eliminate the requirement of specifying the tty lock nesting at lock time; instead, set the lock subclass for slave ptys at pty install (normal ttys and master ptys use subclass 0). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
55199ea3 |
|
04-Nov-2014 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Always return -EIO if slave BSD pty opened first Opening the slave BSD pty first already returns -EIO from the slave pty_open(), which in turn causes the newly installed tty pair to be released before returning from tty_open(). However, this can also cause a parallel master BSD pty open to fail because the pty pair destruction may already been taking place in tty_release(). Failing at driver->install() if the slave pty is opened first ensures that a pty master open cannot fail, because the driver tables will not have been updated so tty_driver_lookup_tty() won't find the master pty (and attempt to "re-open" it). In turn, this guarantees that any tty with a tty->count == 0 is in final close (rather than never opened). Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4ed60fc2 |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Hold ctrl_lock for packet mode updates Updates to the packet mode enable require holding the ctrl_lock; the serialization prevents corruption of adjacent fields. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2622d73e |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Fix packet mode setting race Because pty_set_pktmode() does not claim the slave's ctrl_lock to clear ->ctrl_status (to avoid unnecessary lock nesting), pty_set_pktmode() may accidentally erase new ->ctrl_status updates. For example, CPU 0 | CPU 1 pty_set_pktmode() | pty_start() spin_lock(master's ctrl_lock) | tty->packet = 1 | | if (tty->link->packet) | spin_lock(slave's ctrl_lock) | tty->ctrl_status = TIOCPKT_START tty->link->ctrl_status = 0 | Ensure the clear of ->ctrl_status occurs before packet mode is set (and observable on another cpu). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
54e8e5fc |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Don't claim slave's ctrl_lock for master's packet mode The slave's ctrl_lock serializes updates to the ctrl_status field only, whereas the master's ctrl_lock serializes updates to the packet mode enable (ie., the master does not have ctrl_status and the slave does not have packet mode). Thus, claiming the slave's ctrl_lock to access ->packet is useless. Unlocked reads of ->packet are already smp-safe. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6054c16e |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Use spin_lock_irq() for ctrl_lock when interrupts enabled Interrupts are enabled in the n_tty_read() loop, ioctl(TIOCPKT) and pty driver flush_buffer() routine; no need to save and restore local interrupt state. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4d8c1dff |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Use spin_lock_irq() for pty_set_termios() The tty driver's set_termios() method is called with interrupts enabled; there is no need to save and restore the local interrupt state. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
dbfcd851 |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Move pty-specific set_termios() handling to pty driver Packet mode is unique to the pty driver; move the packet mode state change code from the generic tty ioctl handler to the pty driver. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6460fbbf |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
tty: WARN for attempted set_termios() of pty master The pty master's termios should never be set; currently, all code paths which call the driver's set_termios() method ensure that the pty slave's termios is being set. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5b239542 |
|
16-Oct-2014 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Replace open-coded tty_get_pgrp() Replace open-coded instances of tty_get_pgrp(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
01adc807 |
|
10-Sep-2014 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Move packet mode flow control notifications to pty driver When a master pty is set to packet mode, flow control changes to the slave pty cause notifications to the master pty via reads and polls. However, these tests are occurring for all ttys, not just ptys. Implement flow control packet mode notifications in the pty driver. Only the slave side implements the flow control handlers since packet mode is asymmetric; the master pty receives notifications for slave-side changes, but not vice versa. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
07584d4a |
|
12-Jul-2014 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
drivers: tty: Fix use-after-free in pty_common_install In 2c964a2f "drivers: tty: Merge alloc_tty_struct and initialize_tty_struct", I messed up the refactorization of pty_common_install, causing use-after-free and NULL pointer derefs on various error paths. This should fix it. Reported-by: Julia Lawall <julia.lawall@lip6.fr> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2c964a2f |
|
10-Jul-2014 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
drivers: tty: Merge alloc_tty_struct and initialize_tty_struct The two functions alloc_tty_struct and initialize_tty_struct are always called together. Merge them into alloc_tty_struct, updating its prototype and the only two callers of these functions. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
dee4a0be |
|
24-Jul-2013 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Fix lock order in tty_do_resize() Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and 9356b535fcb71db494fc434acceb79f56d15bda2, respectively 'tty: Convert termios_mutex to termios_rwsem' and 'n_tty: Access termios values safely' introduced a circular lock dependency with console_lock and termios_rwsem. The lockdep report [1] shows that n_tty_write() will attempt to claim console_lock while holding the termios_rwsem, whereas tty_do_resize() may already hold the console_lock while claiming the termios_rwsem. Since n_tty_write() and tty_do_resize() do not contend over the same data -- the tty->winsize structure -- correct the lock dependency by introducing a new lock which specifically serializes access to tty->winsize only. [1] Lockdep report ====================================================== [ INFO: possible circular locking dependency detected ] 3.10.0-0+tip-xeon+lockdep #0+tip Not tainted ------------------------------------------------------- modprobe/277 is trying to acquire lock: (&tty->termios_rwsem){++++..}, at: [<ffffffff81452656>] tty_do_resize+0x36/0xe0 but task is already holding lock: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((fb_notifier_list).rwsem){.+.+.+}: [<ffffffff810b6d62>] lock_acquire+0x92/0x1f0 [<ffffffff8175b797>] down_read+0x47/0x5c [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0 [<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320 [<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper] [<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau] [<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau] [<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm] [<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau] [<ffffffff813b13db>] local_pci_probe+0x4b/0x80 [<ffffffff813b1701>] pci_device_probe+0x111/0x120 [<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0 [<ffffffff81497bab>] __driver_attach+0xab/0xb0 [<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0 [<ffffffff814971fe>] driver_attach+0x1e/0x20 [<ffffffff81496cc1>] bus_add_driver+0x111/0x290 [<ffffffff814982b7>] driver_register+0x77/0x170 [<ffffffff813b0454>] __pci_register_driver+0x64/0x70 [<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm] [<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau] [<ffffffff810002ea>] do_one_initcall+0xea/0x1a0 [<ffffffff810c54cb>] load_module+0x123b/0x1bf0 [<ffffffff810c5f57>] SyS_init_module+0xd7/0x120 [<ffffffff817677c2>] system_call_fastpath+0x16/0x1b -> #1 (console_lock){+.+.+.}: [<ffffffff810b6d62>] lock_acquire+0x92/0x1f0 [<ffffffff810430a7>] console_lock+0x77/0x80 [<ffffffff8146b2a1>] con_flush_chars+0x31/0x50 [<ffffffff8145780c>] n_tty_write+0x1ec/0x4d0 [<ffffffff814541b9>] tty_write+0x159/0x2e0 [<ffffffff814543f5>] redirected_tty_write+0xb5/0xc0 [<ffffffff811ab9d5>] vfs_write+0xc5/0x1f0 [<ffffffff811abec5>] SyS_write+0x55/0xa0 [<ffffffff817677c2>] system_call_fastpath+0x16/0x1b -> #0 (&tty->termios_rwsem){++++..}: [<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30 [<ffffffff810b6d62>] lock_acquire+0x92/0x1f0 [<ffffffff8175b724>] down_write+0x44/0x70 [<ffffffff81452656>] tty_do_resize+0x36/0xe0 [<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0 [<ffffffff8146c99f>] vc_resize+0x1f/0x30 [<ffffffff813e4535>] fbcon_init+0x385/0x5a0 [<ffffffff8146a4bc>] visual_init+0xbc/0x120 [<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320 [<ffffffff8146cfa1>] do_take_over_console+0x61/0x70 [<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0 [<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820 [<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110 [<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0 [<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320 [<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper] [<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau] [<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau] [<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm] [<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau] [<ffffffff813b13db>] local_pci_probe+0x4b/0x80 [<ffffffff813b1701>] pci_device_probe+0x111/0x120 [<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0 [<ffffffff81497bab>] __driver_attach+0xab/0xb0 [<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0 [<ffffffff814971fe>] driver_attach+0x1e/0x20 [<ffffffff81496cc1>] bus_add_driver+0x111/0x290 [<ffffffff814982b7>] driver_register+0x77/0x170 [<ffffffff813b0454>] __pci_register_driver+0x64/0x70 [<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm] [<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau] [<ffffffff810002ea>] do_one_initcall+0xea/0x1a0 [<ffffffff810c54cb>] load_module+0x123b/0x1bf0 [<ffffffff810c5f57>] SyS_init_module+0xd7/0x120 [<ffffffff817677c2>] system_call_fastpath+0x16/0x1b other info that might help us debug this: Chain exists of: &tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((fb_notifier_list).rwsem); lock(console_lock); lock((fb_notifier_list).rwsem); lock(&tty->termios_rwsem); *** DEADLOCK *** 7 locks held by modprobe/277: #0: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b5b>] __driver_attach+0x5b/0xb0 #1: (&__lockdep_no_validate__){......}, at: [<ffffffff81497b69>] __driver_attach+0x69/0xb0 #2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa008a6dd>] drm_get_pci_dev+0xbd/0x2a0 [drm] #3: (registration_lock){+.+.+.}, at: [<ffffffff813d93f5>] register_framebuffer+0x25/0x320 #4: (&fb_info->lock){+.+.+.}, at: [<ffffffff813d8116>] lock_fb_info+0x26/0x60 #5: (console_lock){+.+.+.}, at: [<ffffffff813d95a4>] register_framebuffer+0x1d4/0x320 #6: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff8107aac6>] __blocking_notifier_call_chain+0x56/0xc0 stack backtrace: CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012 ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8 ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8 ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007 Call Trace: [<ffffffff81755f19>] dump_stack+0x19/0x1b [<ffffffff8174f506>] print_circular_bug+0x1fb/0x20c [<ffffffff810b65c3>] __lock_acquire+0x1c43/0x1d30 [<ffffffff810b775e>] ? mark_held_locks+0xae/0x120 [<ffffffff810b78d5>] ? trace_hardirqs_on_caller+0x105/0x1d0 [<ffffffff810b6d62>] lock_acquire+0x92/0x1f0 [<ffffffff81452656>] ? tty_do_resize+0x36/0xe0 [<ffffffff8175b724>] down_write+0x44/0x70 [<ffffffff81452656>] ? tty_do_resize+0x36/0xe0 [<ffffffff81452656>] tty_do_resize+0x36/0xe0 [<ffffffff8146c841>] vc_do_resize+0x3e1/0x4c0 [<ffffffff8146c99f>] vc_resize+0x1f/0x30 [<ffffffff813e4535>] fbcon_init+0x385/0x5a0 [<ffffffff8146a4bc>] visual_init+0xbc/0x120 [<ffffffff8146cd13>] do_bind_con_driver+0x163/0x320 [<ffffffff8146cfa1>] do_take_over_console+0x61/0x70 [<ffffffff813e2b93>] do_fbcon_takeover+0x63/0xc0 [<ffffffff813e67a5>] fbcon_event_notify+0x715/0x820 [<ffffffff81762f9d>] notifier_call_chain+0x5d/0x110 [<ffffffff8107aadc>] __blocking_notifier_call_chain+0x6c/0xc0 [<ffffffff8107ab46>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff813d7c0b>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff813d95b2>] register_framebuffer+0x1e2/0x320 [<ffffffffa01043e1>] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper] [<ffffffff8173cbcb>] ? kmemleak_alloc+0x5b/0xc0 [<ffffffff81198874>] ? kmem_cache_alloc_trace+0x104/0x290 [<ffffffffa01035e1>] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper] [<ffffffffa01bcb05>] nouveau_fbcon_init+0x105/0x140 [nouveau] [<ffffffffa01ad0af>] nouveau_drm_load+0x43f/0x610 [nouveau] [<ffffffffa008a79e>] drm_get_pci_dev+0x17e/0x2a0 [drm] [<ffffffffa01ad4da>] nouveau_drm_probe+0x25a/0x2a0 [nouveau] [<ffffffff8175f162>] ? _raw_spin_unlock_irqrestore+0x42/0x80 [<ffffffff813b13db>] local_pci_probe+0x4b/0x80 [<ffffffff813b1701>] pci_device_probe+0x111/0x120 [<ffffffff814977eb>] driver_probe_device+0x8b/0x3a0 [<ffffffff81497bab>] __driver_attach+0xab/0xb0 [<ffffffff81497b00>] ? driver_probe_device+0x3a0/0x3a0 [<ffffffff814956ad>] bus_for_each_dev+0x5d/0xa0 [<ffffffff814971fe>] driver_attach+0x1e/0x20 [<ffffffff81496cc1>] bus_add_driver+0x111/0x290 [<ffffffffa022a000>] ? 0xffffffffa0229fff [<ffffffff814982b7>] driver_register+0x77/0x170 [<ffffffffa022a000>] ? 0xffffffffa0229fff [<ffffffff813b0454>] __pci_register_driver+0x64/0x70 [<ffffffffa008a9da>] drm_pci_init+0x11a/0x130 [drm] [<ffffffffa022a000>] ? 0xffffffffa0229fff [<ffffffffa022a000>] ? 0xffffffffa0229fff [<ffffffffa022a04d>] nouveau_drm_init+0x4d/0x1000 [nouveau] [<ffffffff810002ea>] do_one_initcall+0xea/0x1a0 [<ffffffff810c54cb>] load_module+0x123b/0x1bf0 [<ffffffff81399a50>] ? ddebug_proc_open+0xb0/0xb0 [<ffffffff813855ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff810c5f57>] SyS_init_module+0xd7/0x120 [<ffffffff817677c2>] system_call_fastpath+0x16/0x1b Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5ede5253 |
|
24-Jul-2013 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Remove extra wakeup from pty write() path Acquiring the write_wait queue spin lock now accounts for the largest slice of cpu time on the tty write path. Two factors contribute to this situation; a overly-pessimistic line discipline write loop which _always_ sets up a wait loop even if i/o will immediately succeed, and on ptys, a wakeup storm from reads and writes. Writer wakeup does not need to be performed by the pty driver. Firstly, since the actual i/o is performed within the write, the line discipline write loop will continue while space remains in the flip buffers. Secondly, when space becomes avail in the line discipline receive buffer (and thus also in the flip buffers), the pty unthrottle re-wakes the writer (non-flow-controlled line disciplines unconditionally unthrottle the driver when data is received). Thus, existing in-kernel i/o is guaranteed to advance. Finally, writer wakeup occurs at the conclusion of the line discipline write (in tty_write_unlock()). This guarantees that any user-space write waiters are woken to continue additional i/o. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7bfe0b71 |
|
15-Jun-2013 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Track flip buffer memory limit atomically Lockless flip buffers require atomically updating the bytes-in-use watermark. The pty driver also peeks at the watermark value to limit memory consumption to a much lower value than the default; query the watermark with new fn, tty_buffer_space_avail(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6a1c0680 |
|
15-Jun-2013 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Convert termios_mutex to termios_rwsem termios is commonly accessed unsafely (especially by N_TTY) because the existing mutex forces exclusive access. Convert existing usage. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7c61c3d8 |
|
13-Jun-2013 |
Peter Hurley <peter@hurleysoftware.com> |
tty: Fix transient pty write() EIO Commit 699390354da6c258b65bf8fa79cfd5feaede50b6 ('pty: Ignore slave pty close() if never successfully opened') introduced a bug with ptys whereby a write() in parallel with an open() on an existing pty could mistakenly indicate an I/O error. Only indicate an I/O error if the condition on open() actually exists. Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Mikael Pettersson <mikpe@it.uu.se> Cc: stable <stable@vger.kernel.org> # 3.9 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b0b88565 |
|
01-May-2013 |
Linus Torvalds <torvalds@linux-foundation.org> |
tty: fix up atime/mtime mess, take three We first tried to avoid updating atime/mtime entirely (commit b0de59b5733d: "TTY: do not update atime/mtime on read/write"), and then limited it to only update it occasionally (commit 37b7f3c76595: "TTY: fix atime/mtime regression"), but it turns out that this was both insufficient and overkill. It was insufficient because we let people attach to the shared ptmx node to see activity without even reading atime/mtime, and it was overkill because the "only once a minute" means that you can't really tell an idle person from an active one with 'w'. So this tries to fix the problem properly. It marks the shared ptmx node as un-notifiable, and it lowers the "only once a minute" to a few seconds instead - still long enough that you can't time individual keystrokes, but short enough that you can tell whether somebody is active or not. Reported-by: Simon Kirby <sim@hostway.ca> Acked-by: Jiri Slaby <jslaby@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f4b208eb |
|
14-Apr-2013 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, fix compilation warning When CONFIG_UNIX98_PTYS is unset, we see this warning in pty: drivers/tty/pty.c:409:13: warning: ‘pty_unix98_shutdown’ defined but not used Fix that by moving the function to a section which depends on that config. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Toralf Foerster <toralf.foerster@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
19ffd68f |
|
05-Feb-2013 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Remove redundant itty reset port->itty has already been reset by release_tty() before pty_cleanup() is called. Call stack: release_tty() tty_kref_put() queue_release_one_tty() release_one_tty() : workqueue tty->ops->cleanup() pty_cleanup() Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
80cace72 |
|
29-Jan-2013 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Ignore slave open count for master pty open Multiple slave pty opens may be performed in parallel with the master open. Of course, all the slave opens will fail because the master pty is still locked but during this time the slave pty count will be artificially greater than 1. This is should not cause the master pty open to fail. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
69939035 |
|
29-Jan-2013 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Ignore slave pty close() if never successfully opened If the master and slave ptys are opened in parallel, the slave open fails because the pty is still locked. This is as designed. However, pty_close() is still called for the slave pty which sets TTY_OTHER_CLOSED in the master pty. This can cause the master open to fail as well. Use a common pattern in other tty drivers by setting TTY_IO_ERROR until the open is successful and only closing the pty if not set. Note: the master pty always closes regardless of whether the open was successful, so that proper cleanup can occur. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7acf6cd8 |
|
29-Jan-2013 |
Peter Hurley <peter@hurleysoftware.com> |
pty: Fix BUG()s when ptmx_open() errors out If pmtx_open() fails to get a slave inode or fails the pty_open(), the tty is released as part of the error cleanup. As evidenced by the first BUG stacktrace below, pty_close() assumes that the linked pty has a valid, initialized inode* stored in driver_data. Also, as evidenced by the second BUG stacktrace below, pty_unix98_shutdown() assumes that the master pty's driver_data has been initialized. 1) Fix the invalid assumption in pty_close(). 2) Initialize driver_data immediately so proper devpts fs cleanup occurs. Fixes this BUG: [ 815.868844] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 815.869018] IP: [<ffffffff81207bcc>] devpts_pty_kill+0x1c/0xa0 [ 815.869190] PGD 7c775067 PUD 79deb067 PMD 0 [ 815.869315] Oops: 0000 [#1] PREEMPT SMP [ 815.869443] Modules linked in: kvm_intel kvm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi microcode snd_rawmidi psmouse serio_raw snd_seq_midi_event snd_seq snd_timer$ [ 815.870025] CPU 0 [ 815.870143] Pid: 27819, comm: stress_test_tty Tainted: G W 3.8.0-next-20130125+ttypatch-2-xeon #2 Bochs Bochs [ 815.870386] RIP: 0010:[<ffffffff81207bcc>] [<ffffffff81207bcc>] devpts_pty_kill+0x1c/0xa0 [ 815.870540] RSP: 0018:ffff88007d3e1ac8 EFLAGS: 00010282 [ 815.870661] RAX: ffff880079c20800 RBX: 0000000000000000 RCX: 0000000000000000 [ 815.870804] RDX: ffff880079c209a8 RSI: 0000000000000286 RDI: 0000000000000000 [ 815.870933] RBP: ffff88007d3e1ae8 R08: 0000000000000000 R09: 0000000000000000 [ 815.871078] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88007bfb7e00 [ 815.871209] R13: 0000000000000005 R14: ffff880079c20c00 R15: ffff880079c20c00 [ 815.871343] FS: 00007f2e86206700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 815.871495] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 815.871617] CR2: 0000000000000028 CR3: 000000007ae56000 CR4: 00000000000006f0 [ 815.871752] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 815.871902] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 815.872012] Process stress_test_tty (pid: 27819, threadinfo ffff88007d3e0000, task ffff88007c874530) [ 815.872012] Stack: [ 815.872012] ffff88007bfb7e00 ffff880079c20c00 ffff88007bfb7e00 0000000000000005 [ 815.872012] ffff88007d3e1b08 ffffffff81417be7 ffff88007caa9bd8 ffff880079c20800 [ 815.872012] ffff88007d3e1bc8 ffffffff8140e5f8 0000000000000000 0000000000000000 [ 815.872012] Call Trace: [ 815.872012] [<ffffffff81417be7>] pty_close+0x157/0x170 [ 815.872012] [<ffffffff8140e5f8>] tty_release+0x138/0x580 [ 815.872012] [<ffffffff816d29f3>] ? _raw_spin_lock+0x23/0x30 [ 815.872012] [<ffffffff816d267a>] ? _raw_spin_unlock+0x1a/0x40 [ 815.872012] [<ffffffff816d0178>] ? __mutex_unlock_slowpath+0x48/0x60 [ 815.872012] [<ffffffff81417dff>] ptmx_open+0x11f/0x180 [ 815.872012] [<ffffffff8119394b>] chrdev_open+0x9b/0x1c0 [ 815.872012] [<ffffffff8118d643>] do_dentry_open+0x203/0x290 [ 815.872012] [<ffffffff811938b0>] ? cdev_put+0x30/0x30 [ 815.872012] [<ffffffff8118d705>] finish_open+0x35/0x50 [ 815.872012] [<ffffffff8119dcce>] do_last+0x6fe/0xe90 [ 815.872012] [<ffffffff8119a7af>] ? link_path_walk+0x7f/0x880 [ 815.872012] [<ffffffff810909d5>] ? cpuacct_charge+0x75/0x80 [ 815.872012] [<ffffffff8119e51c>] path_openat+0xbc/0x4e0 [ 815.872012] [<ffffffff816d0fd0>] ? __schedule+0x400/0x7f0 [ 815.872012] [<ffffffff8140e956>] ? tty_release+0x496/0x580 [ 815.872012] [<ffffffff8119ec11>] do_filp_open+0x41/0xa0 [ 815.872012] [<ffffffff816d267a>] ? _raw_spin_unlock+0x1a/0x40 [ 815.872012] [<ffffffff811abe39>] ? __alloc_fd+0xe9/0x140 [ 815.872012] [<ffffffff8118ea44>] do_sys_open+0xf4/0x1e0 [ 815.872012] [<ffffffff8118eb51>] sys_open+0x21/0x30 [ 815.872012] [<ffffffff816da499>] system_call_fastpath+0x16/0x1b [ 815.872012] Code: 0f 1f 80 00 00 00 00 45 31 e4 eb d7 0f 0b 90 0f 1f 44 00 00 55 48 89 e5 48 83 ec 20 48 89 5d e8 48 89 fb 4c 89 65 f0 4c 89 6d f8 <48> 8b 47 28 48 81 78 58 d1 1c 0$ [ 815.872012] RIP [<ffffffff81207bcc>] devpts_pty_kill+0x1c/0xa0 [ 815.872012] RSP <ffff88007d3e1ac8> [ 815.872012] CR2: 0000000000000028 [ 815.897036] ---[ end trace eadf50b7f34e47d5 ]--- Fixes this BUG also: [ 608.366836] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 608.366948] IP: [<ffffffff812078d8>] devpts_kill_index+0x18/0x70 [ 608.367050] PGD 7c75b067 PUD 7b919067 PMD 0 [ 608.367135] Oops: 0000 [#1] PREEMPT SMP [ 608.367201] Modules linked in: kvm_intel kvm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event microcode snd_seq psmouse snd_timer snd_seq_device serio_raw snd mac_hid soundcore snd_page_alloc rfcomm virtio_balloon parport_pc bnep bluetooth ppdev i2c_piix4 lp parport floppy [ 608.367617] CPU 2 [ 608.367669] Pid: 1918, comm: stress_test_tty Tainted: G W 3.8.0-next-20130125+ttypatch-2-xeon #2 Bochs Bochs [ 608.367796] RIP: 0010:[<ffffffff812078d8>] [<ffffffff812078d8>] devpts_kill_index+0x18/0x70 [ 608.367885] RSP: 0018:ffff88007ae41a88 EFLAGS: 00010286 [ 608.367951] RAX: ffffffff81417e80 RBX: ffff880036472400 RCX: 0000000180400028 [ 608.368010] RDX: ffff880036470004 RSI: 0000000000000004 RDI: 0000000000000000 [ 608.368010] RBP: ffff88007ae41a98 R08: 0000000000000000 R09: 0000000000000001 [ 608.368010] R10: ffffea0001f22e40 R11: ffffffff814151d5 R12: 0000000000000004 [ 608.368010] R13: ffff880036470000 R14: 0000000000000004 R15: ffff880036472400 [ 608.368010] FS: 00007ff7a5268700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 [ 608.368010] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 608.368010] CR2: 0000000000000028 CR3: 000000007a0fd000 CR4: 00000000000006e0 [ 608.368010] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 608.368010] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 608.368010] Process stress_test_tty (pid: 1918, threadinfo ffff88007ae40000, task ffff88003688dc40) [ 608.368010] Stack: [ 608.368010] ffff880036472400 0000000000000001 ffff88007ae41aa8 ffffffff81417e98 [ 608.368010] ffff88007ae41ac8 ffffffff8140c42b ffff88007ac73100 ffff88007ac73100 [ 608.368010] ffff88007ae41b98 ffffffff8140ead5 ffff88007ae41b38 ffff88007ca40e40 [ 608.368010] Call Trace: [ 608.368010] [<ffffffff81417e98>] pty_unix98_shutdown+0x18/0x20 [ 608.368010] [<ffffffff8140c42b>] release_tty+0x3b/0xe0 [ 608.368010] [<ffffffff8140ead5>] __tty_release+0x575/0x5d0 [ 608.368010] [<ffffffff816d2c63>] ? _raw_spin_lock+0x23/0x30 [ 608.368010] [<ffffffff816d28ea>] ? _raw_spin_unlock+0x1a/0x40 [ 608.368010] [<ffffffff816d03e8>] ? __mutex_unlock_slowpath+0x48/0x60 [ 608.368010] [<ffffffff8140ef79>] tty_open+0x449/0x5f0 [ 608.368010] [<ffffffff8119394b>] chrdev_open+0x9b/0x1c0 [ 608.368010] [<ffffffff8118d643>] do_dentry_open+0x203/0x290 [ 608.368010] [<ffffffff811938b0>] ? cdev_put+0x30/0x30 [ 608.368010] [<ffffffff8118d705>] finish_open+0x35/0x50 [ 608.368010] [<ffffffff8119dcce>] do_last+0x6fe/0xe90 [ 608.368010] [<ffffffff8119a7af>] ? link_path_walk+0x7f/0x880 [ 608.368010] [<ffffffff8119e51c>] path_openat+0xbc/0x4e0 [ 608.368010] [<ffffffff8119ec11>] do_filp_open+0x41/0xa0 [ 608.368010] [<ffffffff816d28ea>] ? _raw_spin_unlock+0x1a/0x40 [ 608.368010] [<ffffffff811abe39>] ? __alloc_fd+0xe9/0x140 [ 608.368010] [<ffffffff8118ea44>] do_sys_open+0xf4/0x1e0 [ 608.368010] [<ffffffff816d2c63>] ? _raw_spin_lock+0x23/0x30 [ 608.368010] [<ffffffff8118eb51>] sys_open+0x21/0x30 [ 608.368010] [<ffffffff816da719>] system_call_fastpath+0x16/0x1b [ 608.368010] Code: ec 48 83 c4 10 5b 41 5c 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 48 83 ec 10 4c 89 65 f8 41 89 f4 48 89 5d f0 <48> 8b 47 28 48 81 78 58 d1 1c 00 00 74 0b 48 8b 05 4b 66 cf 00 [ 608.368010] RIP [<ffffffff812078d8>] devpts_kill_index+0x18/0x70 [ 608.368010] RSP <ffff88007ae41a88> [ 608.368010] CR2: 0000000000000028 [ 608.394153] ---[ end trace afe83b0fb5fbda93 ]--- Reported-by: Ilya Zykov <ilya@ilyx.ru> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ded2f295 |
|
10-Jan-2013 |
Jiri Slaby <jirislaby@kernel.org> |
pty: return EINVAL for TIOCGPTN for BSD ptys Commit bbb63c514a3464342967237a51a21ea8f61ab951 (drivers:tty:fix up ENOIOCTLCMD error handling) changed the default return value from tty ioctl to be ENOTTY and not EINVAL. This is appropriate. But in case of TIOCGPTN for the old BSD ptys glibc started failing because it expects EINVAL to be returned. Only then it continues to obtain the pts name the other way around. So fix this case by explicit return of EINVAL in this case. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Florian Westphal <fw@strlen.de> Cc: Alan Cox <alan@linux.intel.com> Cc: stable <stable@vger.kernel.org> # 3.7+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b81273a1 |
|
15-Jan-2013 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: do not reset master's packet mode Now that login from util-linux is forced to drop all references to a TTY which it wants to hangup (to reach reference count 1) we are seeing issues with telnet. When login closes its last reference to the slave PTY, it also resets packet mode on the *master* side. And we have a race here. What telnet does is fork+exec of `login'. Then there are two scenarios: * `login' closes the slave TTY and resets thus master's packet mode, but even now telnet properly sets the mode, or * `telnetd' sets packet mode on the master, `login' closes the slave TTY and resets master's packet mode. The former case is OK. However the latter happens in much more cases, by the order of magnitude to be precise. So when one tries to login to such a messed telnet setup, they see the following: inux login: ogin incorrect Note the missing first letters -- telnet thinks it is still in the packet mode, so when it receives "linux login" from `login', it considers "l" as the type of the packet and strips it. SuS does not mention how the implementation should behave. Both BSDs I checked (Free and Net) do not reset the flag upon the last close. By this I am resurrecting an old bug, see References. We are hitting it regularly now, i.e. with updated util-linux, ergo login. Here, I am changing a behavior introduced back in 2.1 times. It would better have a long time testing before goes upstream. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Bryan Mason <bmason@redhat.com> References: https://lkml.org/lkml/2009/11/11/223 References: https://bugzilla.redhat.com/show_bug.cgi?id=504703 References: https://bugzilla.novell.com/show_bug.cgi?id=797042 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b9f8033f |
|
11-Jan-2013 |
Cong Ding <dinggnu@gmail.com> |
tty: cleanup checkpatch warning in pty.c spaces are used for indent in 3 places of tty/pty.c, we change it to tab. Signed-off-by: Cong Ding <dinggnu@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
82f8c35f |
|
11-Jan-2013 |
Cong Ding <dinggnu@gmail.com> |
tty: cleanup the panic message the "\n" in panic message is excess, so we remove it in tty/pty.c as what it is used in other places. Signed-off-by: Cong Ding <dinggnu@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2e124b4a |
|
03-Jan-2013 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: switch tty_flip_buffer_push Now, we start converting tty buffer functions to actually use tty_port. This will allow us to get rid of the need of tty in many call sites. Only tty_port will needed and hence no more tty_port_tty_get in those paths. Now, the one where most of tty_port_tty_get gets removed: tty_flip_buffer_push. IOW we also closed all the races in drivers not using tty_port_tty_get at all yet. Also we move tty_flip_buffer_push declaration from include/linux/tty.h to include/linux/tty_flip.h to all others while we are changing it anyway. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
05c7cd39 |
|
03-Jan-2013 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: switch tty_insert_flip_string Now, we start converting tty buffer functions to actually use tty_port. This will allow us to get rid of the need of tty in many call sites. Only tty_port will needed and hence no more tty_port_tty_get in those paths. tty_insert_flip_string this time. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
159a8e92 |
|
18-Nov-2012 |
Josh Triplett <josh@joshtriplett.org> |
pty: Mark pty_resize static Nothing outside of drivers/tty/pty.c references pty_resize. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
81c79838 |
|
15-Nov-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, fix tty buffers leak After commit "TTY: move tty buffers to tty_port", the tty buffers are not freed in some drivers. This is because tty_port_destructor is not called whenever a tty_port is freed. This was an assumption I counted with but was unfortunately untrue. So fix the drivers to fulfil this assumption. PTY is one of those, here we just need to use tty_port_put instead of kfree. (Assuming tty_port_destructor does not need port->ops to be set which we change here too.) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
84fd7bdf |
|
24-Oct-2012 |
Cyrill Gorcunov <gorcunov@openvz.org> |
tty: Add get- ioctls to fetch tty status v3 For checkpoint/restore we need to know if tty has exclusive or packet mode set, as well as if pty is currently locked. Just to be able to restore this characteristics. For this sake the following ioctl codes are introduced - TIOCGPKT to get packet mode state - TIOCGPTLCK to get Pty locked state - TIOCGEXCL to get Exclusive mode state Note this ioctls are a bit unsafe in terms of data obtained consistency. The tty characteristics might be changed right after ioctl complete. Keep it in mind and use this ioctl carefully. v2: - Use TIOC prefix for ioctl codes (by jslaby@) Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> CC: Alan Cox <alan@lxorguk.ukuu.org.uk> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Pavel Emelyanov <xemul@parallels.com> CC: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
06026d91 |
|
24-Oct-2012 |
Cyrill Gorcunov <gorcunov@openvz.org> |
tty: pty - Move TIOCPKT handling into pty.c Since this ioctl is for pty devices only move it to pty.c. v2: - drop PTY_TYPE_MASTER test since it's master peer ioctl anyway (by jslaby@) Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Pavel Emelyanov <xemul@parallels.com> CC: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ecbbfd44 |
|
18-Oct-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: move tty buffers to tty_port So this is it. The big step why we did all the work over the past kernel releases. Now everything is prepared, so nothing protects us from doing that big step. | | \ \ nnnn/^l | | | | \ / / | | | '-,.__ => \/ ,-` => | '-,.__ | O __.´´) ( .` | O __.´´) ~~~ ~~ `` ~~~ ~~ The buffers are now in the tty_port structure and we can start teaching the buffer helpers (insert char/string, flip etc.) to use tty_port instead of tty_struct all around. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
967fab69 |
|
18-Oct-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: add port -> tty link For that purpose we have to temporarily introduce a second tty back pointer into tty_port. It is because serial layer, and maybe others, still do not use tty_port_tty_set/get. So that we cannot set the tty_port->tty to NULL at will now. Yes, the fix would be to convert whole serial layer and all its users to tty_port_tty_set/get. However we are in the process of removing the need of tty in most of the call sites, so this would lead to a duplicated work. Instead we have now tty_port->itty (internal tty) which will be used only in flush_to_ldisc. For that one it is ensured that itty is valid wherever the work is run. IOW, the work is synchronously cancelled before we set itty to NULL and also before hangup is processed. After we need only tty_port and not tty_struct in most code, this shall be changed to tty_port_tty_set/get and itty removed completely. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fa2ecfc5a |
|
18-Oct-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: move devpts kill to pty Now that we have control over tty->driver_data in pty, we can just kill the /dev/pts/ in pty code too. Namely, in ->shutdown hook of tty. For pty, this is called only once, for whichever end is closed last. But we don't care, both driver_data are the inode as it used to be till now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f11afb61 |
|
18-Oct-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: devpts, do not set driver_data The goal is to stop setting and using tty->driver_data in devpts code. It should be used solely by the driver's code, pty in this case. Now driver_data are managed only in the pty driver. devpts_pty_new is switched to accept what we used to dig out of tty_struct, i.e. device node number and index. This also removes a note about driver_data being set outside of the driver. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
162b97cf |
|
18-Oct-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: devpts, return created inode from devpts_pty_new The goal is to stop setting and using tty->driver_data in devpts code. It should be used solely by the driver's code, pty in this case. For the cleanup of layering, we will need the inode created in devpts_pty_new to be stored into slave's driver_data. So we convert devpts_pty_new to return the inode or an ERR_PTR-encoded error in case of failure. The move of 'inode = new_inode(sb);' from declarators to the code is only cosmetical, but it makes the code easier to read. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8fcbaa2b |
|
18-Oct-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: devpts, don't care about TTY in devpts_get_tty The goal is to stop setting and using tty->driver_data in devpts code. It should be used solely by the driver's code, pty in this case. First, here we remove TTY from devpts_get_tty and rename it to devpts_get_priv. Note we do not remove type safety, we just shift the [implicit] (void *) cast one layer up. index was unused in devpts_get_tty, so remove that from the prototype too. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
05fb79e4 |
|
19-Sep-2012 |
Alan Cox <alan@linux.intel.com> |
pty: Fix locking bug on error path We end up dropping the mutex twice on some errors. We don't want to do that. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c3a6344a |
|
16-Aug-2012 |
Dan Carpenter <dan.carpenter@oracle.com> |
TTY: tty_alloc_driver() returns error pointers We changed these from alloc_tty_driver() to tty_alloc_driver() so the error handling needs to modified to check for IS_ERR() instead of NULL. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
21aca2fa |
|
08-Aug-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, switch to tty_alloc_driver Switch to the new driver allocation interface, as this is one of the special call-sites. Here, we need TTY_DRIVER_DYNAMIC_ALLOC to not allocate tty_driver->ports, cdevs and potentially other structures because we reserve too many lines in pty. Instead, it provides the tty_port<->tty_struct link in tty->ops->install already. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6f9ea7ad |
|
07-Aug-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, stop passing NULL to free_tty_struct In case alloc_tty_struct fails in pty_common_install, we pass NULL to free_tty_struct. This is invalid as the function is not ready to cope with that. And even if it was, it is not nice to do that anyway. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
89c8d91e |
|
08-Aug-2012 |
Alan Cox <alan@linux.intel.com> |
tty: localise the lock The termios and other changes mean the other protections needed on the driver tty arrays should be adequate. Turn it all back on. This contains pieces folded in from the fixes made to the original patches | From: Geert Uytterhoeven <geert@linux-m68k.org> (fix m68k) | From: Paul Gortmaker <paul.gortmaker@windriver.com> (fix cris) | From: Jiri Kosina <jkosina@suze.cz> (lockdep) | From: Eric Dumazet <eric.dumazet@gmail.com> (lockdep) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d155255a |
|
27-Jul-2012 |
Alan Cox <alan@linux.intel.com> |
tty: Fix race in tty release Ian Abbott found that the tty layer would explode with the right set of parallel open and close operations. This is because we race in the handling of tty->drivers->termios[]. Correct this by Making tty_ldisc_release behave like nromal code (takes the lock, does stuff, drops the lock) Drop the tty lock earlier in tty_ldisc_release Taking the tty mutex around the driver->termios update in all cases Adding a WARN_ON to catch future screwups. I also forgot to clean up the pty resources properly. With a pty pair we need to pull both halves out of the tables. Signed-off-by: Alan Cox <alan@linux.intel.com> Tested-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
36b3c070 |
|
17-Jul-2012 |
Alan Cox <alan@linux.intel.com> |
tty: Move the handling of the tty release logic Now that we don't have tty->termios tied to drivers->tty we can untangle the logic here. In addition we can push the removal logic out of the destructor path. At that point we can think about sorting out tty_port and console and all the other ugly hangovers. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
adc8d746 |
|
14-Jul-2012 |
Alan Cox <alan@linux.intel.com> |
tty: move the termios object into the tty This will let us sort out a whole pile of tty related races. The alternative would be to keep points and refcount the termios objects. However 1. They are tiny anyway 2. Many devices don't use the stored copies 3. We can remove a pty special case Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6d31a88c |
|
14-Jul-2012 |
Alan Cox <alan@linux.intel.com> |
tty: revert incorrectly applied lock patch I sent GregKH this after the pre-requisites. He dropped the pre-requesites for good reason and unfortunately then applied this patch. Without this reverted you get random kernel memory corruption which will make bisecting anything between it and the properly applied patches a complete sod. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
79d75320 |
|
11-Jul-2012 |
Dan Carpenter <dan.carpenter@oracle.com> |
tty: double unlock on error in ptmx_open() The problem here is that we called mutex_unlock(&devpts_mutex) on the error path when we weren't holding the lock. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f5e3bcc5 |
|
29-Jun-2012 |
Alan Cox <alan@linux.intel.com> |
tty: localise the lock The termios and other changes mean the other protections needed on the driver tty arrays should be adequate. Turn it all back on. This contains pieces folded in from the fixes made to the original patches | From: Geert Uytterhoeven <geert@linux-m68k.org> (fix m68k) | From: Paul Gortmaker <paul.gortmaker@windriver.com> (fix cris) | From: Jiri Kosina <jkosina@suze.cz> (lockdep) | From: Eric Dumazet <eric.dumazet@gmail.com> (lockdep) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d03702a2 |
|
04-Jun-2012 |
Jiri Slaby <jirislaby@kernel.org> |
PTY: add tty_port This has *no* function in the PTY driver yet. However as the tty buffers will move to the tty_port structure, we will need tty_port for all TTYs in the system, PTY inclusive. For PTYs this is ensured by allocating 2 tty_port's in pty_install, i.e. where the tty->link is allocated. Both tty_port's are properly assigned to each end of the tty. Freeing is done at the same place where tty is freed, i.e. in tty->ops->cleanup. This means BTW that tty_port does not outlive TTY in PTY. This might be a subject to change in the future if we see some problems. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5d249bc6 |
|
04-Jun-2012 |
Jiri Slaby <jirislaby@kernel.org> |
PTY: merge pty_install implementations There are currently two instances of code which handles PTY install. One for the legacy BSD PTY's, one for unix98's PTY's. Both of them are very similar and differ only in termios allocation and handling. Since we will need to allocate a tty_port at that place, this would require editing two places with the same pattern. Instead, let us move the implementation to one common place and call it from both places. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7171604a |
|
04-Jun-2012 |
Jiri Slaby <jirislaby@kernel.org> |
PTY: remove one empty ops->remove Currently, there are two as a left-over from previous patches. Although we really need to provide an empty handler, we do not need two. So remove one of them. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f309532b |
|
02-Jun-2012 |
Linus Torvalds <torvalds@linux-foundation.org> |
tty: Revert the tty locking series, it needs more work This reverts the tty layer change to use per-tty locking, because it's not correct yet, and fixing it will require some more deep surgery. The main revert is d29f3ef39be4 ("tty_lock: Localise the lock"), but there are several smaller commits that built upon it, they also get reverted here. The list of reverted commits is: fde86d310886 - tty: add lockdep annotations 8f6576ad476b - tty: fix ldisc lock inversion trace d3ca8b64b97e - pty: Fix lock inversion b1d679afd766 - tty: drop the pty lock during hangup abcefe5fc357 - tty/amiserial: Add missing argument for tty_unlock() fd11b42e3598 - cris: fix missing tty arg in wait_event_interruptible_tty call d29f3ef39be4 - tty_lock: Localise the lock The revert had a trivial conflict in the 68360serial.c staging driver that got removed in the meantime. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d3ca8b64 |
|
29-May-2012 |
Alan Cox <alan@linux.intel.com> |
pty: Fix lock inversion The ptmx_open path takes the tty and devpts locks in the wrong order because tty_init_dev locks and returns a locked tty. As far as I can tell this is actually safe anyway because the tty being returned is new so nobody can get a reference to lock it at this point. However we don't even need the devpts lock at this point, it's only held as a byproduct of the way the locks were pushe down. Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b1d679af |
|
09-May-2012 |
Alan Cox <alan@linux.intel.com> |
tty: drop the pty lock during hangup In theory we don't need it, in practice we are hitting some ill understood deadlock when we don't drop it. The old code dropped it here so we are not undoing anything problematic for pty. If pty could be unloaded it would be a problem but it can't. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d29f3ef3 |
|
03-May-2012 |
Alan Cox <alan@linux.intel.com> |
tty_lock: Localise the lock In each remaining case the tty_lock is associated with a specific tty. This means we can now lock on a per tty basis. We do need tty_lock_pair() for the pty case. Uglier but still a step in the right direction. [fixed up calls in 3 missing drivers - gregkh] Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d739e65b |
|
03-May-2012 |
Alan Cox <alan@linux.intel.com> |
pty: Lock the devpts bits privately This is a private pty affair, we don't want to tangle it with the tty_lock any more as we know all the other non tty locking is now handled by the vfs so we too can move. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9ffc93f2 |
|
28-Mar-2012 |
David Howells <dhowells@redhat.com> |
Remove all #inclusions of asm/system.h Remove all #inclusions of asm/system.h preparatory to splitting and killing it. Performed with the following command: perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *` Signed-off-by: David Howells <dhowells@redhat.com>
|
#
2f16669d |
|
05-Mar-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: remove re-assignments to tty_driver members All num, magic and owner are set by alloc_tty_driver. No need to re-set them on each allocation site. pti driver sets something different to what it passes to alloc_tty_driver. It is not a bug, since we don't use the lines parameter in any way. Anyway this is fixed, and now we do the right thing. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ce1000dd |
|
24-Feb-2012 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "TTY: pty, remove superfluous ptm test" This reverts commit a50f724a432997321cabb6c9e665c28e34850f78. Sasha reported that this causes problems, so revert it. Cc: Alan Cox <alan@linux.intel.com> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0ef1698e |
|
24-Feb-2012 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "TTY: get rid of BTM around devpts_*" This reverts commit d3bda5298aad98c7a27678bdd0dd9d008ab9e685. Sasha reported that this causes problems, so revert it. Cc: Sasha Levin <levinsasha928@gmail.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d3bda529 |
|
30-Jan-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: get rid of BTM around devpts_* devpts operations are protected by inode mutexes and dentry refcounting. There is no need to hold BTM. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a50f724a |
|
30-Jan-2012 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, remove superfluous ptm test The code looks like: if (tty->driver->subtype == PTY_TYPE_MASTER) { ... if (tty->driver == ptm_driver) But the second if is superfluous because only the ptm_driver is of PTY_TYPE_MASTER subtype. Also we can remove the #if now because devpts_pty_kill is defined as an empty function for non-CONFIG_UNIX98_PTYS configs. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a4834c10 |
|
05-Jan-2012 |
Konstantin Khlebnikov <khlebnikov@openvz.org> |
tty: move pty count limiting into devpts Let's move this stuff to the better place, where we can account pty right in tty-indexes managing code. Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
593a27c4 |
|
05-Jan-2012 |
Konstantin Khlebnikov <khlebnikov@openvz.org> |
tty: cleanup prohibition of direct opening for unix98 pty master cleanup hack added in v2.6.27-3203-g15582d3 comment from that patch: : pty: If the administrator creates a device for a ptmx slave we should not error : : The open path for ptmx slaves is via the ptmx device. Opening them any : other way is not allowed. Vegard Nossum found that previously this was not : the case and mknod foo c 128 42; cat foo would produce nasty diagnostics : : Signed-off-by: Alan Cox <alan@redhat.com> : Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> devpts_get_tty() returns non-null only for inodes on devpts, but there is no inodes for master-devices, /dev/ptmx (/dev/pts/ptmx) is the only way to open them. Thus we can completely forbid lookup for master-devices and eliminate that hack in tty_init_dev() because tty_open() will get EIO from tty_driver_lookup_tty(). Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
484af54d |
|
16-Nov-2011 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, cleanup the pty counting Instead of the hackish way of counting ptys, let's define a specific ->remove hook both from slave and master. And decrease the count only for master. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
1177c0ef |
|
12-Oct-2011 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, release tty in all ptmx_open fail paths Mistakenly, commit 64ba3dc3143d (tty: never hold BTM while getting tty_mutex) switched one fail path in ptmx_open to not free the newly allocated tty. Fix that by jumping to the appropriate place. And rename the labels so that it's clear what is going on there. Introduced-in: v2.6.36-rc2 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: stable <stable@vger.kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
fa90e1c9 |
|
12-Oct-2011 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: make tty_add_file non-failing If tty_add_file fails at the point it is now, we have to revert all the changes we did to the tty. It means either decrease all refcounts if this was a tty reopen or delete the tty if it was newly allocated. There was a try to fix this in v3.0-rc2 using tty_release in 0259894c7 (TTY: fix fail path in tty_open). But instead it introduced a NULL dereference. It's because tty_release dereferences filp->private_data, but that one is set even in our tty_add_file. And when tty_add_file fails, it's still NULL/garbage. Hence tty_release cannot be called there. To circumvent the original leak (and the current NULL deref) we split tty_add_file into two functions, making the latter non-failing. In that case we may do the former early in open, where handling failures is easy. The latter stays as it is now. So there is no change in functionality. The original bug (leak) was introduced by f573bd176 (tty: Remove __GFP_NOFAIL from tty_add_file()). Thanks Dan for reporting this. Later, we may split tty_release into more functions and call only some of them in this fail path instead. (If at all possible.) Introduced-in: v2.6.37-rc2 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
24d406a6 |
|
10-Aug-2011 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: pty, fix pty counting tty_operations->remove is normally called like: queue_release_one_tty ->tty_shutdown ->tty_driver_remove_tty ->tty_operations->remove However tty_shutdown() is called from queue_release_one_tty() only if tty_operations->shutdown is NULL. But for pty, it is not. pty_unix98_shutdown() is used there as ->shutdown. So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never called. This results in invalid pty_count. I.e. what can be seen in /proc/sys/kernel/pty/nr. I see this was already reported at: https://lkml.org/lkml/2009/11/5/370 But it was not fixed since then. This patch is kind of a hackish way. The problem lies in ->install. We allocate there another tty (so-called tty->link). So ->install is called once, but ->remove twice, for both tty and tty->link. The fix here is to count both tty and tty->link and divide the count by 2 for user. And to have ->remove called, let's make tty_driver_remove_tty() global and call that from pty_unix98_shutdown() (tty_operations->shutdown). While at it, let's document that when ->shutdown is defined, tty_shutdown() is not called. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
99edb3d1 |
|
30-Mar-2011 |
Jovi Zhang <bookjovi@gmail.com> |
tty: remove invalid location line in file header remove invalid location line in each file header after location moved from driver/char to driver/tty Signed-off-by: Jovi Zhang <bookjovi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
a9dccddb |
|
23-Mar-2011 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: plug in deinitialize_tty_struct Used the newly introduced deinitialize_tty_struct to properly shut down ldisc. It is intended to fix the Julian's reported problem. He reports that kmemleak checker warns about memory leak: unreferenced object 0xc0e19860 (size 8): comm cat, pid 1226, jiffies 4294919464 (age 287.476s) hex dump (first 8 bytes): 44 de 2d c1 01 00 00 00 D.-..... backtrace: [<c1065a74>] create_object+0x109/0x1ad [<c1063d2b>] kmem_cache_alloc+0x60/0x68 [<c113505c>] tty_ldisc_get+0x54/0x76 [<c11358c9>] tty_ldisc_init+0xa/0x20 [<c1130ab4>] initialize_tty_struct+0x2d/0x1ac [<c1130c8c>] tty_init_dev+0x59/0x10d [<c113136d>] tty_open+0x24a/0x3a2 ... Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Reported-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
c18d77aa |
|
23-Mar-2011 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: unify pty_unix98_install fail path handling Change it so that we call the deinit functions at one place at the end of the function (by gotos). And while at it use some sane label names. This is a preparation for the deinitialization of tty in the next patch. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Julian Anastasov <ja@ssi.bg> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
8a1b8d70 |
|
23-Mar-2011 |
Jiri Slaby <jirislaby@kernel.org> |
TTY: unify pty_install fail path handling Change it so that we call the deinit functions at one place at the end of the function (by gotos). And while at it use some sane label names. This is a preparation for the deinitialization of tty in the next patch. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Julian Anastasov <ja@ssi.bg> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
5edc3413 |
|
25-Jan-2011 |
Arnd Bergmann <arnd@arndb.de> |
drivers: remove extraneous includes of smp_lock.h These were missed the last time I cleaned this up globally, because of code moving around or new code getting merged. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
#
6caa76b7 |
|
14-Feb-2011 |
Alan Cox <alan@linux.intel.com> |
tty: now phase out the ioctl file pointer for good Only oddities here are a couple of drivers that bogusly called the ldisc helpers instead of returning -ENOIOCTLCMD. Fix the bug and the rest goes away. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
96fd7ce5 |
|
04-Nov-2010 |
Greg Kroah-Hartman <gregkh@suse.de> |
TTY: create drivers/tty and move the tty core files there The tty code should be in its own subdirectory and not in the char driver with all of the cruft that is currently there. Based on work done by Arnd Bergmann <arnd@arndb.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|