<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>i.MX ProcessorsのトピックKernel crash due to imx_rpmsg_tty write attempt after rpmsg channel is removed</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/Kernel-crash-due-to-imx-rpmsg-tty-write-attempt-after-rpmsg/m-p/1556530#M197710</link>
    <description>&lt;P&gt;I have detected a kernel crash situation when using the imx_rpmsg_tty driver to communicate with the M7 co-processor, resulting in my application being hanged forever (kill -9 does not work), and the whole system is unable to reboot.&lt;/P&gt;&lt;P&gt;How to reproduce:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;A firmware running on the M7 that keeps sending data to the Linux through RPMsg-Lite&lt;/LI&gt;&lt;LI&gt;An application receiving the data from the M7 by opening and reading the corresponding ttyRPMSG (one can use minicom or so)&lt;/LI&gt;&lt;LI&gt;Stop the M7 by running "echo stop &amp;gt; /sys/class/remoteproc/remoteproc0/state"&lt;/LI&gt;&lt;LI&gt;The tty file is still opened in the application, attempting to write will cause the crash (hit enter on the minicom screen for example)&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;[full trace log attached]&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;Call trace:&lt;BR /&gt;tty_buffer_flush+0x48/0x100&lt;BR /&gt;tty_ldisc_flush+0x3c/0x84&lt;BR /&gt;tty_port_close_start.part.0+0xc4/0x1d0&lt;BR /&gt;tty_port_close+0x40/0xcc&lt;BR /&gt;rpmsgtty_close+0x1c/0x30 [imx_rpmsg_tty]&lt;BR /&gt;tty_release+0x138/0x61c&lt;BR /&gt;__fput+0x78/0x230&lt;BR /&gt;____fput+0x10/0x20&lt;BR /&gt;task_work_run+0x80/0x140&lt;BR /&gt;do_exit+0x32c/0xa04&lt;BR /&gt;die+0x21c/0x260&lt;BR /&gt;die_kernel_fault+0x64/0x7c&lt;BR /&gt;__do_kernel_fault+0x11c/0x160&lt;BR /&gt;do_translation_fault+0x54/0xd0&lt;BR /&gt;do_mem_abort+0x44/0xa4&lt;BR /&gt;el1_abort+0x74/0xdc&lt;BR /&gt;el1_sync_handler+0xac/0xd0&lt;BR /&gt;el1_sync+0x88/0x140&lt;BR /&gt;dev_driver_string+0x10/0x40&lt;BR /&gt;rpmsg_send_offchannel_raw+0x3d8/0x4b0&lt;BR /&gt;virtio_rpmsg_send+0x28/0x34&lt;BR /&gt;rpmsg_send+0x24/0x44&lt;BR /&gt;rpmsgtty_write+0x60/0xe0 [imx_rpmsg_tty]&lt;BR /&gt;n_tty_write+0x2b0/0x45c&lt;BR /&gt;file_tty_write.constprop.0+0x138/0x290&lt;BR /&gt;tty_write+0x14/0x20&lt;BR /&gt;new_sync_write+0xe8/0x184&lt;BR /&gt;vfs_write+0x244/0x2a4&lt;BR /&gt;ksys_write+0x68/0xf4&lt;BR /&gt;__arm64_sys_write+0x20/0x2c&lt;BR /&gt;el0_svc_common.constprop.0+0x80/0x240&lt;BR /&gt;do_el0_svc+0x24/0x90&lt;BR /&gt;el0_svc+0x14/0x20&lt;BR /&gt;el0_sync_handler+0x1a4/0x1b0&lt;BR /&gt;el0_sync+0x180/0x1c0&lt;BR /&gt;Code: 9100a298 aa1803e0 94248c10 f9400280 (c8dffc13)&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;So I dug a bit and it seems to me that this should be handled by the imx_rpmsg_tty driver, as it is the driver that receives a notification of the rpmsg driver being removed and is also able to prevent further writes on that channel. In fact I actually implemented some workaround using a global variable to hold the channel state to avoid this and it seemed to be working, though does not look ideal [patch attached].&lt;/P&gt;&lt;P&gt;Would be really nice to hear opinions from maintainers on how to address and fix this properly&lt;/P&gt;&lt;P&gt;Additional information:&lt;/P&gt;&lt;P&gt;Processor: IMX8MP&lt;/P&gt;&lt;P&gt;Board: Variscite VAR-SOM-IMX8M-PLUS&lt;/P&gt;&lt;P&gt;root@imx8mp-var-dart:~# uname -a&lt;BR /&gt;Linux imx8mp-var-dart 5.10.72+gd2cfea0c171e #1 SMP PREEMPT Thu Jul 14 16:54:09 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux&lt;/P&gt;&lt;DIV class=""&gt;&amp;nbsp;&lt;/DIV&gt;</description>
    <pubDate>Fri, 18 Nov 2022 14:41:03 GMT</pubDate>
    <dc:creator>btessele</dc:creator>
    <dc:date>2022-11-18T14:41:03Z</dc:date>
    <item>
      <title>Kernel crash due to imx_rpmsg_tty write attempt after rpmsg channel is removed</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Kernel-crash-due-to-imx-rpmsg-tty-write-attempt-after-rpmsg/m-p/1556530#M197710</link>
      <description>&lt;P&gt;I have detected a kernel crash situation when using the imx_rpmsg_tty driver to communicate with the M7 co-processor, resulting in my application being hanged forever (kill -9 does not work), and the whole system is unable to reboot.&lt;/P&gt;&lt;P&gt;How to reproduce:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;A firmware running on the M7 that keeps sending data to the Linux through RPMsg-Lite&lt;/LI&gt;&lt;LI&gt;An application receiving the data from the M7 by opening and reading the corresponding ttyRPMSG (one can use minicom or so)&lt;/LI&gt;&lt;LI&gt;Stop the M7 by running "echo stop &amp;gt; /sys/class/remoteproc/remoteproc0/state"&lt;/LI&gt;&lt;LI&gt;The tty file is still opened in the application, attempting to write will cause the crash (hit enter on the minicom screen for example)&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;[full trace log attached]&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;Call trace:&lt;BR /&gt;tty_buffer_flush+0x48/0x100&lt;BR /&gt;tty_ldisc_flush+0x3c/0x84&lt;BR /&gt;tty_port_close_start.part.0+0xc4/0x1d0&lt;BR /&gt;tty_port_close+0x40/0xcc&lt;BR /&gt;rpmsgtty_close+0x1c/0x30 [imx_rpmsg_tty]&lt;BR /&gt;tty_release+0x138/0x61c&lt;BR /&gt;__fput+0x78/0x230&lt;BR /&gt;____fput+0x10/0x20&lt;BR /&gt;task_work_run+0x80/0x140&lt;BR /&gt;do_exit+0x32c/0xa04&lt;BR /&gt;die+0x21c/0x260&lt;BR /&gt;die_kernel_fault+0x64/0x7c&lt;BR /&gt;__do_kernel_fault+0x11c/0x160&lt;BR /&gt;do_translation_fault+0x54/0xd0&lt;BR /&gt;do_mem_abort+0x44/0xa4&lt;BR /&gt;el1_abort+0x74/0xdc&lt;BR /&gt;el1_sync_handler+0xac/0xd0&lt;BR /&gt;el1_sync+0x88/0x140&lt;BR /&gt;dev_driver_string+0x10/0x40&lt;BR /&gt;rpmsg_send_offchannel_raw+0x3d8/0x4b0&lt;BR /&gt;virtio_rpmsg_send+0x28/0x34&lt;BR /&gt;rpmsg_send+0x24/0x44&lt;BR /&gt;rpmsgtty_write+0x60/0xe0 [imx_rpmsg_tty]&lt;BR /&gt;n_tty_write+0x2b0/0x45c&lt;BR /&gt;file_tty_write.constprop.0+0x138/0x290&lt;BR /&gt;tty_write+0x14/0x20&lt;BR /&gt;new_sync_write+0xe8/0x184&lt;BR /&gt;vfs_write+0x244/0x2a4&lt;BR /&gt;ksys_write+0x68/0xf4&lt;BR /&gt;__arm64_sys_write+0x20/0x2c&lt;BR /&gt;el0_svc_common.constprop.0+0x80/0x240&lt;BR /&gt;do_el0_svc+0x24/0x90&lt;BR /&gt;el0_svc+0x14/0x20&lt;BR /&gt;el0_sync_handler+0x1a4/0x1b0&lt;BR /&gt;el0_sync+0x180/0x1c0&lt;BR /&gt;Code: 9100a298 aa1803e0 94248c10 f9400280 (c8dffc13)&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;So I dug a bit and it seems to me that this should be handled by the imx_rpmsg_tty driver, as it is the driver that receives a notification of the rpmsg driver being removed and is also able to prevent further writes on that channel. In fact I actually implemented some workaround using a global variable to hold the channel state to avoid this and it seemed to be working, though does not look ideal [patch attached].&lt;/P&gt;&lt;P&gt;Would be really nice to hear opinions from maintainers on how to address and fix this properly&lt;/P&gt;&lt;P&gt;Additional information:&lt;/P&gt;&lt;P&gt;Processor: IMX8MP&lt;/P&gt;&lt;P&gt;Board: Variscite VAR-SOM-IMX8M-PLUS&lt;/P&gt;&lt;P&gt;root@imx8mp-var-dart:~# uname -a&lt;BR /&gt;Linux imx8mp-var-dart 5.10.72+gd2cfea0c171e #1 SMP PREEMPT Thu Jul 14 16:54:09 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux&lt;/P&gt;&lt;DIV class=""&gt;&amp;nbsp;&lt;/DIV&gt;</description>
      <pubDate>Fri, 18 Nov 2022 14:41:03 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Kernel-crash-due-to-imx-rpmsg-tty-write-attempt-after-rpmsg/m-p/1556530#M197710</guid>
      <dc:creator>btessele</dc:creator>
      <dc:date>2022-11-18T14:41:03Z</dc:date>
    </item>
  </channel>
</rss>

