DragonFlyBSD

<@tuxillo> I still don't understand why sc_switch_scr() needs to be called locked
<@thesjg_> for accesses to sc probably
<@tuxillo> thesjg_: so that the values that it checks doesn't change in the mean time?=
<@tuxillo> like saying, instead of locking/unlocking in a bunch of places inside sc_switch_scr(), I rather
lock the whole thing
<@thesjg_> if that's the case.. you can't unlock until around save_kbd_state() in exchange_scr(), but i'm
not sure its protecting that
<@tuxillo> is that right?
<@thesjg_> not even then
<@thesjg_> you need to figure out what the lock is protecting for sure
<@thesjg_> then you can figure out what to do about it
<@tuxillo> yah true
<@tuxillo> thesjg_: gonna see where it is used to try to find out why
<@thesjg_> it certainly looks like its protecting accesses to the softc
<@thesjg_> yeah, it is
<@tuxillo> hmm
<@thesjg_> so, you need to call kbd_ioctl() without the lock held, but you have two problems there
<@thesjg_> save_kbd_state() (maybe update_kbd_state() too) is called with the lock held sometimes, you know
that, but you can't just unlock unconditionally until you confirm that it is always called with the lock
held
<@thesjg_> if its sometimes called with the lock held, sometimes not, you have to sort that out
<@thesjg_> also, it passes an argument contained in the protected softc into the ioctl, you need to sort
that out
<aggelos> thesjg_: back to the freebsd 5.x days? :P
<@thesjg_> (make a copy of that member of the softc structure, call the ioctl, copy it back into the
structure after you re-acquire the lock on return?)
<@thesjg_> aggelos: looks that way
<@thesjg_> i'm not sure if the ioctl modifies the arg or just needs it for reference, so you'll have to
figure that out
<@thesjg_> tuxillo: armed that with info, you should be able to come up with a fix w/o too much pain
<aggelos> ok, time to reboot into kubuntu 11.10 :/
<@thesjg_> can't help, must sleep :)

^-- for posterity

From what I've seen in the syscons code, save_kbd_state() and update_kbd_state()
are never called with the lock held.

Furthermore, in the console path functions, specifically in sccnputc() I've
found this:

scp->status &= ~SLKED;
#if 0
        /* This can block, illegal in the console path */
        update_kbd_state(scp, scp->status, SLKED);
#endif

Sam,

As you already know what's passed to the ioctl is struct keyboard kbd from the
softc.

For both atkbd and ukbd that struct's private data (kb_data) is modified. One
thing to note is that for both the ioctl function is entirely under a critical
section.

Cheers,
Antonio Huete

Fixed in f6ce8b1945431efc69d4d9b9b02f73af98edbe53