- 22 Apr, 2021 26 commits
-
-
Johan Hovold authored
Commit de7053c7 ("tty: serial: rp2: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Kevin Cernekee <cernekee@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-20-johan@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
The rda driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had been removed years before the driver was added by commit c10b1332 ("tty: serial: Add RDA8810PL UART driver"). Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by:
-
Johan Hovold authored
The owl driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had been removed years before the driver was added by commit fc60a8b6 ("tty: serial: owl: Implement console driver"). Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by:
-
Johan Hovold authored
Commit f77232da ("tty: serial: msm: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Johan Hovold authored
Commit fbe543b4 ("Fix a potential issue in mpc52xx uart driver") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by:
-
Johan Hovold authored
The meson driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had already been removed by the time the driver was added by commit ff7693d0 ("ARM: meson: serial: add MesonX SoC on-chip uart driver"). Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by:
-
Johan Hovold authored
Commit 5275ad70 ("tty: serial: mcf: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit ec128510 ("tty: serial: lpc32xx_hs: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit 5faf75d7 ("tty: serial: icom: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit b4d49924 ("tty: serial: bcm63xx: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit 1ecc26bd ("atmel_serial: split the interrupt handler") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by dropping and reacquiring the port lock in the tasklet callback. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Richard Genoud <richard.genoud@gmail.com> Signed-off-by:
-
Johan Hovold authored
Commit 3fa12008 ("tty: serial: arc: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Johan Hovold authored
Commit b16c8e3e ("tty: serial: ar933x: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit 78d34d75 ("tty: serial: apbuart: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by:
-
Johan Hovold authored
Commit ead76f32 ("ARM: 6763/1: pl011: add optional RX DMA to PL011 v2") added RX DMA support and also reproduced the workaround for the infamous low_latency behaviour of tty_flip_buffer_push() by dropping and reacquiring the port lock during receive processing. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Note that the port lock is also dropped in the PIO path (see pl011_rx_chars), but it is not clear whether this is still needed by the DMA code added by the aforementioned commit. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Russell King <linux@armlinux.org.uk> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Johan Hovold authored
Commit 2389b272 ("[ARM] 4417/1: Serial: Fix AMBA drivers locking") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
-
Johan Hovold authored
Commit dd085ed8 ("tty: serial: altera: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Tobias Klauser <tklauser@distanz.ch> Acked-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Johan Hovold authored
Commit 53dd0ba7 ("tty: serial: altera_jtag: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Tobias Klauser <tklauser@distanz.ch> Acked-by:
-
Johan Hovold authored
Commit 67d2bc58 ("Char: mxser_new, fix recursive locking") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/lkml/3018694794025219@wsc.cz/T/#m06b04c640a7b6f41afb3d34a4cf29b1df4935d3aReviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Dario Binacchi authored
Data received during half-duplex transmission must be filtered. If the target device responds quickly, emptying the FIFO at the end of the transmission can erase not only the echo characters but also part of the response message. By keeping the receive interrupt enabled even during transmission, it allows you to filter each echo character and only in a number equal to those transmitted. The issue was generated by a target device that started responding 240us later having received a request in communication at 115200bps. Sometimes, some messages received by the target were missing some of the first bytes. Fixes: 3a13884a ("tty/serial: omap: empty the RX FIFO at the end of half-duplex TX") Signed-off-by:
Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20210418094705.27014-1-dariobin@libero.itSigned-off-by:
-
Dario Binacchi authored
There are rs485 transceivers (e.g. MAX13487E/MAX13488E) which automatically disable or enable the driver and receiver to keep the bus in the correct state. In these cases we don't need a GPIO for flow control. Fixes: 4a0ac0f5 ("OMAP: add RS485 support") Signed-off-by:
-
Johan Hovold authored
Use the uart_unlock_and_check_sysrq() helper to defer sysrq processing until receive processing is done and the port lock has been released. This allows cleaning up the console_write() implementation by not having to work around the recursive sysrq case (by dropping locking completely) and also makes the console code work with PREEMPT_RT by no longer relying on local_irq_save(). Reviewed-by: Valentin Caron<valentin.caron@foss.st.com> Signed-off-by:
-
Johan Hovold authored
When DMA is enabled the receive handler runs in a threaded handler, but the primary handler up until very recently neither disabled interrupts in the device or used IRQF_ONESHOT. This would lead to a deadlock if an interrupt comes in while the threaded receive handler is running under the port lock. Commit ad767681 ("serial: stm32: fix a deadlock condition with wakeup event") claimed to fix an unrelated deadlock, but unfortunately also disabled interrupts in the threaded handler. While this prevents the deadlock mentioned in the previous paragraph it also defeats the purpose of using a threaded handler in the first place. Fix this by making the interrupt one-shot and not disabling interrupts in the threaded handler. Note that (receive) DMA must not be used for a console port as the threaded handler could be interrupted while holding the port lock, something which could lead to a deadlock in case an interrupt handler ends up calling printk. Fixes: ad767681 ("serial: stm32: fix a deadlock condition with wakeup event") Fixes: 34891872 ("serial: stm32: adding dma support") Cc: stable@vger.kernel.org # 4.9 Cc: Alexandre TORGUE <alexandre.torgue@st.com> Cc: Gerald Baeza <gerald.baeza@st.com> Reviewed-by: Valentin Caron<valentin.caron@foss.st.com> Signed-off-by:
-
Johan Hovold authored
The uart_unlock_and_check_sysrq() helper can be used to defer processing of sysrq until the interrupt handler has released the port lock and is about to return. Since commit 81e2073c ("genirq: Disable interrupts for force threaded handlers") interrupt handlers that are not explicitly requested as threaded are always called with interrupts disabled and there is no need to save the interrupt state when taking the port lock. Instead of adding another sysrq helper for when the interrupt state has not needlessly been saved, drop the state parameter from uart_unlock_and_check_sysrq() and update its callers to no longer explicitly disable interrupts in their interrupt handlers. Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Colin Ian King authored
The variable count is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Reviewed-by:
Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210420105718.377086-1-colin.king@canonical.comSigned-off-by:
-
Tetsuo Handa authored
syzbot is reporting hung task due to flood of tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__, port->count); message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from decrementing port->count due to tty_hung_up_p() == true. ---------- #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> int main(int argc, char *argv[]) { int i; int fd[10]; for (i = 0; i < 10; i++) fd[i] = open("/dev/ttyprintk", O_WRONLY); ioctl(fd[0], TIOCVHANGUP); for (i = 0; i < 10; i++) close(fd[i]); close(open("/dev/ttyprintk", O_WRONLY)); return 0; } ---------- When TTY hangup happens, port->count needs to be reset via "struct tty_operations"->hangup callback. [1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6aReported-by:syzbot <syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com> Reported-by:
syzbot <syzbot+3ed715090790806d8b18@syzkaller.appspotmail.com> Tested-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: 24b4b67d ("add ttyprintk driver") Link: https://lore.kernel.org/r/17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jpSigned-off-by:
-
- 15 Apr, 2021 13 commits
-
-
Ulrich Hecht authored
Since the transition to hrtimers there is no more need to set a minimum RX timeout to work around latency issues. Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Ulrich Hecht <uli+renesas@fpond.eu> Link: https://lore.kernel.org/r/20210415093547.21639-1-uli+renesas@fpond.euSigned-off-by:
-
Greg Kroah-Hartman authored
There are a lot of tty-core-only functions that are listed in include/linux/tty.h. Move them to drivers/tty/tty.h so that no one else can accidentally call them or think that they are public functions. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-14-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The flow change and restricted_tty_write() logic is internal to the tty core only, so move it out of the include/linux/tty.h file. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-12-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
No one calls this outside of the tty_io.c file, so mark this static and do not export the symbol anymore. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-11-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
Move the TTY_LOCK_* enums and tty_ldisc lock functions out of the global tty.h into the local header file to clean things up. Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-10-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The functions tty_audit_add_data() and tty_audit_tiocsti() are local to the tty core code, and do not need to be in a "kernel-wide" header file so move them to drivers/tty/tty.h Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210408125134.3016837-9-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
No one is calling this macro, and no one should, so remove it from the .h file. Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Hillf Danton authored
Add the error path for registering tty devices and roll back in case of error in bid to avoid the UAF like the below one reported. Plus syzbot reported general protection fault in cdev_del() on Sep 24, 2020 and both cases are down to the kobject_put() in tty_cdev_add(). ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 8923 at lib/refcount.c:28 refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28 Modules linked in: CPU: 1 PID: 8923 Comm: executor Not tainted 5.12.0-rc5+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x1cf/0x210 -origin/lib/refcount.c:28 Code: 4f ff ff ff e8 32 fa b5 fe 48 c7 c7 3d f8 f6 86 e8 d6 ab c6 fe c6 05 7c 34 67 04 01 48 c7 c7 68 f8 6d 86 31 c0 e8 81 2e 9d fe <0f> 0b e9 22 ff ff ff e8 05 fa b5 fe 48 c7 c7 3e f8 f6 86 e8 a9 ab RSP: 0018:ffffc90001633c60 EFLAGS: 00010246 RAX: 15d08b2e34b77800 RBX: 0000000000000003 RCX: ffff88804c056c80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000003 R08: ffffffff813767aa R09: 0001ffffffffffff R10: 0001ffffffffffff R11: ffff88804c056c80 R12: ffff888040b7d000 R13: ffff88804c206938 R14: ffff88804c206900 R15: ffff888041b18488 FS: 00000000022c9940(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9f9b122008 CR3: 0000000044b4b000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: __refcount_sub_and_test -origin/./include/linux/refcount.h:283 [inline] __refcount_dec_and_test -origin/./include/linux/refcount.h:315 [inline] refcount_dec_and_test -origin/./include/linux/refcount.h:333 [inline] kref_put -origin/./include/linux/kref.h:64 [inline] kobject_put+0x17b/0x180 -origin/lib/kobject.c:753 cdev_del+0x4b/0x50 -origin/fs/char_dev.c:597 tty_unregister_device+0x99/0xd0 -origin/drivers/tty/tty_io.c:3343 gsmld_detach_gsm -origin/drivers/tty/n_gsm.c:2409 [inline] gsmld_close+0x6c/0x140 -origin/drivers/tty/n_gsm.c:2478 tty_ldisc_close -origin/drivers/tty/tty_ldisc.c:488 [inline] tty_ldisc_kill -origin/drivers/tty/tty_ldisc.c:636 [inline] tty_ldisc_release+0x1b6/0x400 -origin/drivers/tty/tty_ldisc.c:809 tty_release_struct+0x19/0xb0 -origin/drivers/tty/tty_io.c:1714 tty_release+0x9ad/0xa00 -origin/drivers/tty/tty_io.c:1885 __fput+0x260/0x4e0 -origin/fs/file_table.c:280 ____fput+0x11/0x20 -origin/fs/file_table.c:313 task_work_run+0x8e/0x110 -origin/kernel/task_work.c:140 tracehook_notify_resume -origin/./include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop -origin/kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x16b/0x1a0 -origin/kernel/entry/common.c:208 __syscall_exit_to_user_mode_work -origin/kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x20/0x40 -origin/kernel/entry/common.c:301 do_syscall_64+0x45/0x80 -origin/arch/x86/entry/common.c:56 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com Reported-and-tested-by:
Hao Sun <sunhao.th@gmail.com> Signed-off-by:
Hillf Danton <hdanton@sina.com> Link: https://lore.kernel.org/r/20210412035758.1974-1-hdanton@sina.comSigned-off-by:
-
Zev Weiss authored
These correspond to the existing lpc_address, sirq, and sirq_polarity sysfs attributes; the second element of aspeed,lpc-interrupts provides a replacement for the deprecated aspeed,sirq-polarity-sense property. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20210412034712.16778-5-zev@bewilderbeest.netSigned-off-by:
-
Zev Weiss authored
These allow describing all the Aspeed VUART attributes currently available via sysfs. aspeed,lpc-interrupts provides a replacement for the deprecated aspeed,sirq-polarity-sense property. Reviewed-by:
Andrew Jeffery <andrew@aj.id.au> Signed-off-by:
-
Zev Weiss authored
This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions out of the sysfs store functions in preparation for adding DT properties that will be poking the same registers. While we're at it, these functions now provide some basic bounds-checking on their arguments. Reviewed-by: -
Zev Weiss authored
This property ties SIRQ polarity to SCU register bits that don't necessarily have any direct relationship to it; the only use of it was removed in commit c82bf6e1 ("ARM: aspeed: g5: Do not set sirq polarity"). Reviewed-by:
Joel Stanley <joel@jms.id.au> Acked-by:
-
- 10 Apr, 2021 1 commit
-
-
Yu Kuai authored
The sparse tool complains as follows: drivers/tty/hvc/hvc_udbg.c:20:19: warning: symbol 'hvc_udbg_dev' was not declared. Should it be static? This symbol is not used outside of hvc_udbg.c, so this commit marks it static. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20210407125826.4139130-1-yukuai3@huawei.comSigned-off-by:
-
