1. 17 Sep, 2010 1 commit
    • NeilBrown's avatar
      md: call md_update_sb even for 'external' metadata arrays. · 126925c0
      NeilBrown authored
      Now that we depend on md_update_sb to clear variable bits in
      mddev->flags (rather than trying not to set them) it is important to
      always call md_update_sb when appropriate.
      
      md_check_recovery has this job but explicitly avoids it for ->external
      metadata arrays.  This is not longer appropraite, or needed.
      
      However we do want to avoid taking the mddev lock if only
      MD_CHANGE_PENDING is set as that is not cleared by md_update_sb for
      external-metadata arrays.
      Reported-by: default avatar"Kwolek, Adam" <adam.kwolek@intel.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      126925c0
  2. 15 Sep, 2010 6 commits
  3. 14 Sep, 2010 4 commits
    • Roland McGrath's avatar
      x86-64, compat: Retruncate rax after ia32 syscall entry tracing · eefdca04
      Roland McGrath authored
      In commit d4d67150, we reopened an old hole for a 64-bit ptracer touching a
      32-bit tracee in system call entry.  A %rax value set via ptrace at the
      entry tracing stop gets used whole as a 32-bit syscall number, while we
      only check the low 32 bits for validity.
      
      Fix it by truncating %rax back to 32 bits after syscall_trace_enter,
      in addition to testing the full 64 bits as has already been added.
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      eefdca04
    • H. Peter Anvin's avatar
      x86-64, compat: Test %rax for the syscall number, not %eax · 36d001c7
      H. Peter Anvin authored
      On 64 bits, we always, by necessity, jump through the system call
      table via %rax.  For 32-bit system calls, in theory the system call
      number is stored in %eax, and the code was testing %eax for a valid
      system call number.  At one point we loaded the stored value back from
      the stack to enforce zero-extension, but that was removed in checkin
      d4d67150.  An actual 32-bit process
      will not be able to introduce a non-zero-extended number, but it can
      happen via ptrace.
      
      Instead of re-introducing the zero-extension, test what we are
      actually going to use, i.e. %rax.  This only adds a handful of REX
      prefixes to the code.
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@kernel.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      36d001c7
    • H. Peter Anvin's avatar
      compat: Make compat_alloc_user_space() incorporate the access_ok() · c41d68a5
      H. Peter Anvin authored
      compat_alloc_user_space() expects the caller to independently call
      access_ok() to verify the returned area.  A missing call could
      introduce problems on some architectures.
      
      This patch incorporates the access_ok() check into
      compat_alloc_user_space() and also adds a sanity check on the length.
      The existing compat_alloc_user_space() implementations are renamed
      arch_compat_alloc_user_space() and are used as part of the
      implementation of the new global function.
      
      This patch assumes NULL will cause __get_user()/__put_user() to either
      fail or access userspace on all architectures.  This should be
      followed by checking the return value of compat_access_user_space()
      for NULL in the callers, at which time the access_ok() in the callers
      can also be removed.
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: James Bottomley <jejb@parisc-linux.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: <stable@kernel.org>
      c41d68a5
    • Guillaume Chazarain's avatar
      HID: fix hiddev's use of usb_find_interface · 8fe294ca
      Guillaume Chazarain authored
      My macbook infrared remote control was broken by commit
      bd25f4dd ("HID: hiddev: use
      usb_find_interface, get rid of BKL").
      
      This device appears in dmesg as:
      apple 0003:05AC:8242.0001: hiddev0,hidraw0: USB HID v1.11 Device
      [Apple Computer, Inc. IR Receiver] on usb-0000:00:1d.2-1/input0
      
      It stopped working as lircd was getting ENODEV when opening /dev/usb/hiddev0.
      
      AFAICS hiddev_driver is a dummy driver so usb_find_interface(&hiddev_driver)
      does not find anything.
      
      The device is associated with the usbhid driver, so let's do
      usb_find_interface(&hid_driver) instead.
      
      $ ls -l /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver
      lrwxrwxrwx 1 root root 0 2010-09-12 16:28 /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver -> ../../../../../../bus/usb/drivers/usbhid
      Signed-off-by: default avatarGuillaume Chazarain <guichaz@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      8fe294ca
  4. 13 Sep, 2010 20 commits
  5. 12 Sep, 2010 9 commits