Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754911Ab1B1PlP (ORCPT ); Mon, 28 Feb 2011 10:41:15 -0500 Received: from mga11.intel.com ([192.55.52.93]:11932 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754264Ab1B1PlN (ORCPT ); Mon, 28 Feb 2011 10:41:13 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.62,240,1297065600"; d="scan'208";a="662182671" Date: Mon, 28 Feb 2011 15:19:43 +0000 From: Alan Cox To: Alan Stern Cc: Jiri Slaby , gregkh@suse.de, , , Subject: Re: [PATCH 1/2] USB: serial/keyspan_pda, fix potential tty NULL dereferences Message-ID: <20110228151943.140546a5@bob.linux.org.uk> In-Reply-To: References: <1298885646-9293-1-git-send-email-jslaby@suse.cz> Organization: Intel X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; 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 Content-Length: 1614 Lines: 38 > I wonder about these changes. Does it makes sense to add this > checking everywhere? A more reasonable approach might be to make > sure that tty_port_tty_get is never called in a context where it > could return NULL. Or would that involve just as much effort, making > work routines and so on check to see whether there's an open TTY > device before doing anything else? The tty is refcounted so it can go away at any time including on another processor parallel to an IRQ happening. The right way to fix it longer term is to get every tty to be using a tty_port (which is something we are close to) and then stuff all the physical device related properties into the tty_port so most rx paths simply don't dereference the tty struct. At that point the lifetime of the relevant objects is the lifetime of the physical port which means the driver can do ref count = 0 disable interrupts free physical port representation & associated tty_port the locking and tty struct use on most of the irq paths can go away for most situations (still needed for some cases like SYSRQ). Unfortunately there is quite a lot to move including the tty buffers, various bits of flow control, wait queues and the like. Possibly even the termios data. At that point we'd only need a tty reference when we actually did the ldisc processing or in exceptional situations. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/