linux-kernel - Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090820225819.14c70306@lxorguk.ukuu.org.uk>
Date:	Thu, 20 Aug 2009 22:58:19 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
Cc:	Alan Stern <stern@...land.harvard.edu>, Greg KH <greg@...ah.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while
 in use

> > +	/* For reasons that have been lost in antiquity, the TTY
> > layer calls
> > +	 * our close method even if the open call fails.  Hence we
> > must not
> > +	 * drop the reference obtained by usb_serial_get_by_index().

Not lost in antiquity:

The logic is this

	open
	do some opening work
	block on carrier
						HANGUP
	open returns error

	cleanup still required

So the tty layer always went that way so that the awkward cases around an
opening failing with a hangup just go away. For the normal drivers which
basically do

open:
	tty layer open work
		open hardware and set ASYNCB_INITIALIZED
	block for carrier

close:
	if (!hung_up) {
		if initialized
			shutdown()
	}

the USB layer works really hard to be completely different (in part
because the old code simply didn't implement open semantics properly or
hangup correctly - hence things like mgetty fail on them).

The later patches I was working on were trying to get USB serial to the
point where the model was that drv->open/drv->close were the hardware
init/shutdown and did indeed get called in nice matching open/close pairs
and not re-entered or called unserialized.

Nice spot on the ASYNC v ASYNCB bug Alan btw

Alan (the other one)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/