1. 04 10月, 2010 3 次提交
  2. 30 9月, 2010 2 次提交
  3. 27 9月, 2010 1 次提交
  4. 24 9月, 2010 1 次提交
    • R
      perf, x86: Catch spurious interrupts after disabling counters · 63e6be6d
      Robert Richter 提交于
      Some cpus still deliver spurious interrupts after disabling a
      counter. This caused 'undelivered NMI' messages. This patch
      fixes this. Introduced by:
      
        4177c42a: perf, x86: Try to handle unknown nmis with an enabled PMU
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: gorcunov@gmail.com <gorcunov@gmail.com>
      Cc: fweisbec@gmail.com <fweisbec@gmail.com>
      Cc: ying.huang@intel.com <ying.huang@intel.com>
      Cc: ming.m.lin@intel.com <ming.m.lin@intel.com>
      Cc: yinghai@kernel.org <yinghai@kernel.org>
      Cc: andi@firstfloor.org <andi@firstfloor.org>
      Cc: eranian@google.com <eranian@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20100915162034.GO13563@erda.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      63e6be6d
  5. 23 9月, 2010 5 次提交
  6. 22 9月, 2010 13 次提交
  7. 21 9月, 2010 15 次提交
    • S
      sched: Fix nohz balance kick · f6c3f168
      Suresh Siddha 提交于
      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: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1284400941.2684.19.camel@sbsiddha-MOBL3.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f6c3f168
    • J
      oprofile: Add Support for Intel CPU Family 6 / Model 29 · bb7ab785
      Jiri Olsa 提交于
      This patch adds CPU type detection for dunnington processor (Family 6
      / Model 29) to be identified as core 2 family cpu type (wikipedia
      source).
      
      I tested oprofile on Intel(R) Xeon(R) CPU E7440 reporting itself as
      model 29, and it runs without an issue.
      
      Spec:
      
       http://www.intel.com/Assets/en_US/PDF/specupdate/320336.pdfSigned-off-by: NJiri Olsa <jolsa@redhat.com>
      Acked-by: NAndi Kleen <ak@linux.intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      bb7ab785
    • V
      cfq-iosched: fix a kernel OOPs when usb key is inserted · 180be2a0
      Vivek Goyal 提交于
      Mike reported a kernel crash when a usb key hotplug is performed while all
      kernel thrads are not in a root cgroup and are running in one of the child
      cgroups of blkio controller.
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000002c
      	IP: [<c11c7b08>] cfq_get_queue+0x232/0x412
      	*pde = 00000000
      	Oops: 0000 [#1] PREEMPT
      	last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/host3/scsi_host/host3/uevent
      
      	[..]
      	Pid: 30039, comm: scsi_scan_3 Not tainted 2.6.35.2-fg.roam #1 Volvi2                         /Aspire 4315
      	EIP: 0060:[<c11c7b08>] EFLAGS: 00010086 CPU: 0
      	EIP is at cfq_get_queue+0x232/0x412
      	EAX: f705f9c0 EBX: e977abac ECX: 00000000 EDX: 00000000
      	ESI: f00da400 EDI: f00da4ec EBP: e977a800 ESP: dff8fd00
      	 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      	Process scsi_scan_3 (pid: 30039, ti=dff8e000 task=f6b6c9a0 task.ti=dff8e000)
      	Stack:
      	 00000000 00000000 00000001 01ff0000 f00da508 00000000 f00da524 f00da540
      	<0> e7994940 dd631750 f705f9c0 e977a820 e977ac44 f00da4d0 00000001 f6b6c9a0
      	<0> 00000010 00008010 0000000b 00000000 00000001 e977a800 dd76fac0 00000246
      	Call Trace:
      	 [<c11c7f10>] ? cfq_set_request+0x228/0x34c
      	 [<c11c7ce8>] ? cfq_set_request+0x0/0x34c
      	 [<c11bb3b9>] ? elv_set_request+0xf/0x1c
      	 [<c11bdd51>] ? get_request+0x1ad/0x22f
      	 [<c11bddf2>] ? get_request_wait+0x1f/0x11a
      	 [<c11d013b>] ? kvasprintf+0x33/0x3b
      	 [<c127b537>] ? scsi_execute+0x1d/0x103
      	 [<c127b675>] ? scsi_execute_req+0x58/0x83
      	 [<c127c391>] ? scsi_probe_and_add_lun+0x188/0x7c2
      	 [<c12718c6>] ? attribute_container_add_device+0x15/0xfa
      	 [<c11c95d1>] ? kobject_get+0xf/0x13
      	 [<c126d1db>] ? get_device+0x10/0x14
      	 [<c127be93>] ? scsi_alloc_target+0x217/0x24d
      	 [<c127cbd8>] ? __scsi_scan_target+0x95/0x480
      	 [<c10204eb>] ? dequeue_entity+0x14/0x1fe
      	 [<c1020491>] ? update_curr+0x165/0x1ab
      	 [<c1020491>] ? update_curr+0x165/0x1ab
      	 [<c127d00d>] ? scsi_scan_channel+0x4a/0x76
      	 [<c127d0b0>] ? scsi_scan_host_selected+0x77/0xad
      	 [<c127d13c>] ? do_scan_async+0x0/0x11a
      	 [<c127d137>] ? do_scsi_scan_host+0x51/0x56
      	 [<c127d13c>] ? do_scan_async+0x0/0x11a
      	 [<c127d14a>] ? do_scan_async+0xe/0x11a
      	 [<c127d13c>] ? do_scan_async+0x0/0x11a
      	 [<c10354c5>] ? kthread+0x5e/0x63
      	 [<c1035467>] ? kthread+0x0/0x63
      	 [<c1002af6>] ? kernel_thread_helper+0x6/0x10
      	Code: 44 24 1c 54 83 44 24 18 54 83 fa 03 75 94 8b 06 c7 86 64 02 00 00 01 00 00 00 83 e0 03 09 f0 89 06 8b 44 24 28 8b 90 58 01 00 00 <8b> 42 2c 85 c0 75 03 8b 42 08 8d 54 24 48 52 8d 4c 24 50 51 68
      	EIP: [<c11c7b08>] cfq_get_queue+0x232/0x412 SS:ESP 0068:dff8fd00
      	CR2: 000000000000002c
      	---[ end trace 9a88306573f69b12 ]---
      
      The problem here is that we don't have bdi->dev information available when
      thread does some IO.  Hence when dev_name() tries to access bdi->dev, it
      crashes.
      
      This problem does not happen if kernel threads are in root group as root
      group is statically allocated at device initialization time and we don't
      hit this piece of code.
      
      Fix it by delaying the filling of major and minor number information of
      device in blk_group.  Initially a blk_group is created with 0 as device
      information and this information is filled later once some more IO comes
      in from same group.
      Reported-by: NMike Kazantsev <mk.fraggod@gmail.com>
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      180be2a0
    • B
      block: fix blk_rq_map_kern bio direction flag · a45dc2d2
      Benny Halevy 提交于
      This bug was introduced in 7b6d91da
      "block: unify flags for struct bio and struct request"
      
      Cc: Boaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NBenny Halevy <bhalevy@panasas.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      a45dc2d2
    • D
      cciss: freeing uninitialized data on error path · b0722cb1
      Dan Carpenter 提交于
      The "h->scatter_list" is allocated inside a for loop.  If any of those
      allocations fail, then the rest of the list is uninitialized data.  When
      we free it we should start from the top and free backwards so that we
      don't call kfree() on uninitialized pointers.
      
      Also if the allocation for "h->scatter_list" fails then we would get an
      Oops here.  I should have noticed this when I send: 4ee69851 "cciss:
      handle allocation failure."  but I didn't.  Sorry about that.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      b0722cb1
    • C
      Merge remote branch 'linus' into drm-intel-fixes · db8c076b
      Chris Wilson 提交于
      db8c076b
    • D
      sparc64: Fix race in signal instruction flushing. · 05c5e769
      David S. Miller 提交于
      If another cpu does a very wide munmap() on the signal frame area,
      it can tear down the page table hierarchy from underneath us.
      
      Borrow an idea from the 64-bit fault path's get_user_insn(), and
      disable cross call interrupts during the page table traversal
      to lock them in place while we operate.
      Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05c5e769
    • R
      lguest: update comments to reflect LHCALL_LOAD_GDT_ENTRY. · 9b6efcd2
      Rusty Russell 提交于
      We used to have a hypercall which reloaded the entire GDT, then we
      switched to one which loaded a single entry (to match the IDT code).
      
      Some comments were not updated, so fix them.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reported by: Eviatar Khen <eviatarkhen@gmail.com>
      9b6efcd2
    • A
      virtio: console: Prevent userspace from submitting NULL buffers · 65745422
      Amit Shah 提交于
      A userspace could submit a buffer with 0 length to be written to the
      host.  Prevent such a situation.
      
      This was not needed previously, but recent changes in the way write()
      works exposed this condition to trigger a virtqueue event to the host,
      causing a NULL buffer to be sent across.
      Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      CC: stable@kernel.org
      65745422
    • H
      virtio: console: Fix poll blocking even though there is data to read · 6df7aadc
      Hans de Goede 提交于
      I found this while working on a Linux agent for spice, the symptom I was
      seeing was select blocking on the spice vdagent virtio serial port even
      though there were messages queued up there.
      
      virtio_console's port_fops_poll checks port->inbuf != NULL to determine
      if read won't block. However if an application reads enough bytes from
      inbuf through port_fops_read, to empty the current port->inbuf,
      port->inbuf will be NULL even though there may be buffers left in the
      virtqueue.
      
      This causes poll() to block even though there is data to be read,
      this patch fixes this by using will_read_block(port) instead of the
      port->inbuf != NULL check.
      Signed-off-By: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: stable@kernel.org
      6df7aadc
    • L
      Linux 2.6.36-rc5 · b30a3f62
      Linus Torvalds 提交于
      b30a3f62
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6 · 6b3d2cc4
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6:
        Staging: vt6655: fix buffer overflow
        Revert: "Staging: batman-adv: Adding netfilter-bridge hooks"
      6b3d2cc4
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 · 0c4ab345
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
        USB: musb: MAINTAINERS: Fix my mail address
        USB: serial/mos*: prevent reading uninitialized stack memory
        USB: otg: twl4030: fix phy initialization(v1)
        USB: EHCI: Disable langwell/penwell LPM capability
        usb: musb_debugfs: don't use the struct file private_data field with seq_files
      0c4ab345
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6 · 36ff4a55
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
        serial: mfd: fix bug in serial_hsu_remove()
        serial: amba-pl010: fix set_ldisc
      36ff4a55
    • D
      Staging: vt6655: fix buffer overflow · dd173abf
      Dan Carpenter 提交于
      "param->u.wpa_associate.wpa_ie_len" comes from the user.  We should
      check it so that the copy_from_user() doesn't overflow the buffer.
      
      Also further down in the function, we assume that if
      "param->u.wpa_associate.wpa_ie_len" is set then "abyWPAIE[0]" is
      initialized.  To make that work, I changed the test here to say that if
      "wpa_ie_len" is set then "wpa_ie" has to be a valid pointer or we return
      -EINVAL.
      
      Oddly, we only use the first element of the abyWPAIE[] array.  So I
      suspect there may be some other issues in this function.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dd173abf