1. 14 7月, 2008 18 次提交
  2. 10 6月, 2008 2 次提交
    • J
      [S390] tape_3590.c: introduce missing kfree · 1783e60f
      Julia Lawall 提交于
      The semantic match that finds the problem is as follows:
      (http://www.emn.fr/x-info/coccinelle/)
      
      @r exists@
      expression E,E1;
      statement S;
      position p1,p2,p3;
      @@
      
      E =@p1 \(kmalloc\|kcalloc\|kzalloc\)(...)
      ... when != E = E1
      if (E == NULL || ...) S
      ... when != E = E1
      if@p2 (...) {
       ... when != kfree(E)
       }
      ... when != E = E1
      kfree@p3(E);
      
      @forall@
      position r.p2;
      expression r.E;
      int E1 != 0;
      @@
      
      * if@p2 (...) {
       ... when != kfree(E)
           when strict
      return E1; }
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1783e60f
    • C
      [S390] vt220 console, initialize list head before use · 7b439d25
      Carsten Otte 提交于
      This patch fixes a null pointer dereference during initialisation when no
      sclp event facility is available:
      sclp vt220 tty driver: could not register vt220 - sclp_register returned -5
      Unable to handle kernel paging request at virtual user address 0000000000000000
      Oops: 0004 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0 Not tainted 2.6.26-rc3-kvm-bigiron-00968-gd939e93-dirty #30
      Process swapper (pid: 0, task: 0000000000600be0, ksp: 000000000064a000)
      Krnl PSW : 0400000180000000 0000000000320d8c (sclp_unregister+0x48/0x8c)
                 R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:0 PM:0 EA:3
      Krnl GPRS: 0000000000000000 0000000000000000 0000000000630478 0700000000649c20
                 0000000000000000 0000000000433060 000000000064a660 0000000002e26000
                 00000000006db000 0000000000000000 0000000000a78578 0000000000649b80
                 0000000000630dc0 000000000044fa20 0000000000320d76 0000000000649b80
      Krnl Code: 0000000000320d7c: e310c0080004       lg      %r1,8(%r12)
                 0000000000320d82: b9040032           lgr     %r3,%r2
                 0000000000320d86: c02000187b79       larl    %r2,630478
                >0000000000320d8c: e34010000024       stg     %r4,0(%r1)
                 0000000000320d92: e31040080024       stg     %r1,8(%r4)
                 0000000000320d98: c01100200200       lgfi    %r1,2097664
                 0000000000320d9e: e310c0080024       stg     %r1,8(%r12)
                 0000000000320da4: c01100100100       lgfi    %r1,1048832
      Call Trace:
      ([<0000000000320d76>] sclp_unregister+0x32/0x8c)
       [<00000000006657b4>] __sclp_vt220_cleanup+0xc4/0xe0
       [<000000000066595c>] __sclp_vt220_init+0x18c/0x1a0
       [<0000000000665aba>] sclp_vt220_con_init+0x42/0x68
       [<00000000006601ca>] console_init+0x4e/0x68
       [<000000000064acae>] start_kernel+0x3a2/0x4dc
       [<0000000000100020>] _stext+0x20/0x80
      INFO: lockdep is turned off.
      Last Breaking-Event-Address:
       [<000000000041f964>] _spin_lock_irqsave+0xb0/0xb4
       <4>---[ end trace 31fd0ba7d8756001 ]---
      
      The issue is caused by a list_empty() check in __sclp_vt220_cleanup, which
      usually fails on non-initialized list heads that contain {NULL,NULL} instead.
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7b439d25
  3. 30 5月, 2008 5 次提交
    • M
      [S390] tape: fix race with stack local wait_queue_head_t. · 4657fb8a
      Martin Schwidefsky 提交于
      A wait_event call with a stack local wait_queue_head_t structure that is
      used to do the wake up for the wait_event is inherently racy. After the
      wait_event finished the wake_up call might not have completed yet.
      Replace the stack local wait_queue_head_t in tape_do_io and
      tape_do_io_interruptible with a per device wait queue.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      4657fb8a
    • M
      [S390] 3270: fix race with stack local wait_queue_head_t. · 54ad6412
      Martin Schwidefsky 提交于
      A wait_event call with a stack local wait_queue_head_t structure that is
      used to do the wake up for the wait_event is inherently racy. After the
      wait_event finished the wake_up call might not have completed yet.
      Remove the stack local wait_queue_head_t from raw3270_start_init and
      use the global raw3270_wait_queue instead.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      54ad6412
    • H
      [S390] sclp_vt220: fix scheduling while atomic bug. · d4820e44
      Heiko Carstens 提交于
      The driver incorrectly assumed that putchar will only be called from
      schedulable process context and therefore blocked and waited if no
      free output buffers where available.
      Since putchar may also be called from BH context this may lead to
      deadlocks.
      To fix this just return the number of characters accepted and let the
      upper layer handle the rest.
      
      The console write function will busy wait (sclp_sync_wait) until a
      buffer is available again.
      
      Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d4820e44
    • H
      [S390] Fix section mismatch warnings. · 67060d9c
      Heiko Carstens 提交于
      This fixes the last remaining section mismatch warnings in s390
      architecture code. It reveals also a real bug introduced by... me
      with git commit 2069e978
      ("[S390] sparsemem vmemmap: initialize memmap.")
      
      Calling the generic vmemmap_alloc_block() function to get initialized
      memory is a nice idea, however that function is __meminit annotated
      and therefore the function might be gone if we try to call it later.
      This can happen if a DCSS segment gets added.
      
      So basically revert the patch and clear the memmap explicitly to fix
      the original bug.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      67060d9c
    • M
      [S390] tape: Fix race condition in tape block device driver · f71ad62a
      Michael Holzheu 提交于
      Due to incorrect function call sequence it can happen that a tape block
      request is finished before the request is taken from the block request queue.
      
      The following sequence leads to that condition:
       * tapeblock_start_request() -> start CCW program
       * Request finishes -> IO interrupt
       * tapeblock_end_request()
       * end_that_request_last()
      
      If blkdev_dequeue_request() has not been called before end_that_request_last(),
      a kernel bug is triggered in end_that_request_last() because the request is
      still queued. To solve that problem blkdev_dequeue_request() has to be called
      before starting the CCW program.
      Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f71ad62a
  4. 21 5月, 2008 1 次提交
    • G
      s390: fix race in device_create · c5fb920a
      Greg Kroah-Hartman 提交于
      There is a race from when a device is created with device_create() and
      then the drvdata is set with a call to dev_set_drvdata() in which a
      sysfs file could be open, yet the drvdata will be NULL, causing all
      sorts of bad things to happen.
      
      This patch fixes the problem by using the new function,
      device_create_drvdata().
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c5fb920a
  5. 15 5月, 2008 2 次提交
  6. 07 5月, 2008 1 次提交
  7. 30 4月, 2008 2 次提交
  8. 29 4月, 2008 2 次提交
  9. 17 4月, 2008 5 次提交
  10. 05 3月, 2008 2 次提交