Commit Graph

8 Commits

Author SHA1 Message Date
Antonino A. Daplas 065d9cac98 [PATCH] vc: Use correct size on buffer copy in vc_resize
In the unlikely case of the new screen width much wider then the old,
use (old_row_size * new_rows) instead of new_screen_size to prevent a
buffer overrun during the copy.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-15 08:24:09 -07:00
Antonino A. Daplas 3b41dc1a3c [PATCH] console: Fix buffer copy on vc resize
On a vc resize, the contents of the old screen buffer are transferred to the
new screenbuffer.  If the new screenbuffer is smaller than the old one, only
the contents from the bottom are copied to new.  If the contents of the old
buffer are located at the top, then the contents will not be copied to the new
buffer resulting in a blank screen.

This bug will happen only if the vc in question is not in the foreground.
Doing an fbset -a or con2fbmap will trigger this bug.

To fix this problem, base the start of the copy from the location of the
current cursor.  If the cursor is near the top of the buffer, copy the
contents at the top, and if the cursor is near the bottom of the buffer, then
copy the contents at the bottom.  In the unlikely case where the new row size
is greater than 2x smaller than the old one, and the cursor is in the middle,
copy 1/2 screenful from the top and bottom of the cursor position.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:58:00 -07:00
Antonino A. Daplas 414edcd32a [PATCH] vt: fix possible memory corruption in complement_pos
Based on a patch from Andr Pereira de Almeida <andre@cachola.com.br>

It might be possible for the saved pointer (*p) to become invalid in
between vc_resizes, so saving the screen offset instead of the screen
pointer is saner.

This bug is very hard to trigger though, but Andre probably did, if he's
submitting this patch.  Anyway, with Andre's patch, it's still possible for
the offsets to be still illegal, if the new screen size is smaller than the
old one.  So I've also added checks if the offsets are still within the
screenbuffer size.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:36 -07:00
Stephane Doyon 2d237c6365 [PATCH] Console blanking locking fix
I've had WARN_CONSOLE_UNLOCKED warnings when calling TIOCLINUX
TIOCL_BLANKSCREEN and TIOCL_UNBLANKSCREEN.

(I'm blind and I use a braille display.  I use those functions to blank my
laptop's screen so people don't read it, and hopefully to conserve power.)

The warnings are from these places:
do_blank_screen at drivers/char/vt.c:2754 (Not tainted)
save_screen at drivers/char/vt.c:575 (Not tainted)
do_unblank_screen at drivers/char/vt.c:2822 (Not tainted)
set_palette at drivers/char/vt.c:2908 (Not tainted)

At a glance I would think the following patch ought to fix that.  Tested on
one machine.  Could you please tell me if this is correct and/or forward
the patch where appropriate...

Signed-off-by: Stephane Doyon <s.doyon@videotron.ca>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:31 -07:00
Paul Mackerras f786648b89 [PATCH] Remove race between con_open and con_close
[ Same race and same patch also by Steven Rostedt <rostedt@goodmis.org> ]

I have a laptop (G3 powerbook) which will pretty reliably hit a race
between con_open and con_close late in the boot process and oops in
vt_ioctl due to tty->driver_data being NULL.

What happens is this: process A opens /dev/tty6; it comes into
con_open() (drivers/char/vt.c) and assign a non-NULL value to
tty->driver_data.  Then process A closes that and concurrently process
B opens /dev/tty6.  Process A gets through con_close() and clears
tty->driver_data, since tty->count == 1.  However, before process A
can decrement tty->count, we switch to process B (e.g. at the
down(&tty_sem) call at drivers/char/tty_io.c line 1626).

So process B gets to run and comes into con_open with tty->count == 2,
as tty->count is incremented (in init_dev) before con_open is called.
Because tty->count != 1, we don't set tty->driver_data.  Then when the
process tries to do anything with that fd, it oopses.

The simple and effective fix for this is to test tty->driver_data
rather than tty->count in con_open.  The testing and setting of
tty->driver_data is serialized with respect to the clearing of
tty->driver_data in con_close by the console_sem.  We can't get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called.  Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.

Signed-off-by: Paul Mackerras <paulus@samba.org>
[ Same patch
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
  in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-27 18:03:42 -07:00
Nishanth Aravamudan 030babac6a [PATCH] vt.c build fix
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-15 09:54:50 -07:00
Jan Beulich cc63b1e12b [PATCH] console blanking oops fix
When significant delays happen during boot (e.g.  with a kernel debugger,
but the problem has also seen in other cases) the timeout for blanking the
console may trigger, but the work scheduler may not have been initialized,
yet.  schedule_work() will oops over the null keventd_wq.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-18 13:33:01 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00