Re: [PATCH v2 2/7] serial: qcom-geni: fix shutdown race

[Johan Hovold <johan@kernel.org>]

On Fri, Oct 11, 2024 at 07:30:30AM -0700, Doug Anderson wrote:
> On Thu, Oct 10, 2024 at 11:51 PM Johan Hovold <johan@kernel.org> wrote:
> >
> > > > Not sure how your "console process" works, but this should only happen
> > > > if you do not enable the serial console (console=ttyMSM0) and then try
> > > > to use a polled console (as enabling the console will prevent port
> > > > shutdown from being called).

> > And this is with a Chromium kernel, not mainline?
> 
> Who do you take me for?!?!  :-P :-P :-P Of course it's with mainline.

Heh. Just checking. I was sure about shutdown() not being called when
closing ports, but yeah, you can indeed hit this via hangup() as serial
core was only half-converted over to use the tty port implementation in
2016.

> > If you take a look at tty_port_shutdown() there's a hack in there for
> > consoles that was added back in 2010 and that prevents shutdown() from
> > called for console ports.
> >
> > Put perhaps you manage to hit shutdown() via some other path. Serial
> > core is not yet using tty_port_hangup() so a hangup might trigger
> > that...
> >
> > Could you check that with a dump_stack()?

> lazor-rev9 ~ # stop console-ttyMSM0

> [   68.812702]  qcom_geni_serial_shutdown+0x38/0x110
> [   68.817578]  uart_port_shutdown+0x48/0x68
> [   68.821736]  uart_shutdown+0xcc/0x170
> [   68.825530]  uart_hangup+0x54/0x158
> [   68.829154]  __tty_hangup+0x20c/0x318
> [   68.832954]  tty_vhangup_session+0x20/0x38
> [   68.837195]  disassociate_ctty+0xe8/0x1a8
> [   68.841355]  do_exit+0x10c/0x358
> [   68.844716]  do_group_exit+0x9c/0xa8
> [   68.848441]  get_signal+0x408/0x4d8
> [   68.852071]  do_signal+0xa8/0x770

Thanks for confirming. I see this too when stopping a getty.

> > > Now I (via ssh) drop into the debugger:
> > >
> > > echo g > /proc/sysrq-trigger
> > >
> > > I see the "kgdb" prompt but I can't interact with it because
> > > qcom_geni_serial_shutdown() stopped RX.
> >
> > How about simply amending poll_get_char() so that it enables the
> > receiver if it's not already enabled?
> 
> Yeah, this would probably work.

Seems we should clean up serial core so that it at least behaves
consistently on hangup and close.

Having someone think trough and document how these polled consoles are
supposed to work would also be good and save people modifying these
drivers a lot of work.

If they are restricted to when the console is active, there would be no
need for most of poll_init(), and we already prevent the console from
being shut down on hangup() and close().

And then we now also have the detachable console mess to consider...

Johan