linux-kernel - Re: [PATCH] USB: cdc-acm: Prevent loss of data when filling tty buffer

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]

Date:	Wed, 8 Jun 2011 16:46:26 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Toby Gray <toby.gray@...lvnc.com>
Cc:	Oliver Neukum <oliver@...kum.name>,
	Greg Kroah-Hartman <gregkh@...e.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: cdc-acm: Prevent loss of data when filling tty
 buffer

> This patch adds checking for how many bytes have been inserted into the tty
> buffer and places data which hasn't been inserted into a pending buffer list.
> The pending buffer list is pushed to the tty buffer when the tty unthrottles

I don't think this is the way to tackle it.

If the kernel tty buffer code is shedding data then not only have we
asserted a throttle but 64K has been accumulated or the system is out of
memory.

So the questions to me are:

a) Why is your setup filling 64K in the time it takes the throttle
response to occur

b) Do we care (is the right thing to do to lose bits anyway at that point)

c) What should we do about it in the *general* case

It seems to me either its a cdc-acm specific problem with throttle
response behaviour, or its a general case at very high speed (which seems
more likely). In neither case is adding an extra queue to paper over it
the right solution.

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