1. 11 10月, 2008 1 次提交
  2. 09 10月, 2008 1 次提交
    • T
      block: don't depend on consecutive minor space · f331c029
      Tejun Heo 提交于
      * Implement disk_devt() and part_devt() and use them to directly
        access devt instead of computing it from ->major and ->first_minor.
      
        Note that all references to ->major and ->first_minor outside of
        block layer is used to determine devt of the disk (the part0) and as
        ->major and ->first_minor will continue to represent devt for the
        disk, converting these users aren't strictly necessary.  However,
        convert them for consistency.
      
      * Implement disk_max_parts() to avoid directly deferencing
        genhd->minors.
      
      * Update bdget_disk() such that it doesn't assume consecutive minor
        space.
      
      * Move devt computation from register_disk() to add_disk() and make it
        the only one (all other usages use the initially determined value).
      
      These changes clean up the code and will help disk->part dereference
      fix and extended block device numbers.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      f331c029
  3. 04 10月, 2008 14 次提交
  4. 17 9月, 2008 2 次提交
    • S
      [S390] cio: fix orb initialization in cio_start_key · 9adb8c1d
      Stefan Weinhuber 提交于
      The functions cio_tm_start_key and cio_start_key use the same private
      orb structure of a subchannel, so the orb needs to be cleared of old
      data before it is used again. A respective memset is missing from
      cio_start_key and hereby added.
      Signed-off-by: NStefan Weinhuber <wein@de.ibm.com>
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9adb8c1d
    • C
      [S390] cio: Fix driver_data handling for ccwgroup devices. · f26fd5d6
      Cornelia Huck 提交于
      Since 16f7f956, we've seen
      oopses when grouping/ungrouping devices:
      
      Unable to handle kernel pointer dereference at virtual kernel address 0000000000
      114000
      Oops: 0004 [#1] PREEMPT SMP
      Modules linked in: bonding qeth_l2 dm_multipath sunrpc qeth_l3 dm_mod qeth chsc_
      sch ccwgroup
      CPU: 1 Not tainted 2.6.26-29.x.20080815-s390xdefault #1
      Process iperf (pid: 24412, task: 000000003f446038, ksp: 000000003c929e08)
      Krnl PSW : 0404d00180000000 000003e00006f6e6 (qeth_irq+0xda/0xb28 [qeth])
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
      Krnl GPRS: 0000000000000000 000003e000000003 0000000000000000 0000000000114ccc
                 000000003fb82e48 000003e00006f60c 000000000000000c 000000003ce72100
                 0000000000114944 000000003fb82e48 0000000000114ccc 000000003fe8fd28
                 000003e000066000 000003e000076128 000000003fe8fdb8 000000003fe8fd28
      Krnl Code: 000003e00006f6da: bf3f2024            icm     %r3,15,36(%r2)
                 000003e00006f6de: a774023c            brc     7,3e00006fb56
                 000003e00006f6e2: a7280000            lhi     %r2,0
                >000003e00006f6e6: 5020a1a0            st      %r2,416(%r10)
                 000003e00006f6ea: 58109000            l       %r1,0(%r9)
                 000003e00006f6ee: a7111000            tmll    %r1,4096
                 000003e00006f6f2: a77400f9            brc     7,3e00006f8e4
                 000003e00006f6f6: 8810000c            srl     %r1,12
      Call Trace:
      ([<000000003fe8fd20>] 0x3fe8fd20)
       [<000000000033bf2a>] ccw_device_call_handler+0xb2/0xd8
       [<0000000000339e1c>] ccw_device_irq+0x124/0x164
       [<0000000000339758>] io_subchannel_irq+0x8c/0x118
       [<00000000003309ba>] do_IRQ+0x192/0x1bc
       [<0000000000114f66>] io_return+0x0/0x8
       [<00000000001149cc>] sysc_do_svc+0x0/0x22
      ([<0000000000114a18>] sysc_noemu+0x10/0x16)
       [<00000200002e047c>] 0x200002e047c
      Last Breaking-Event-Address:
       [<000003e00006f6d6>] qeth_irq+0xca/0xb28 [qeth]
      
      The problem is that dev->driver_data for a ccw device is NULL,
      while it should point to the ccwgroup device it is a member of.
      This happened due to incorrect cleanup if creating a ccwgroup
      device failed because the ccw devices were already grouped.
      
      Fix this by setting cdev[i] to NULL in the error handling of
      ccwgroup_create_from_string() after we give up our reference and
      by checking if the driver_data points to the ccwgroup device in
      ccwgroup_release() just to be really sure.
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f26fd5d6
  5. 09 9月, 2008 3 次提交
  6. 29 8月, 2008 6 次提交
  7. 27 8月, 2008 7 次提交
  8. 26 8月, 2008 1 次提交
    • H
      [S390] dcss: fix build bug. · dbe13d99
      Heiko Carstens 提交于
      Fix this compile bug:
      
        CC      drivers/s390/block/dcssblk.o
      drivers/s390/block/dcssblk.c: In function 'dcssblk_add_store':
      drivers/s390/block/dcssblk.c:387: error: implicit declaration of function 'dcssblk_get_segment_by_name'
      drivers/s390/block/dcssblk.c:389: error: label 'release_gd' used but not defined
      make[1]: *** [drivers/s390/block/dcssblk.o] Error 1
      make: *** [drivers/s390/block/] Error 2
      
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      dbe13d99
  9. 24 8月, 2008 1 次提交
  10. 22 8月, 2008 4 次提交