linux-kernel - Re: [Bisected] [Bug #13821] Replugging USB serial converter uses new device node

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: <20090727172254.GA19576@Pilar.aei.mpg.de>
Date:	Mon, 27 Jul 2009 19:22:54 +0200
From:	"Carlos R. Mafra" <crmafra2@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Ferenc Wagner <wferi@...f.hu>, Greg KH <greg@...ah.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	Kay Sievers <kay.sievers@...y.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [Bisected] [Bug #13821] Replugging USB serial converter uses
	new device node

On Mon 27.Jul'09 at 17:55:25 +0100, Alan Cox wrote:
> > > Another thing to check is whether this patch (not yet merged) fixes it:
> > > 
> > > 	http://marc.info/?l=linux-usb&m=124825571403844&w=2
> > 
> > No, unfortunately it does not fix it. I've just tested it.
> 
> I wouldn't expect it to.
> 
> In the ppp case you have this occuring on an unplug
> 
> 	USB layer
> 		unplug
> 		hangup tty
> 	PPPD
> 		SIGHUP
> 		ouch
> 		log stuff
> 		close down
> 
> However at the same time that PPPD is logging stuff and closing down th
> USB layer is going to see the replug if you just unplug/replug quickly
> and in that case you will get ttyUSB1. That aspect is timing dependant.

Ok, so how long is "quickly" here? During bisection I typically waited ~30 secs 
and there was no pppd listed on 'ps aux' when I reconnected it.

> If everything has closed down and given the port back before you replug
> it you should get ttyUSB0 again.
> #

I don't know what to say. I believe in you, of course, but I am not 
seeing what you expect. For example, after sending the last email
I unplugged it and went back to work until I read this reply of
yours. So I did this,

[mafra@...ar:5-pts-tree-level]$ ls /dev/ttyU*
ls: cannot access /dev/ttyU*: No such file or directory

which is OK, because the stick was not plugged in all this time. So
then I plugged it and got this,

[mafra@...ar:5-pts-tree-level]$ ls /dev/ttyU*
/dev/ttyUSB1  /dev/ttyUSB2

And it took a lot longer than 30 secs this time, more than 5 minutes
for sure (and I don't see anything suspect in the output of 'ps aux').

And the fact that is, reverting your commit made things work under
the same testing conditions.

Do you have any suggestions as to what I should do between unplugging
and plugging it back?
--
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/