Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 7月, 2008 4 次提交
  3. 11 6月, 2008 5 次提交
  5. 10 6月, 2008 4 次提交
    • 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
    • C
      [S390] cio: Fix inverted isc priorities. · 85b0d7c0
      由 Cornelia Huck 提交于 
      Priorities for I/O interruption subclasses range from 0 (highest)
to 7 (lowest). Unfortunately, the console has been using isc 7
instead of an isc with a higher priority than regular I/O
subchannels (which use 3). Fix this by making the console use
isc 1.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      85b0d7c0
    • C
      [S390] cio: Fix sparse warnings in blacklist.c. · 12829126
      由 Cornelia Huck 提交于 
      sparse complains about signedness:

drivers/s390/cio/blacklist.c:132:28: warning: incorrect type in
argument 2 (different signedness)
drivers/s390/cio/blacklist.c:132:28:    expected unsigned int *val
drivers/s390/cio/blacklist.c:132:28:    got int *cssid
drivers/s390/cio/blacklist.c:136:28: warning: incorrect type in
argument 2 (different signedness)
drivers/s390/cio/blacklist.c:136:28:    expected unsigned int *val
drivers/s390/cio/blacklist.c:136:28:    got int *ssid
drivers/s390/cio/blacklist.c:140:28: warning: incorrect type in
argument 2 (different signedness)
drivers/s390/cio/blacklist.c:140:28:    expected unsigned int *val
drivers/s390/cio/blacklist.c:140:28:    got int *devno

cssid, ssid and devno are of course unsigned, so let's make the
variables unsigned as well.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      12829126
  7. 07 6月, 2008 1 次提交
  9. 30 5月, 2008 7 次提交
    • 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
    • S
      [S390] dasd: use a generic wait_queue for sleep_on · c80ee724
      由 Stefan Haberland 提交于 
      Use a generic wait_queue to prevent the wait_queue in dasd_sleep_on_
functions from being referenced by callback_data while it does not
exist any more.
Signed-off-by: NStefan Haberland  <stefan.haberland@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c80ee724
    • 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
    • R
      virtio: set device index in common code. · b769f579
      由 Rusty Russell 提交于 
      Anthony Liguori points out that three different transports use the virtio code,
but each one keeps its own counter to set the virtio_device's index field.  In
theory (though not in current practice) this means that names could be
duplicated, and that risk grows as more transports are created.

So we move the selection of the unique virtio_device.index into the common code
in virtio.c, which has the side-benefit of removing duplicate code.

The only complexity is that lguest and S/390 use the index to uniquely identify
the device in case of catastrophic failure before register_virtio_device() is
called: now we use the offset within the descriptor page as a unique identifier
for the printks.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Chris Lalancette <clalance@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
      b769f579
  11. 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
  13. 18 5月, 2008 1 次提交
  15. 15 5月, 2008 6 次提交
  17. 07 5月, 2008 4 次提交
  19. 02 5月, 2008 1 次提交
    • B
      [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer · 64a87b24
      由 Boaz Harrosh 提交于 
       - struct scsi_cmnd had a 16 bytes command buffer of its own.
   This is an unnecessary duplication and copy of request's
   cmd. It is probably left overs from the time that scsi_cmnd
   could function without a request attached. So clean that up.

 - Once above is done, few places, apart from scsi-ml, needed
   adjustments due to changing the data type of scsi_cmnd->cmnd.

 - Lots of drivers still use MAX_COMMAND_SIZE. So I have left
   that #define but equate it to BLK_MAX_CDB. The way I see it
   and is reflected in the patch below is.
   MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB
                      as per the SCSI standard and is not related
                      to the implementation.
   BLK_MAX_CDB.     - The allocated space at the request level

 - I have audit all ISA drivers and made sure none use ->cmnd in a DMA
   Operation. Same audit was done by Andi Kleen.

(*)fixed-length here means commands that their size can be determined
   by their opcode and the CDB does not carry a length specifier, (unlike
   the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly
   true and the SCSI standard also defines extended commands and
   vendor specific commands that can be bigger than 16 bytes. The kernel
   will support these using the same infrastructure used for VARLEN CDB's.
   So in effect MAX_COMMAND_SIZE means the maximum size command
   scsi-ml supports without specifying a cmd_len by ULD's
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      64a87b24
  21. 30 4月, 2008 5 次提交
  23. 29 4月, 2008 1 次提交