Skip to content
Snippets Groups Projects
  1. Nov 07, 2005
  2. Nov 06, 2005
  3. Nov 05, 2005
    • Bart Oldeman's avatar
      [PATCH] reset tss->io_bitmap_owner in sys_ioperm() · f912696a
      Bart Oldeman authored
      
      my patch "x86: initialise tss->io_bitmap_owner to something" (commit ID
      d5cd4aad) introduced a problem with a
      program (DOSEMU) that called ioperm after already doing some port i/o.
      
      The problem is that a process switch return causes tss->io_bitmap_base
      to be set to IO_BITMAP_OFFSET so that the fault (that *really* sets the
      io bitmap) never triggers.
      
      This fixes that regression.
      
      Signed-off-by: default avatarBart Oldeman <bartoldeman@users.sourceforge.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f912696a
    • Samuel Thibault's avatar
      [PATCH] Set the vga cursor even when hidden · 88dcb6c4
      Samuel Thibault authored
      
      Some visually impaired people use hardware devices which directly read
      the vga screen. When newt for instance asks to hide the cursor for
      better visual aspect, the kernel puts the vga cursor out of the screen,
      so that the cursor position can't be read by the hardware device. This
      is a great loss for such people.
      
      Here is a patch which uses the same technique as CUR_NONE for hiding the
      cursor while still moving it.
      
      Mario, you should apply it to the speakup kernel for access floppies
      asap. I'll submit a 2.4 patch too.
      
      Signed-off-by: default avatar <samuel.thibault@ens-lyon.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      88dcb6c4
    • Russell King's avatar
      [DRIVER MODEL] Fix sgivwfb · 2c119aa8
      Russell King authored
      
      Statically allocated devices in module data is a potential cause
      of oopsen.  The device may be in use by a userspace process, which
      will keep a reference to the device.  If the module is unloaded,
      the module data will be freed.  Subsequent use of the platform
      device will cause a kernel oops.
      
      Use generic platform device allocation/release code in modules.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2c119aa8
    • Russell King's avatar
      [DRIVER MODEL] Fix gbefb · abbf268a
      Russell King authored
      
      Statically allocated devices in module data is a potential cause
      of oopsen.  The device may be in use by a userspace process, which
      will keep a reference to the device.  If the module is unloaded,
      the module data will be freed.  Subsequent use of the platform
      device will cause a kernel oops.
      
      Use generic platform device allocation/release code in modules.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      abbf268a
    • Russell King's avatar
      [DRIVER MODEL] Fix arcfb · 8d972a96
      Russell King authored
      
      Release code in driver modules is a potential cause of oopsen.
      The device may be in use by a userspace process, which will keep
      a reference to the device.  If the module is unloaded, the module
      text will be freed.  Subsequently, when the last reference is
      dropped, the release code will be called, which no longer exists.
      
      Use generic platform device allocation/release code in modules.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8d972a96
Loading