From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753278AbbJBRZc (ORCPT ); Fri, 2 Oct 2015 13:25:32 -0400 Received: from www.eclis.ch ([217.162.2.166]:56963 "EHLO mail.eclis.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979AbbJBRZb (ORCPT ); Fri, 2 Oct 2015 13:25:31 -0400 Message-ID: <560EBE07.70801@eclis.ch> Date: Fri, 02 Oct 2015 19:25:27 +0200 From: Jean-Christian de Rivaz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Thomas Osterried , Greg Kroah-Hartman , Jiri Slaby Cc: Peter Hurley , David Ranch , =?windows-1252?Q?Ralf_B=E4chle_DL5RB?= , 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 References: <20151001073117.GA31401@linux-mips.org> <1443691088-30478-1-git-send-email-jc@eclis.ch> <560D65C7.30707@eclis.ch> <560DBA47.3040907@hurleysoftware.com> <560E40A1.7050002@eclis.ch> <97E87223-A3FF-476E-86F2-AE923D4AB955@osterried.de> <560E8B1C.9030209@eclis.ch> In-Reply-To: <560E8B1C.9030209@eclis.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 02. 10. 15 15:48, Jean-Christian de Rivaz a écrit : > Le 02. 10. 15 12:35, Thomas Osterried a écrit : > >> I also wonder why userspace processes like kissattach do not get a >> signal by the kernel, indicating that the filedescriptor is not valid >> anymore. >> Who’s job would it be to signal, the serial driver’s (slip, ppp, >> mkiss, ..), or ldisc’s? > > It's a complete other problem, not kernel related. The safety of the > kernel cannot depend on a user application closing a file descriptor. > Even if the user application close his file descriptor, process > scheduling can make this delayed long enough to let's a packet reach > the parasitic uninitialized interface and completely crash the system. > This will at best only reduce the race window but do nothing to fix > the real bug. That said, kissattach uses a while (1) { sleep(); } loop > that can be cheaply replaced by a single old select() waiting on the > file descriptor. My understanding is that after the the AX25 > discipline is in place the only event that can happen is that the > descriptor is to be closed. I will test a kissattach patch for this. > > AFAIK tty_ldisc_hangup() already signal EOF to the file descriptor > owner with these lines: > > wake_up_interruptible_poll(&tty->write_wait, POLLOUT); > wake_up_interruptible_poll(&tty->read_wait, POLLIN); > I was completely wrong on this. The kissattach application get no event at all. I tried with select() and poll(). You are right, something is missing in the kernel to notify EOF in the descriptor of a removed serial device when at least the N_AX25 line discipline is used. The EOF is notified correctly at least in the case of the N_TTY line discipline. So your question make sense: who must send the EOF ? Maybe it's the line discipline code. Greg, Jiri, can you give some hint ? Best Regards, Jean-Christian de Rivaz