1. 02 May, 2007 4 commits
    • Avi Kivity's avatar
      KVM: MMU: Fix guest writes to nonpae pde · 1c4b6343
      Avi Kivity authored
      KVM shadow page tables are always in pae mode, regardless of the guest
      setting.  This means that a guest pde (mapping 4MB of memory) is mapped
      to two shadow pdes (mapping 2MB each).
      
      When the guest writes to a pte or pde, we intercept the write and emulate it.
      We also remove any shadowed mappings corresponding to the write.  Since the
      mmu did not account for the doubling in the number of pdes, it removed the
      wrong entry, resulting in a mismatch between shadow page tables and guest
      page tables, followed shortly by guest memory corruption.
      
      This patch fixes the problem by detecting the special case of writing to
      a non-pae pde and adjusting the address and number of shadow pdes zapped
      accordingly.
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAvi Kivity <avi@qumranet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1c4b6343
    • Jiri Kosina's avatar
      HID: zeroing of bytes in output fields is bogus · 68e26a3d
      Jiri Kosina authored
      HID: zeroing of bytes in output fields is bogus
      
      This patch removes bogus zeroing of unused bits in output reports,
      introduced in Simon's patch in commit d4ae650a.
      According to the specification, any sane device should not care
      about values of unused bits.
      
      What is worse, the zeroing is done in a way which is broken and
      might clear certain bits in output reports which are actually
      _used_ - a device that has multiple fields with one value of
      the size 1 bit each might serve as an example of why this is
      bogus - the second call of hid_output_report() would clear the
      first bit of report, which has already been set up previously.
      
      This patch will break LEDs on SpaceNavigator, because this device
      is broken and takes into account the bits which it shouldn't touch.
      The quirk for this particular device will be provided in a separate
      patch.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      68e26a3d
    • Michael S. Tsirkin's avatar
      IB/mthca: Fix data corruption after FMR unmap on Sinai · d44da5e9
      Michael S. Tsirkin authored
      In mthca_arbel_fmr_unmap(), the high bits of the key are masked off.
      This gets rid of the effect of adjust_key(), which makes sure that
      bits 3 and 23 of the key are equal when the Sinai throughput
      optimization is enabled, and so it may happen that an FMR will end up
      with bits 3 and 23 in the key being different.  This causes data
      corruption, because when enabling the throughput optimization, the
      driver promises the HCA firmware that bits 3 and 23 of all memory keys
      will always be equal.
      
      Fix by re-applying adjust_key() after masking the key.
      
      Thanks to Or Gerlitz for reproducing the problem, and Ariel Shahar for
      help in debug.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@dev.mellanox.co.il>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d44da5e9
    • NeilBrown's avatar
      knfsd: Use a spinlock to protect sk_info_authunix · bd862252
      NeilBrown authored
      sk_info_authunix is not being protected properly so the object that
      it points to can be cache_put twice, leading to corruption.
      
      We borrow svsk->sk_defer_lock to provide the protection.  We should probably
      rename that lock to have a more generic name - later.
      
      Thanks to Gabriel for reporting this.
      
      Cc: Greg Banks <gnb@melbourne.sgi.com>
      Cc: Gabriel Barazer <gabriel@oxeva.fr>
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bd862252
  2. 27 Apr, 2007 3 commits
  3. 26 Apr, 2007 2 commits
  4. 25 Apr, 2007 2 commits
  5. 13 Apr, 2007 29 commits