1. 15 10月, 2010 1 次提交
  2. 07 10月, 2010 1 次提交
    • J
      elevator: fix oops on early call to elevator_change() · 430c62fb
      Jens Axboe 提交于
      2.6.36 introduces an API for drivers to switch the IO scheduler
      instead of manually calling the elevator exit and init functions.
      This API was added since q->elevator must be cleared in between
      those two calls. And since we already have this functionality
      directly from use by the sysfs interface to switch schedulers
      online, it was prudent to reuse it internally too.
      
      But this API needs the queue to be in a fully initialized state
      before it is called, or it will attempt to unregister elevator
      kobjects before they have been added. This results in an oops
      like this:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000051
      IP: [<ffffffff8116f15e>] sysfs_create_dir+0x2e/0xc0
      PGD 47ddfc067 PUD 47c6a1067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.1/irq
      CPU 2
      Modules linked in: t(+) loop hid_apple usbhid ahci ehci_hcd uhci_hcd libahci usbcore nls_base igb
      
      Pid: 7319, comm: modprobe Not tainted 2.6.36-rc6+ #132 QSSC-S4R/QSSC-S4R
      RIP: 0010:[<ffffffff8116f15e>]  [<ffffffff8116f15e>] sysfs_create_dir+0x2e/0xc0
      RSP: 0018:ffff88027da25d08  EFLAGS: 00010246
      RAX: ffff88047c68c528 RBX: 00000000fffffffe RCX: 0000000000000000
      RDX: 000000000000002f RSI: 000000000000002f RDI: ffff88047e196c88
      RBP: ffff88027da25d38 R08: 0000000000000000 R09: d84156c5635688c0
      R10: d84156c5635688c0 R11: 0000000000000000 R12: ffff88047e196c88
      R13: 0000000000000000 R14: 0000000000000000 R15: ffff88047c68c528
      FS:  00007fcb0b26f6e0(0000) GS:ffff880287400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000051 CR3: 000000047e76e000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process modprobe (pid: 7319, threadinfo ffff88027da24000, task ffff88027d377090)
      Stack:
       ffff88027da25d58 ffff88047c68c528 00000000fffffffe ffff88047e196c88
      <0> ffff88047c68c528 ffff88047e05bd90 ffff88027da25d78 ffffffff8123fb77
      <0> ffff88047e05bd90 0000000000000000 ffff88047e196c88 ffff88047c68c528
      Call Trace:
       [<ffffffff8123fb77>] kobject_add_internal+0xe7/0x1f0
       [<ffffffff8123fd98>] kobject_add_varg+0x38/0x60
       [<ffffffff8123feb9>] kobject_add+0x69/0x90
       [<ffffffff8116efe0>] ? sysfs_remove_dir+0x20/0xa0
       [<ffffffff8103d48d>] ? sub_preempt_count+0x9d/0xe0
       [<ffffffff8143de20>] ? _raw_spin_unlock+0x30/0x50
       [<ffffffff8116efe0>] ? sysfs_remove_dir+0x20/0xa0
       [<ffffffff8116eff4>] ? sysfs_remove_dir+0x34/0xa0
       [<ffffffff81224204>] elv_register_queue+0x34/0xa0
       [<ffffffff81224aad>] elevator_change+0xfd/0x250
       [<ffffffffa007e000>] ? t_init+0x0/0x361 [t]
       [<ffffffffa007e000>] ? t_init+0x0/0x361 [t]
       [<ffffffffa007e0a8>] t_init+0xa8/0x361 [t]
       [<ffffffff810001de>] do_one_initcall+0x3e/0x170
       [<ffffffff8108c3fd>] sys_init_module+0xbd/0x220
       [<ffffffff81002f2b>] system_call_fastpath+0x16/0x1b
      Code: e5 41 56 41 55 41 54 49 89 fc 53 48 83 ec 10 48 85 ff 74 52 48 8b 47 18 49 c7 c5 00 46 61 81 48 85 c0 74 04 4c 8b 68 30 45 31 f6 <41> 80 7d 51 00 74 0e 49 8b 44 24 28 4c 89 e7 ff 50 20 49 89 c6
      RIP  [<ffffffff8116f15e>] sysfs_create_dir+0x2e/0xc0
       RSP <ffff88027da25d08>
      CR2: 0000000000000051
      ---[ end trace a6541d3bf07945df ]---
      
      Fix this by adding a registered bit to the elevator queue, which is
      set when the sysfs kobjects have been registered.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      430c62fb
  3. 25 9月, 2010 1 次提交
    • A
      block: prevent merges of discard and write requests · f281fb5f
      Adrian Hunter 提交于
      Add logic to prevent two I/O requests being merged if
      only one of them is a discard.  Ditto secure discard.
      
      Without this fix, it is possible for write requests
      to transform into discard requests.  For example:
      
        Submit bio 1 to discard 8 sectors from sector n
        Submit bio 2 to write 8 sectors from sector n + 16
        Submit bio 3 to write 8 sectors from sector n + 8
      
      Bio 1 becomes request 1.  Bio 2 becomes request 2.
      Bio 3 is merged with request 2, and then subsequently
      request 2 is merged with request 1 resulting in just
      one I/O request which discards all 24 sectors.
      Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
      
      (Moved the checks above the position checks /Jens)
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      f281fb5f
  4. 21 9月, 2010 2 次提交
    • 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
  5. 10 9月, 2010 1 次提交
    • B
      block: Range check cpu in blk_cpu_to_group · be14eb61
      Brian King 提交于
      While testing CPU DLPAR, the following problem was discovered.
      We were DLPAR removing the first CPU, which in this case was
      logical CPUs 0-3. CPUs 0-2 were already marked offline and
      we were in the process of offlining CPU 3. After marking
      the CPU inactive and offline in cpu_disable, but before the
      cpu was completely idle (cpu_die), we ended up in __make_request
      on CPU 3. There we looked at the topology map to see which CPU
      to complete the I/O on and found no CPUs in the cpu_sibling_map.
      This resulted in the block layer setting the completion cpu
      to be NR_CPUS, which then caused an oops when we tried to
      complete the I/O.
      
      Fix this by sanity checking the value we return from blk_cpu_to_group
      to be a valid cpu value.
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      be14eb61
  6. 23 8月, 2010 8 次提交
  7. 12 8月, 2010 1 次提交
  8. 09 8月, 2010 2 次提交
  9. 08 8月, 2010 19 次提交
  10. 24 6月, 2010 1 次提交
  11. 21 6月, 2010 1 次提交
  12. 19 6月, 2010 1 次提交
    • V
      cfq-iosched: Fixed boot warning with BLK_CGROUP=y and CFQ_GROUP_IOSCHED=n · e98ef89b
      Vivek Goyal 提交于
      Hi Jens,
      
      Few days back Ingo noticed a CFQ boot time warning. This patch fixes it.
      The issue here is that with CFQ_GROUP_IOSCHED=n, CFQ should not really
      be making blkio stat related calls.
      
      > Hm, it's still not entirely fixed, as of 2.6.35-rc2-00131-g7908a9e5. With
      > some
      > configs i get bad spinlock warnings during bootup:
      >
      > [   28.968013] initcall net_olddevs_init+0x0/0x82 returned 0 after 93750
      > usecs
      > [   28.972003] calling  b44_init+0x0/0x55 @ 1
      > [   28.976009] bus: 'pci': add driver b44
      > [   28.976374]  sda:
      > [   28.978157] BUG: spinlock bad magic on CPU#1, async/0/117
      > [   28.980000]  lock: 7e1c5bbc, .magic: 00000000, .owner: <none>/-1, +.owner_cpu: 0
      > [   28.980000] Pid: 117, comm: async/0 Not tainted +2.6.35-rc2-tip-01092-g010e7ef-dirty #8183
      > [   28.980000] Call Trace:
      > [   28.980000]  [<41ba6d55>] ? printk+0x20/0x24
      > [   28.980000]  [<4134b7b7>] spin_bug+0x7c/0x87
      > [   28.980000]  [<4134b853>] do_raw_spin_lock+0x1e/0x123
      > [   28.980000]  [<41ba92ca>] ? _raw_spin_lock_irqsave+0x12/0x20
      > [   28.980000]  [<41ba92d2>] _raw_spin_lock_irqsave+0x1a/0x20
      > [   28.980000]  [<4133476f>] blkiocg_update_io_add_stats+0x25/0xfb
      > [   28.980000]  [<41335dae>] ? cfq_prio_tree_add+0xb1/0xc1
      > [   28.980000]  [<41337bc7>] cfq_insert_request+0x8c/0x425
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      e98ef89b
  13. 18 6月, 2010 1 次提交
    • J
      cfq: Don't allow queue merges for queues that have no process references · c10b61f0
      Jeff Moyer 提交于
      Hi,
      
      A user reported a kernel bug when running a particular program that did
      the following:
      
      created 32 threads
      - each thread took a mutex, grabbed a global offset, added a buffer size
        to that offset, released the lock
      - read from the given offset in the file
      - created a new thread to do the same
      - exited
      
      The result is that cfq's close cooperator logic would trigger, as the
      threads were issuing I/O within the mean seek distance of one another.
      This workload managed to routinely trigger a use after free bug when
      walking the list of merge candidates for a particular cfqq
      (cfqq->new_cfqq).  The logic used for merging queues looks like this:
      
      static void cfq_setup_merge(struct cfq_queue *cfqq, struct cfq_queue *new_cfqq)
      {
      	int process_refs, new_process_refs;
      	struct cfq_queue *__cfqq;
      
      	/* Avoid a circular list and skip interim queue merges */
      	while ((__cfqq = new_cfqq->new_cfqq)) {
      		if (__cfqq == cfqq)
      			return;
      		new_cfqq = __cfqq;
      	}
      
      	process_refs = cfqq_process_refs(cfqq);
      	/*
      	 * If the process for the cfqq has gone away, there is no
      	 * sense in merging the queues.
      	 */
      	if (process_refs == 0)
      		return;
      
      	/*
      	 * Merge in the direction of the lesser amount of work.
      	 */
      	new_process_refs = cfqq_process_refs(new_cfqq);
      	if (new_process_refs >= process_refs) {
      		cfqq->new_cfqq = new_cfqq;
      		atomic_add(process_refs, &new_cfqq->ref);
      	} else {
      		new_cfqq->new_cfqq = cfqq;
      		atomic_add(new_process_refs, &cfqq->ref);
      	}
      }
      
      When a merge candidate is found, we add the process references for the
      queue with less references to the queue with more.  The actual merging
      of queues happens when a new request is issued for a given cfqq.  In the
      case of the test program, it only does a single pread call to read in
      1MB, so the actual merge never happens.
      
      Normally, this is fine, as when the queue exits, we simply drop the
      references we took on the other cfqqs in the merge chain:
      
      	/*
      	 * If this queue was scheduled to merge with another queue, be
      	 * sure to drop the reference taken on that queue (and others in
      	 * the merge chain).  See cfq_setup_merge and cfq_merge_cfqqs.
      	 */
      	__cfqq = cfqq->new_cfqq;
      	while (__cfqq) {
      		if (__cfqq == cfqq) {
      			WARN(1, "cfqq->new_cfqq loop detected\n");
      			break;
      		}
      		next = __cfqq->new_cfqq;
      		cfq_put_queue(__cfqq);
      		__cfqq = next;
      	}
      
      However, there is a hole in this logic.  Consider the following (and
      keep in mind that each I/O keeps a reference to the cfqq):
      
      q1->new_cfqq = q2   // q2 now has 2 process references
      q3->new_cfqq = q2   // q2 now has 3 process references
      
      // the process associated with q2 exits
      // q2 now has 2 process references
      
      // queue 1 exits, drops its reference on q2
      // q2 now has 1 process reference
      
      // q3 exits, so has 0 process references, and hence drops its references
      // to q2, which leaves q2 also with 0 process references
      
      q4 comes along and wants to merge with q3
      
      q3->new_cfqq still points at q2!  We follow that link and end up at an
      already freed cfqq.
      
      So, the fix is to not follow a merge chain if the top-most queue does
      not have a process reference, otherwise any queue in the chain could be
      already freed.  I also changed the logic to disallow merging with a
      queue that does not have any process references.  Previously, we did
      this check for one of the merge candidates, but not the other.  That
      doesn't really make sense.
      
      Without the attached patch, my system would BUG within a couple of
      seconds of running the reproducer program.  With the patch applied, my
      system ran the program for over an hour without issues.
      
      This addresses the following bugzilla:
          https://bugzilla.kernel.org/show_bug.cgi?id=16217
      
      Thanks a ton to Phil Carns for providing the bug report and an excellent
      reproducer.
      
      [ Note for stable: this applies to 2.6.32/33/34 ].
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      Reported-by: NPhil Carns <carns@mcs.anl.gov>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      c10b61f0
新手
引导
客服 返回
顶部