https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082011-10-14T15:57:02ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #2148: DFBSD v2.13.0.38.g09a36 - Switch to TTY panichttps://bugs.dragonflybsd.org/issues/2148?journal_id=101942011-10-14T15:57:02Zsjg
<ul></ul><p><@tuxillo> I still don't understand why sc_switch_scr() needs to be called locked<br /><@thesjg_> for accesses to sc probably<br /><@tuxillo> thesjg_: so that the values that it checks doesn't change in the mean time?=<br /><@tuxillo> like saying, instead of locking/unlocking in a bunch of places inside sc_switch_scr(), I rather <br />lock the whole thing<br /><@thesjg_> if that's the case.. you can't unlock until around save_kbd_state() in exchange_scr(), but i'm <br />not sure its protecting that<br /><@tuxillo> is that right?<br /><@thesjg_> not even then<br /><@thesjg_> you need to figure out what the lock is protecting for sure<br /><@thesjg_> then you can figure out what to do about it<br /><@tuxillo> yah true<br /><@tuxillo> thesjg_: gonna see where it is used to try to find out why<br /><@thesjg_> it certainly looks like its protecting accesses to the softc<br /><@thesjg_> yeah, it is<br /><@tuxillo> hmm<br /><@thesjg_> so, you need to call kbd_ioctl() without the lock held, but you have two problems there<br /><@thesjg_> save_kbd_state() (maybe update_kbd_state() too) is called with the lock held sometimes, you know <br />that, but you can't just unlock unconditionally until you confirm that it is always called with the lock <br />held<br /><@thesjg_> if its sometimes called with the lock held, sometimes not, you have to sort that out<br /><@thesjg_> also, it passes an argument contained in the protected softc into the ioctl, you need to sort <br />that out<br /><aggelos> thesjg_: back to the freebsd 5.x days? :P<br /><@thesjg_> (make a copy of that member of the softc structure, call the ioctl, copy it back into the <br />structure after you re-acquire the lock on return?)<br /><@thesjg_> aggelos: looks that way<br /><@thesjg_> i'm not sure if the ioctl modifies the arg or just needs it for reference, so you'll have to <br />figure that out<br /><@thesjg_> tuxillo: armed that with info, you should be able to come up with a fix w/o too much pain<br /><aggelos> ok, time to reboot into kubuntu 11.10 :/<br /><@thesjg_> can't help, must sleep :)</p>
<p>^-- for posterity</p> DragonFlyBSD - Bug #2148: DFBSD v2.13.0.38.g09a36 - Switch to TTY panichttps://bugs.dragonflybsd.org/issues/2148?journal_id=101952011-10-14T18:33:45Ztuxillo
<ul></ul><p>From what I've seen in the syscons code, save_kbd_state() and update_kbd_state() <br />are never called with the lock held.</p>
<p>Furthermore, in the console path functions, specifically in sccnputc() I've <br />found this:</p>
<pre><code>scp->status &= ~SLKED;<br />#if 0<br /> /* This can block, illegal in the console path */<br /> update_kbd_state(scp, scp->status, SLKED);<br />#endif</code></pre> DragonFlyBSD - Bug #2148: DFBSD v2.13.0.38.g09a36 - Switch to TTY panichttps://bugs.dragonflybsd.org/issues/2148?journal_id=101972011-10-15T03:40:30Ztuxillo
<ul></ul><p>Sam,</p>
<p>As you already know what's passed to the ioctl is struct keyboard kbd from the <br />softc.</p>
<p>For both atkbd and ukbd that struct's private data (kb_data) is modified. One <br />thing to note is that for both the ioctl function is entirely under a critical <br />section.</p>
<p>Cheers,<br />Antonio Huete</p> DragonFlyBSD - Bug #2148: DFBSD v2.13.0.38.g09a36 - Switch to TTY panichttps://bugs.dragonflybsd.org/issues/2148?journal_id=102132011-10-18T17:43:48Ztuxillo
<ul></ul><p>Fixed in f6ce8b1945431efc69d4d9b9b02f73af98edbe53</p>