linuxconsole-dev

Re: tty_struct curruption

[Andreas S. <an...@sc...>]

ok, some more research, but i still do not understand what really
happens.

the tty_struct which later is found from kdb_keycode and causes
the oops in tty_insert_flip_char() is correctly kfree()d much
earlier, when the tty is shut down at some point. (they seem to
be opened and released all the time for different purposes.)

But in the vc->vc_tty pointer keeps pointing to the old, freed
tty_struct.
where should that pointer be reset, if a tty is released? 

Shouldnt this happen in tty_io.c in release_dev()? this is not
the case in ruby or in Aivils backport to 2.4.

Re: tty_struct curruption

[Aivils S. <Aiv...@un...>]

>ok, some more research, but i still do not understand what really
>happens.
>
>the tty_struct which later is found from kdb_keycode and causes
>the oops in tty_insert_flip_char() is correctly kfree()d much
>earlier, when the tty is shut down at some point. (they seem to
>be opened and released all the time for different purposes.)
>
>But in the vc->vc_tty pointer keeps pointing to the old, freed
>tty_struct.
>where should that pointer be reset, if a tty is released?
>
>Shouldnt this happen in tty_io.c in release_dev()? this is not
>the case in ruby or in Aivils backport to 2.4.

Now understand.

--- drivers/char/vt.c.orig    Mon Sep 23 21:19:26 2002
+++ drivers/char/vt.c    Mon Oct 21 18:46:36 2002
@@ -1277,11 +1277,14 @@ static int vt_open(struct tty_struct *tt

 static void vt_close(struct tty_struct *tty, struct file *filp)
 {
+        struct vc_data *vc;
     if (!tty)
          return;
     if (tty->count != 1)
          return;
     vcs_make_devfs(minor(tty->device), 1);
+    vc = (struct vc_data *) tty->driver_data;
+    vc->vc_tty = NULL;
     tty->driver_data = 0;
 }

James Simons
Current ruby CVS call vt_map_input() vt.c any time when keyboard pluged
into box.
If user plug USB keyboard multiple times in vt_map_input() vty_driver
allocated
again and again, called from kbd_connect() keyboard.c.

Your sugestion?
1) Free vty_driver in the kbd_disconnect()
or
2) ignore vt_map_input() second call from kbd_connect() if vty_driver
already
allocated for this VT.
Me like 2) because VT never released.

Aivils Stoss

Re: tty_struct curruption

[Andreas S. <an...@sc...>]

* Aivils Stoss (Aiv...@un...) [021024 09:51]:
> 
> Andreas wrote:
> >> >> Now understand.
> >> >>
> >> >
> >> >COOL! that fixed it, actually.
> >
> >it fixed the oops.
> >
> >however, that bug had the side effect that the kbd_event()
> >function returns immediatly without calling kbd_keycode() any
> >more, because
> >if (!vt->fg_console->vc_tty) return;
> >
> >we did set the vc->vc_tty=NULL in vt_close, after all.
> >
> >So it would be better to actually find a free tty (from the
> >vty_driver->table, which holds all the vt`s ttys. Are they
> >intendet for this purpose?).
> >
> >so how does one recognize a free tty?
> 
> I mistake.  keyboard.c is vc->vc_tty == NULL safe.

that actually fixes that oops, but it does create other funnies,
which make me think that it would be necessary to differentiat a
little more. for me this change made the first vc (vc0) on VT0
dissapear. as one result the shifting through the VCs with
ALT-Left and ALT-Right does now end at vt6 and vt1. vt7 and vt0
became invalid. this is checked for in vt_callback, where the
actual switching happens.

Again, i think this needs to be initialized properly. I have
stared at the VC, TTY and VT code for some time now but do not
understand how this would be initialized correctly in vt_close.
Do we need some check if we are closing a tty which is associated
to the VCs? I have the code for tty paranoia checking compiled in
and if it works correctly this should be caught in relese_dev in
tty_io.c. 

on other switching bug is in fn_dec_console fn_inc_console in
keyboard.c. this surfaces when we try the console switching on
a dumb VT. strangly i get an oops only if decrementing (alt-left)
the vc, eventhough it should trigger the same error in
incrementing the console. again, this is an initialisation issue,
because find_vc return a nullpointer if the tty/vc is not
initialised correctly. This nullpointer would get dereferenced in
set_console() and that causes the oops.

James, could you write something up about the initialisation
strategy and stuff?

attached find some obvious fixes for vt.c. non of these address
the issues mentioned above.