summaryrefslogtreecommitdiffstats
path: root/drivers/thermal
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2009-09-05 13:27:10 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2009-09-05 13:27:10 -0700
commitac89a9174decf343de049a06fad75681f71890eb (patch)
treec2fa9e7deef47b2cbc6bf4523e068a0265b105ac /drivers/thermal
parent37f81fa1f63ad38e16125526bb2769ae0ea8d332 (diff)
downloadop-kernel-dev-ac89a9174decf343de049a06fad75681f71890eb.zip
op-kernel-dev-ac89a9174decf343de049a06fad75681f71890eb.tar.gz
pty: don't limit the writes to 'pty_space()' inside 'pty_write()'
The whole write-room thing is something that is up to the _caller_ to worry about, not the pty layer itself. The total buffer space will still be limited by the buffering routines themselves, so there is no advantage or need in having pty_write() artificially limit the size somehow. And what happened was that the caller (the n_tty line discipline, in this case) may have verified that there is room for 2 bytes to be written (for NL -> CRNL expansion), and it used to then do those writes as two single-byte writes. And if the first byte written (CR) then caused a new tty buffer to be allocated, pty_space() may have returned zero when trying to write the second byte (LF), and then incorrectly failed the write - leading to a lost newline character. This should finally fix http://bugzilla.kernel.org/show_bug.cgi?id=14015 Reported-by: Mikael Pettersson <mikpe@it.uu.se> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/thermal')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud