1. 17 9月, 2008 1 次提交
    • 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
  2. 22 8月, 2008 1 次提交
  3. 30 4月, 2008 1 次提交
  4. 29 4月, 2008 1 次提交
  5. 19 4月, 2008 1 次提交
  6. 05 2月, 2008 1 次提交
  7. 26 1月, 2008 4 次提交
  8. 13 10月, 2007 1 次提交
    • K
      Driver core: change add_uevent_var to use a struct · 7eff2e7a
      Kay Sievers 提交于
      This changes the uevent buffer functions to use a struct instead of a
      long list of parameters. It does no longer require the caller to do the
      proper buffer termination and size accounting, which is currently wrong
      in some places. It fixes a known bug where parts of the uevent
      environment are overwritten because of wrong index calculations.
      
      Many thanks to Mathieu Desnoyers for finding bugs and improving the
      error handling.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      7eff2e7a
  9. 12 10月, 2007 1 次提交
  10. 27 7月, 2007 1 次提交
  11. 27 4月, 2007 1 次提交
  12. 16 3月, 2007 1 次提交
    • A
      [PATCH] sysfs and driver core: add callback helper, used by SCSI and S390 · d9a9cdfb
      Alan Stern 提交于
      This patch (as868) adds a helper routine for device drivers that need
      to set up a callback to perform some action in a different process's
      context.  This is intended for use by attribute methods that want to
      unregister themselves or their parent device.  Attribute method calls
      are mutually exclusive with unregistration, so such actions cannot be
      taken directly.
      
      Two attribute methods are converted to use the new helper routine: one
      for SCSI device deletion and one for System/390 ccwgroup devices.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Oliver Neukum <oneukum@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d9a9cdfb
  13. 06 2月, 2007 1 次提交
  14. 30 8月, 2006 1 次提交
  15. 27 7月, 2006 1 次提交
  16. 12 7月, 2006 1 次提交
  17. 29 6月, 2006 1 次提交
    • C
      [S390] ccwgroup device unregister. · 887ab599
      Cornelia Huck 提交于
      Work around the problem that a device cannot be unregistered from
      driver_for_each_device() because of klist node refcounting: Get device
      after device owned by the driver to be unregistered with driver_find_device()
      and then unregister it. This works because driver_get_device() gets us out of
      the region of the elevated klist node refcount. driver_find_device() will
      always get the next device in the list after the found one has been
      unregistered.
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      887ab599
  18. 24 3月, 2006 1 次提交
  19. 02 2月, 2006 1 次提交
  20. 15 1月, 2006 1 次提交
  21. 14 1月, 2006 1 次提交
  22. 07 1月, 2006 1 次提交
  23. 05 1月, 2006 1 次提交
  24. 07 11月, 2005 1 次提交
  25. 22 9月, 2005 1 次提交
  26. 26 6月, 2005 1 次提交
  27. 21 6月, 2005 1 次提交
  28. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4