linux-kernel - Re: TTY loosing data with u

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: <4D8B3E61.1090704@realvnc.com>
Date:	Thu, 24 Mar 2011 12:51:45 +0000
From:	Toby Gray <toby.gray@...lvnc.com>
To:	balbi@...com
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Stefan Bigler <stefan.bigler@...mile.com>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: TTY loosing data with u_serial gadget

On 24/03/2011 12:37, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 24, 2011 at 12:07:56PM +0000, Toby Gray wrote:
>> Is this patch missing the changes to tty_buffer.c that were in
>> http://permalink.gmane.org/gmane.linux.usb.general/28976
>>
>> Without the changes to tty_buffer.c to use the value returned from
>> the receive_buf call then doesn't this patch not work correctly?
>>
<snip>
> you are right, thanks for noticing that. Attached is an updated patch.
> I left removal of receive_room out of this patch to prevent too invasive
> change, that can be done on a separate patch.

I've just tried removing receive_room myself and noticed that it is 
still used in flush_to_ldisc to decide if it needs to schedule work to 
be done later:

    if (!tty->receive_room || seen_tail) {
       schedule_work(&tty->buf.work);
       break;
    }

If receive_room is no longer being updated then isn't this the wrong 
thing to do? Shouldn't it check if some data was copied after calling 
receive_buf, and if there wasn't any then it should schedule the work 
and break?

The other query I've got is about the return value from receive_buf. I 
noticed that you've modified some drivers (such as 
bluetooth/hci_ldisc.c) so that they can return error values, such as 
-ENODEV. Won't this cause things to go wrong when flush_to_ldisc and 
paste_selection use the return value without checking for it being negative?

Thank you for your quick reply to my first query, it's appreciated.

Regards,

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