1. 04 10月, 2008 3 次提交
    • M
      rtc: fix kernel panic on second use of SIGIO nofitication · 2e4a75cd
      Marcin Slusarz 提交于
      When userspace uses SIGIO notification and forgets to disable it before
      closing file descriptor, rtc->async_queue contains stale pointer to struct
      file.  When user space enables again SIGIO notification in different
      process, kernel dereferences this (poisoned) pointer and crashes.
      
      So disable SIGIO notification on close.
      
      Kernel panic:
      (second run of qemu (requires echo 1024 > /sys/class/rtc/rtc0/max_user_freq))
      
      general protection fault: 0000 [1] PREEMPT
      CPU 0
      Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer ir_common compat_ioctl32 snd_page_alloc videodev v4l1_compat snd_mpu401_uart snd_rawmidi v4l2_common videobuf_dma_sg videobuf_core snd_seq_device snd btcx_risc soundcore tveeprom i2c_viapro
      Pid: 5781, comm: qemu-system-x86 Not tainted 2.6.27-rc6 #363
      RIP: 0010:[<ffffffff8024f891>]  [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f
      RSP: 0000:ffffffff80674cb8  EFLAGS: 00010002
      RAX: ffff8800224c62f0 RBX: 0000000000000046 RCX: 0000000000000002
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800224c62f0
      RBP: ffffffff80674d08 R08: 0000000000000002 R09: 0000000000000001
      R10: ffffffff80238941 R11: 0000000000000001 R12: 0000000000000000
      R13: 6b6b6b6b6b6b6b6b R14: ffff88003a450080 R15: 0000000000000000
      FS:  00007f98b69516f0(0000) GS:ffffffff80623200(0000) knlGS:00000000f7cc86d0
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000a87000 CR3: 0000000022598000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process qemu-system-x86 (pid: 5781, threadinfo ffff880028812000, task ffff88003a450080)
      Stack:  ffffffff80674cf8 0000000180238440 0000000200000002 0000000000000000
       ffff8800224c62f0 0000000000000046 0000000000000000 0000000000000002
       0000000000000002 0000000000000000 ffffffff80674d68 ffffffff8024fc7a
      Call Trace:
       <IRQ>  [<ffffffff8024fc7a>] lock_acquire+0x85/0xa9
       [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184
       [<ffffffff80491d1f>] _read_lock+0x3e/0x4a
       [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184
       [<ffffffff8029cb62>] send_sigio+0x2a/0x184
       [<ffffffff8024fb97>] ? __lock_acquire+0x6e1/0x73f
       [<ffffffff8029cd4d>] ? kill_fasync+0x2c/0x4e
       [<ffffffff8029cd10>] __kill_fasync+0x54/0x65
       [<ffffffff8029cd5b>] kill_fasync+0x3a/0x4e
       [<ffffffff80402896>] rtc_update_irq+0x9c/0xa5
       [<ffffffff80404640>] cmos_interrupt+0xae/0xc0
       [<ffffffff8025d1c1>] handle_IRQ_event+0x25/0x5a
       [<ffffffff8025e5e4>] handle_edge_irq+0xdd/0x123
       [<ffffffff8020da34>] do_IRQ+0xe4/0x144
       [<ffffffff8020bad6>] ret_from_intr+0x0/0xf
       <EOI>  [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad
       [<ffffffff8033fe67>] ? clear_page_c+0x7/0x10
       [<ffffffff8026fc10>] ? get_page_from_freelist+0x385/0x450
       [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad
       [<ffffffff80280aac>] ? anon_vma_prepare+0x2e/0xf6
       [<ffffffff80279400>] ? handle_mm_fault+0x227/0x6a5
       [<ffffffff80494716>] ? do_page_fault+0x494/0x83f
       [<ffffffff8049251d>] ? error_exit+0x0/0xa9
      
      Code: cc 41 39 45 28 74 24 e8 5e 1d 0f 00 85 c0 0f 84 6a 03 00 00 83 3d 8f a9 aa 00 00 be 47 03 00 00 0f 84 6a 02 00 00 e9 53 03 00 00 <41> ff 85 38 01 00 00 45 8b be 90 06 00 00 41 83 ff 2f 76 24 e8
      RIP  [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f
       RSP <ffffffff80674cb8>
      ---[ end trace 431877d860448760 ]---
      Kernel panic - not syncing: Aiee, killing interrupt handler!
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: NAlessandro Zummo <alessandro.zummo@towertech.it>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2e4a75cd
    • J
      [S390] qdio: prevent stack clobber · 75f62761
      Jan Glauber 提交于
      Don't print more information than fits into the string on the
      stack. Combine the informational output of qdio to fit into
      one line.
      Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      75f62761
    • L
      e1000e: Fix incorrect debug warning · 95b866d5
      Linus Torvalds 提交于
      Doing 'WARN_ON(preempt_count())' was horribly horribly wrong, and would
      cause tons of warnings at bootup if PREEMPT was enabled because the
      initcalls currently run with the kernel lock, which increments the
      preempt count.
      
      At the same time, the warning was also insufficient, since it didn't
      check that interrupts were enabled.
      
      The proper debug function to use for something that can sleep and wants
      a warning if it's called in the wrong context is 'might_sleep()'.
      Reported-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      95b866d5
  2. 03 10月, 2008 9 次提交
  3. 02 10月, 2008 2 次提交
  4. 01 10月, 2008 3 次提交
    • C
      dm mpath: add missing path switching locking · 7253a334
      Chandra Seetharaman 提交于
      Moving the path activation to workqueue along with scsi_dh patches introduced
      a race. It is due to the fact that the current_pgpath (in the multipath data
      structure) can be modified if changes happen in any of the paths leading to
      the lun. If the changes lead to current_pgpath being set to NULL, then it
      leads to the invalid access which results in the panic below.
      
      This patch fixes that by storing the pgpath to activate in the multipath data
      structure and properly protecting it.
      
      Note that if activate_path is called twice in succession with different pgpath,
      with the second one being called before the first one is done, then activate
      path will be called twice for the second pgpath, which is fine.
      
      Unable to handle kernel paging request for data at address 0x00000020
      Faulting instruction address: 0xd000000000aa1844
      cpu 0x1: Vector: 300 (Data Access) at [c00000006b987a80]
          pc: d000000000aa1844: .activate_path+0x30/0x218 [dm_multipath]
          lr: c000000000087a2c: .run_workqueue+0x114/0x204
          sp: c00000006b987d00
         msr: 8000000000009032
         dar: 20
       dsisr: 40000000
        current = 0xc0000000676bb3f0
        paca    = 0xc0000000006f3680
          pid   = 2528, comm = kmpath_handlerd
      enter ? for help
      [c00000006b987da0] c000000000087a2c .run_workqueue+0x114/0x204
      [c00000006b987e40] c000000000088b58 .worker_thread+0x120/0x144
      [c00000006b987f00] c00000000008ca70 .kthread+0x78/0xc4
      [c00000006b987f90] c000000000027cc8 .kernel_thread+0x4c/0x68
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      7253a334
    • M
      dm: cope with access beyond end of device in dm_merge_bvec · b01cd5ac
      Mikulas Patocka 提交于
      If for any reason dm_merge_bvec() is given an offset beyond the end of the
      device, avoid an oops and always allow one page to be added to an empty bio.
      We'll reject the I/O later after the bio is submitted.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      b01cd5ac
    • M
      dm: always allow one page in dm_merge_bvec · 5037108a
      Mikulas Patocka 提交于
      Some callers assume they can always add at least one page to an empty bio,
      so dm_merge_bvec should not return 0 in this case: we'll reject the I/O
      later after the bio is submitted.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      5037108a
  5. 30 9月, 2008 2 次提交
  6. 29 9月, 2008 3 次提交
  7. 28 9月, 2008 3 次提交
  8. 27 9月, 2008 1 次提交
  9. 26 9月, 2008 2 次提交
  10. 25 9月, 2008 1 次提交
    • L
      ath9k: disable MIB interrupts to fix interrupt storm · 92cccc2c
      Luis R. Rodriguez 提交于
      Enabling the MIB interrupts has proven to cause an
      interrupt storm after 7 hours of run. We will make use of the
      MIB interrupt once we have ANI supported added so for now
      to cure this we disable the interrupt.
      
      The interrupt storm can be seen as follows after 7 hours of run
      as reported by  Steven Noonan <steven@uplinklabs.net>:
      
      18:28:38          sum   1106.00
      18:28:39          sum   1037.62
      18:28:40          sum   1069.00
      18:28:41          sum   1167.00
      18:28:42          sum   1155.00
      18:28:43          sum   1339.00
      18:28:44          sum  18355.00
      18:28:45          sum  17845.45
      18:28:46          sum  15285.00
      18:28:47          sum  17511.00
      18:28:48          sum  17568.69
      18:28:49          sum  17704.04
      18:28:50          sum  18566.67
      18:28:51          sum  18913.13
      
      at 18:28:44 the MIB interrupt kicked off and caused huge
      latency which can be seen even on a video he submitted:
      
      http://www.youtube.com/watch?v=4GeCx1gZMpASigned-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      92cccc2c
  11. 24 9月, 2008 11 次提交