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:	Thu, 24 Mar 2011 14:37:11 +0200
From:	Felipe Balbi <balbi@...com>
To:	Toby Gray <toby.gray@...lvnc.com>
Cc:	balbi@...com, 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

Hi,

On Thu, Mar 24, 2011 at 12:07:56PM +0000, Toby Gray wrote:
> On 22/03/2011 08:53, Felipe Balbi wrote:
> >Patch attached, please give it a good round of test as I don't have how
> >to exercise all line disciplines. I ran 100 randconfigs over night and
> >no warnings or erros on that area, at least not that I could see (so
> >many warning while compiling the kernel :-( )
> 
> 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?
> 
> Also with this patch, does the receive_room member of tty_struct have
> any use? As far as I can tell it's also referenced in paste_selection
> in drivers/tty/vt/selection.c. It's the case that past_selection uses
> receive_buf so shouldn't it be updated to use the new return value
> semantics for receive_buf?
> 
> Without modifying tty_buffer.c to not make use of receive_room I
> can't get console terminals to work with this patch. Although I have
> to admit that I've been applying the patch to 2.6.35.3 as that's the
> kernel my development board is currently using, but I can't see any
> immediate reason why the most recent kernel would be any different.
> However I'm still fairly new to the interactions between the various
> bits of tty code and drivers, so I could just be missing an important
> change that's in 2.6.38+.

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.

-- 
balbi

View attachment "0001-tty-make-receive_buf-return-the-amout-of-bytes-receiv.diff" of type "text/x-diff" (26739 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ