From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753239AbdHNMkG (ORCPT ); Mon, 14 Aug 2017 08:40:06 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:40546 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752893AbdHNMkF (ORCPT ); Mon, 14 Aug 2017 08:40:05 -0400 Date: Mon, 14 Aug 2017 13:39:47 +0100 From: Alan Cox To: Arnd Bergmann Cc: Greg Kroah-Hartman , Jiri Slaby , Linux Kernel Mailing List , Adam Borowski , linux-serial@vger.kernel.org, Peter Hurley , jun.he@linaro.org, graeme.gregory@linaro.org, gema.gomez-solano@linaro.org Subject: Re: Race between release_tty() and vt_disallocate() Message-ID: <20170814133947.37ad1855@alans-desktop> In-Reply-To: References: Organization: Intel Corporation X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > non-pointer value 0x00000028fecaedff. The tty_port belongs to > a vc_data structure, which gets freed after we find that > console_driver->ttys[i]->count is zero in the VT_DISALLOCATE > ioctl. Apparently at the same time, the agetty process owning That wouldn't actually be a safe check. tty->count isn't a simple reference count even if the locking were right. > the tty closes and that leads to tty->count dropping to zero > before we call tty_buffer_cancel_work() on the tty_port that > has now been freed. > > Apparently the locking and/or reference counting between the > two code paths is insufficient, but I don't understand enough > about tty locking to come up with a fix that doesn't break other > things. Please have a look. I'm actually not sure how we can fix this within the current API. The tty port is refcounted (see tty_port_put() and tty_port_tty_get()) so any ioctl would end up returning but the console port resources would not disappear until that tty finally closed down. Calling tty_hangup on the tty for the port will close the tty down, but that in itself is also asynchronous. The only easy way I can think to keep the current semantics would instead be to keep the tty port resources around and indexed somewhere but blackhole input to/output from that port or switching to it and also call tty_hangup if the port has a tty. Alan