linux-kernel - Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

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: <20070506174641.0e118546@the-village.bc.nu>
Date:	Sun, 6 May 2007 17:46:41 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Antonino Ingargiola" <tritemio@...il.com>
Cc:	"Oliver Neukum" <oliver@...kum.org>,
	"Paul Fulghum" <paulkf@...rogate.com>,
	linux-usb-users@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial
 possible bug]

> To conclude, the store the *last* N bytes received seems a more
> reasonable policy for the input buffers managed by the kernel. If the

For your use maybe, but it is not the normal behaviour and it is not the
behaviour supported by hardware, which generally buffers the first few
bytes (and some things like Apple localtalk actually rely upon this)

> other policy is used (as tty does), then the kernel should flush all
> the buffers he *can* physically flush, remaining inside the host
> computer of course.

It certainly does no harm to try and do the job as best you can.
-
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/