From: Peter Hurley <peter@hurleysoftware.com>
To: Jean-Christian de Rivaz <jc@eclis.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
Thomas Osterried <thomas@osterried.de>,
David Ranch <dranch@trinnet.net>,
Ralf Baechle DL5RB <ralf@linux-mips.org>,
linux-hams@trinnet.net, linux-hams@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Force mkiss to reset the line discipline when serial device is removed
Date: Thu, 1 Oct 2015 18:57:11 -0400 [thread overview]
Message-ID: <560DBA47.3040907@hurleysoftware.com> (raw)
In-Reply-To: <560D65C7.30707@eclis.ch>
On 10/01/2015 12:56 PM, Jean-Christian de Rivaz wrote:
> Hi Greg and Jiri,
>
> I try to fix a kernel panic bug related to the AX25 (and probably SLIP) line discipline when the corresponding serial device is removed [1]. I proposed some patches [2] [3] on the linux-hams mailing list but I think there raise more questions about how tty_ldisc_hangup() should work when a serial device is removed [4].
>
> I actually see the following options:
>
> a) Let the specific line discipline set the TTY_DRIVER_RESET_TERMIOS flag in tty->driver as in [2] but this is suspected bad practice [5].
>
> b) Let the specific line discipline set the TTY_OTHER_CLOSED flag in tty and check it in tty_ldisc_hangup() as in [3].
>
> c) Let the specific line discipline set the TTY_LDISC_HALTED flag in tty and check it in tty_ldisc_hangup().
>
> d) Let the specific line discipline set a new flag for that purpose, for example TTY_LDISC_RESET, and check it in tty_ldisc_hangup().
>
> e) Close the tty earlier so that tty_ldisc_reinit() is not even called. Need some advise on how this should be done.
>
> f) That's all wrong, something other need to be changed.
>
> I would appreciate some comments from tty subsystem experts about this issue.
>
> [1] http://www.spinics.net/lists/linux-hams/msg03500.html
The crash reported here appears to be related to how mkiss handles its netdev;
maybe prematurely freeing the tx/rx buffers? I'd relook at how slip handles
netdev teardown.
I don't see a problem with the ACM tty/tty core side of this.
At the time the hangup occurs, there is actually still an ACM tty device.
The line discipline is reinited as a security precaution to prevent a previous
session's data from being visible in the new session. The tty core does not know
at the time the vhangup() occurs that the ACM driver plans to unregister the
tty device.
Don't do any of the things you suggest above.
Regards,
Peter Hurley
next prev parent reply other threads:[~2015-10-01 22:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20151001073117.GA31401@linux-mips.org>
[not found] ` <1443691088-30478-1-git-send-email-jc@eclis.ch>
2015-10-01 16:56 ` Force mkiss to reset the line discipline when serial device is removed Jean-Christian de Rivaz
2015-10-01 22:57 ` Peter Hurley [this message]
2015-10-02 8:30 ` Jean-Christian de Rivaz
2015-10-02 10:35 ` Thomas Osterried
2015-10-02 13:48 ` Jean-Christian de Rivaz
2015-10-02 17:25 ` Jean-Christian de Rivaz
2015-10-02 21:46 ` [PATCH 1/1] Add poll method to mkiss let notify hangup to the user process Jean-Christian de Rivaz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=560DBA47.3040907@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=dranch@trinnet.net \
--cc=gregkh@linuxfoundation.org \
--cc=jc@eclis.ch \
--cc=jslaby@suse.com \
--cc=linux-hams@trinnet.net \
--cc=linux-hams@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=thomas@osterried.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).