Re: AX25 mkiss interface not deleted when the serial port is removed

[Jean-Christian de Rivaz <jc@eclis.ch>]

Le 30. 09. 15 22:22, Thomas Osterried a écrit :
> Hello,
>
>> Unfortunately the kernel 4.3.0-rc3+ crash the same way. I suspect that the real question is: what in ax25/mkiss make tty_ldisc_hangup() calling tty_ldisc_open() on a serial port that no longer exists, and how to avoid this ?

First, many many thanks for your time investigating this bug.

> that’s a good question ;)
>
> We had a long debug sessions today.
>
> tty_ldisc_hangup() always calls tty_ldisc_reinit(tty, N_TTY)) and tty_ldisc_open(tty, tty->ldisc)).

Conceptually, is there any good reason to call tty_ldisc_reinit() on a 
deleted device ? I would like to propose a check in tty_ldisc_hangup() 
to test if the underlying device still exists. If not the tty can be 
deleted. That said, I don't know enough this kernel part to assert that 
it's a good proposal or not.

In case the call tty_ldisc_reinit() is really needed, it seem to be 
acceptable to use the N_TTY line discipline instead of N_AX25 one. My 
understanding is that this will prevent calling mkiss_open() right after 
the mkiss_close().

> mkiss_close() is supposed to be called, because the old interface disappeared (we have the same number of ax25-interfaces bevor and after the plug).

I remember having traced this, and yes mkiss_close() is called before. I 
don't think there is any issue regarding this.

> After the plug, mkiss_open() is called again, because the ldisc defines:
> static struct tty_ldisc_ops ax_ldisc = { …         .open           = mkiss_open, …}

This is certainly the strangest part. How is that possible since the 
tty_ldisc_reinit() is explicitly called with the N_TTY line discipline 
in argument ? I would expect that tty_ldisc_reinit() will call this instead:

struct tty_ldisc_ops tty_ldisc_N_TTY = { ...    .open            = 
n_tty_open, ...}

I was unable to catch a problem in tty_ldisc_reinit(tty, N_TTY) that 
correctly set tty->ldisc so that the tty_ldisc_open(tty, tty->ldisc) 
must call n_tty_open(). I now suspect that in tty_ldisc_hangup() the 
reset variable is zero so that tty_ldisc_reinit(tty, 
tty->termios.c_line) and tty_ldisc_open(tty, tty->ldisc) are called. At 
this point I think that the bug is that some code is missing to set 
tty->driver->flags |= TTY_DRIVER_RESET_TERMIOS before tty_ldisc_hangup() 
is called.

I fully agree with all the rest of your message, but I believe it 
describes the logical consequences of an earlier problem.

Regards,
Jean-Christian

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html