linux-kernel - Re: [PATCH 1/1, v2] usb-use-kfifo-to-buffer-usb-generic-serial-writes.patch

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] [day] [month] [year] [list]

Date:	Sat, 29 Aug 2009 14:56:57 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	David VomLehn <dvomlehn@...co.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	greg@...ah.com
Subject: Re: [PATCH 1/1, v2] usb-use-kfifo-to-buffer-usb-generic-serial-writes.patch

Am Freitag, 28. August 2009 22:01:06 schrieb Alan Cox:
> > It seems propagating errors back to user space appears somewhat
> > problematic, but this is true independent of whether a FIFO is used.
>
> The best I can think of would be to implement socket like behaviour from
> networking. That is
>
> - at the start of a write check for an asynchronous error event
> - if there is one, clear the event and report it
> - if not do the normal write
>
> and keep a single 's**t happened' variable to record such matters.

This looks like an excellent suggestion.

> > > user space writes to device
> > > user space waits for answer
> > >
> > > kernel transfers 1. buffer
> > > system suspension - 2. buffer cannot be transfered,
> > > 	as usb_serial_generic_write_start gets -EPERM
> > > system resumption - 2. buffer is never transmitted,
> > > 	user space times out and reports an error
>
> You would need to handle this in the shutdown - and beyond that you need

Why in shutdown?

> to wait for any FIFO in the device before you power it down.

This is not about powering down. If you power down a usb serial
device this will disconnect it unless you implement reset_resume()
which would therefore be another code path.
This problem arises in STR only.

> Its not really fixable as it isn't transactional and you have no idea if
> the state of the other device also changed. Consider
>
> ATD foo
> oops flight time
> suspend
>
> Arrive in Australia
> resume
> ATD foo
>
> Ouch that was an expensive data call...

As soon as you make the next write the buffered data will go out.
So if we don't know the optimal solution, we can still be consistent,
which would be to start IO after resumption in all cases.

	Regards
		Oliver

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