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: <20100119155225.GB2104@localhost>
Date:	Tue, 19 Jan 2010 16:52:25 +0100
From:	Johan Hovold <jhovold@...il.com>
To:	Johan Hovold <jhovold@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Oliver Neukum <oliver@...kum.org>,
	Matthew Garrett <mjg59@...f.ucam.org>, dvomlehn@...co.com,
	gregkh@...e.de, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] "USB: use kfifo to buffer usb-generic serial
 writes" causes gobi_loader to hang

> > > The log shows no call to usb_serial_generic_write_room()
> > > Do you consider this a bug in the tty layer?
> > 
> > Actually this all makes sense because of where it was hanging. A reply of
> > 0 to the tty->ops->write will cause it to either return (O_NONBLOCK) or
> > sleep in the n_tty write code waiting for a write_wait wakeup
> > (tty_wakeup(tty))
> > 
> > So the fix does indeed look correct.
> 
> Is it really a fix? If the fifo is already full the write urb should be
> in use and Oliver's patch would amount to only a minor optimisation as
> usb_serial_generic_write_start would return 0 anyway.

So the question seems to be: why doesn't the on-going transfer finish (so
that tty_wakeup is called)?


> drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0
> drivers/usb/serial/usb-serial.c: serial_write - port 0, 29 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 29
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 0 bytes
> into fifo

Writer got woken but fifo is still full so write returns 0 and writer goes
back to sleep.

> drivers/usb/serial/generic.c: usb_serial_generic_write_bulk_callback -
> port 0
> drivers/usb/serial/generic.c: usb_serial_generic_write_start - starting
> IO
> qcserial ttyUSB0: usb_serial_generic_write_start - length = 512, data =
> f0 f8 0a 01 f0 00 0b 01 f0 0c 10 01 f0 38 10 01 f0 0f 22 a0 e3 04 40 92
> e5 1c 30 94 e5 a3 32 a0 e1 7f 3f c3 e3 ff 33 c3 e3 0f 35 c3 e3 0e 12 83
> e2 08 00 91 e5 00 00 50 e3 0a 00 00 0a 0a 20 d0 e5 02 00 52 e3 0d 00 00
> 0a 60 31 91 e5 0a 30 c0 e5 64 21 91 e5 0b 20 c0 e5 38 10 81 e2 44 30 91
> e5 c0 30 c3 e3 44 30 81 e5 04 00 a0 e1 96 fc ff eb 50 31 94 e5 fe df 8d
> e3 03 f0 a0 e1 fe ff ff ea 08 30 94 e5 0a 20 c3 e5 38 20 84 e2 44 30 92
> e5 80 30 83 e3 44 30 82 e5 ea ff ff ea 02 60 a0 e1 01 50 a0 e1 04 d0 4d
> e2 00 70 a0 e1 03 80 a0 e1 4d ff ff eb a5 2f a0 e1 86 30 82 e1 00 00 a0
> e3 2f 20 e0 e3 00 00 8d e5 b2 20 cd e1 00 10 9d e5 03 19 81 e3 00 10 8d
> e5 a6 4f a0 e1 a3 20 a0 e1 84 3f 82 e1 08 20 97 e5 48 30 82 e5 0f 32 a0
> e3 40 10 82 e5 0c 00 82 e5 44 50 82 e5 04 10 93 e5 2c 30 91 e5 e4 00 97
> e5 20 20 9f e5 01 30 83 e3 2c 30 81 e5 80 20 87 e5 50 81 87 e5 10 30 9f
> e5 00 10 a0 e1 0c e0 9f e5 03 f0 a0 e1 fe ff ff ea 20 81 00 f0 8c 89 00
> f0 10 b6 00 f0 0f 32 a0 e3 04 40 93 e5 08 20 94 e5 40 30 92 e5 04 d0 4d
> e2 00 30 8d e5 04 00 a0 e1 5b fc ff eb d1 30 dd e1 00 00 53 e3 03 00 00
> ba 50 31 94 e5 fe df 8d e3 03 f0 a0 e1 fe ff ff ea 04 00 9f e5 73 05 00
> eb f8 ff ff ea 4c 10 01 f0 0f c2 a0 e3 18 40 dc e5 18 d0 4d e2 00 00 54
> e3 0e 60 a0 e1 14 00 8d e5 01 a0 a0 e1 10 20 8d e5 03 90 a0 e1 20 b0 9d
> e5 51 01 00 1a 0f 32 a0 e3 04 80 93 e5 50 26 9f e5 0c 30 98 e5 00 10 92
> e5 01 00 53 e1 00 00 a0 13 01 00 a0 03 00 00 50 e3 41 01 00 0a 14 50 9d
> e5 01 20 75 e2 00 20 a0 33 00 00 52 e3 0d 00 00 1a b4 31 dd e1 3f 00 13
> e3 02 30 a0 e1 03 00 00

New transfer started from completion handler.

> drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0

Writer woken up from completion handler after having started the
next transfer.

> drivers/usb/serial/usb-serial.c: serial_write - port 0, 29 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 29
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 29 bytes
> into fifo
> drivers/usb/serial/usb-serial.c: serial_write - port 0, 2048 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 2048
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 483 bytes
> into fifo
> drivers/usb/serial/usb-serial.c: serial_write - port 0, 1565 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 1565
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 0 bytes
> into fifo

Now there was some room (29 + 483 = 512 bytes bytes just transfered).

> drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback -
> port 0

Waiting forever for on-going transfer to finish...

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ