1. 15 5月, 2011 2 次提交
    • B
      Further fbcon sanity checking · c590cece
      Bruno Prémont 提交于
      This moves the
      
          if (num_registered_fb == FB_MAX)
                  return -ENXIO;
      
      check _AFTER_ the call to do_remove_conflicting_framebuffers() as this
      would (now in a safe way) allow a native driver to replace the
      conflicting one even if all slots in registered_fb[] are taken.
      
      This also prevents unregistering a framebuffer that is no longer
      registered (vga16f will unregister at module unload time even if the
      frame buffer had been unregistered earlier due to being found
      conflicting).
      Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c590cece
    • L
      fbmem: fix remove_conflicting_framebuffers races · 712f3147
      Linus Torvalds 提交于
      When a register_framebuffer() call results in us removing old
      conflicting framebuffers, the new registration_lock doesn't protect that
      situation.  And we can't just add the same locking to the function,
      because these functions call each other: register_framebuffer() calls
      remove_conflicting_framebuffers, which in turn calls
      unregister_framebuffer for any conflicting entry.
      
      In order to fix it, this just creates wrapper functions around all three
      functions and makes the versions that actually do the work be called
      "do_xxx()", leaving just the wrapper that gets the lock and calls the
      worker function.
      
      So the rule becomes simply that "do_xxxx()" has to be called with the
      lock held, and now do_register_framebuffer() can just call
      do_remove_conflicting_framebuffers(), and that in turn can call
      _do_unregister_framebuffer(), and there is no deadlock, and we can hold
      the registration lock over the whole sequence, fixing the races.
      
      It also makes error cases simpler, and fixes one situation where we
      would return from unregister_framebuffer() without releasing the lock,
      pointed out by Bruno Prémont.
      Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
      Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      712f3147
  2. 12 5月, 2011 2 次提交
    • L
      fbmem: make read/write/ioctl use the frame buffer at open time · c47747fd
      Linus Torvalds 提交于
      read/write/ioctl on a fbcon file descriptor has traditionally used the
      fbcon not when it was opened, but as it was at the time of the call.
      That makes no sense, but the lack of sense is much more obvious now that
      we properly ref-count the usage - it means that the ref-counting doesn't
      actually protect operations we do on the frame buffer.
      
      This changes it to look at the fb_info that we got at open time, but in
      order to avoid using a frame buffer long after it has been unregistered,
      we do verify that it is still current, and return -ENODEV if not.
      Acked-by: NTim Gardner <tim.gardner@canonical.com>
      Tested-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
      Cc: Bruno Prémont <bonbons@linux-vserver.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c47747fd
    • L
      fbcon: add lifetime refcount to opened frame buffers · 698b3682
      Linus Torvalds 提交于
      This just adds the refcount and the new registration lock logic.  It
      does not (for example) actually change the read/write/ioctl routines to
      actually use the frame buffer that was opened: those function still end
      up alway susing whatever the current frame buffer is at the time of the
      call.
      
      Without this, if something holds the frame buffer open over a
      framebuffer switch, the close() operation after the switch will access a
      fb_info that has been free'd by the unregistering of the old frame
      buffer.
      
      (The read/write/ioctl operations will normally not cause problems,
      because they will - illogically - pick up the new fbcon instead.  But a
      switch that happens just as one of those is going on might see problems
      too, the window is just much smaller: one individual op rather than the
      whole open-close sequence.)
      
      This use-after-free is apparently fairly easily triggered by the Ubuntu
      11.04 boot sequence.
      Acked-by: NTim Gardner <tim.gardner@canonical.com>
      Tested-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
      Cc: Bruno Prémont <bonbons@linux-vserver.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      698b3682
  3. 11 5月, 2011 36 次提交