Skip to content

L
linux
Switch branch/tag
  1. 21 Sep, 2010 1 commit
    • Suresh Siddha's avatar
      sched: Fix nohz balance kick · f6c3f168
      Suresh Siddha authored 
      There's a situation where the nohz balancer will try to wake itself:

cpu-x is idle which is also ilb_cpu
got a scheduler tick during idle
and the nohz_kick_needed() in trigger_load_balance() checks for
rq_x->nr_running which might not be zero (because of someone waking a
task on this rq etc) and this leads to the situation of the cpu-x
sending a kick to itself.

And this can cause a lockup.

Avoid this by not marking ourself eligible for kicking.
Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1284400941.2684.19.camel@sbsiddha-MOBL3.sc.intel.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f6c3f168
  3. 15 Sep, 2010 7 commits
  5. 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
  7. 13 Sep, 2010 20 commits
  9. 12 Sep, 2010 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7