1. 04 Oct, 2008 2 commits
    • Krzysztof Helt's avatar
      fbdev: fix recursive notifier and locking when fbdev console is blanked · aef7db4b
      Krzysztof Helt authored
      Fix infinite recursive notifier in the fbdev layer.  This causes recursive
      locking.  Dmitry Baryshkov found the problem and confirmed that the patch
      fixes the bug.
      
      After doing
      # echo 1 > /sys/class/graphics/fb0/blank
      I got the following in my kernel log:
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.27-rc6-00086-gda63874-dirty #97
      ---------------------------------------------
      echo/1564 is trying to acquire lock:
       ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c
      
      but task is already holding lock:
       ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c
      
      other info that might help us debug this:
      2 locks held by echo/1564:
       #0:  (&buffer->mutex){--..}, at: [<c00ddde0>] sysfs_write_file+0x30/0x80
       #1:  ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c
      
      stack backtrace:
      [<c0029fe4>] (dump_stack+0x0/0x14) from [<c0060ce0>] (print_deadlock_bug+0xa4/0xd0)
      [<c0060c3c>] (print_deadlock_bug+0x0/0xd0) from [<c0060e54>] (check_deadlock+0x148/0x17c)
       r6:c397a1e0 r5:c397a530 r4:c04fcf98
      [<c0060d0c>] (check_deadlock+0x0/0x17c) from [<c00637e8>] (validate_chain+0x3c4/0x4f0)
      [<c0063424>] (validate_chain+0x0/0x4f0) from [<c0063efc>] (__lock_acquire+0x5e8/0x6b4)
      [<c0063914>] (__lock_acquire+0x0/0x6b4) from [<c006402c>] (lock_acquire+0x64/0x78)
      [<c0063fc8>] (lock_acquire+0x0/0x78) from [<c0316ca8>] (down_read+0x4c/0x60)
       r7:00000009 r6:ffffffff r5:c0427a40 r4:c005a384
      [<c0316c5c>] (down_read+0x0/0x60) from [<c005a384>] (__blocking_notifier_call_chain+0x38/0x6c)
       r5:c0427a40 r4:c0427a74
      [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28)
       r8:00000009 r7:c086d640 r6:c3967940 r5:00000000 r4:c38984b8
      [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24)
      [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70)
      [<c014c128>] (fb_blank+0x0/0x70) from [<c0155978>] (fbcon_blank+0x114/0x1bc)
       r5:00000001 r4:c38984b8
      [<c0155864>] (fbcon_blank+0x0/0x1bc) from [<c0170ea8>] (do_blank_screen+0x1e0/0x2a0)
      [<c0170cc8>] (do_blank_screen+0x0/0x2a0) from [<c0154024>] (fbcon_fb_blanked+0x74/0x94)
       r5:c3967940 r4:00000001
      [<c0153fb0>] (fbcon_fb_blanked+0x0/0x94) from [<c0154228>] (fbcon_event_notify+0x100/0x12c)
       r5:fffffffe r4:c39bc194
      [<c0154128>] (fbcon_event_notify+0x0/0x12c) from [<c005a0d4>] (notifier_call_chain+0x38/0x7c)
      [<c005a09c>] (notifier_call_chain+0x0/0x7c) from [<c005a3a0>] (__blocking_notifier_call_chain+0x54/0x6c)
       r8:c3b51ea0 r7:00000009 r6:ffffffff r5:c0427a40 r4:c0427a74
      [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28)
       r8:00000001 r7:c3a7e000 r6:00000000 r5:00000000 r4:c38984b8
      [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24)
      [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70)
      [<c014c128>] (fb_blank+0x0/0x70) from [<c014e450>] (store_blank+0x54/0x7c)
       r5:c38984b8 r4:c3b51ec4
      [<c014e3fc>] (store_blank+0x0/0x7c) from [<c017981c>] (dev_attr_store+0x28/0x2c)
       r8:00000001 r7:c042bf80 r6:c39eba10 r5:c3967c30 r4:c38e0140
      [<c01797f4>] (dev_attr_store+0x0/0x2c) from [<c00ddaac>] (flush_write_buffer+0x54/0x68)
      [<c00dda58>] (flush_write_buffer+0x0/0x68) from [<c00dde08>] (sysfs_write_file+0x58/0x80)
       r8:c3b51f78 r7:c3bcb070 r6:c39eba10 r5:00000001 r4:00000001
      [<c00dddb0>] (sysfs_write_file+0x0/0x80) from [<c009de04>] (vfs_write+0xb8/0x148)
      [<c009dd4c>] (vfs_write+0x0/0x148) from [<c009e384>] (sys_write+0x44/0x70)
       r7:00000004 r6:c3bcb070 r5:00000000 r4:00000000
      [<c009e340>] (sys_write+0x0/0x70) from [<c0025d00>] (ret_fast_syscall+0x0/0x2c)
       r6:4001b000 r5:00000001 r4:401dc658
      Signed-off-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Reported-by: default avatarDmitry Baryshkov <dbaryshkov@gmail.com>
      Testted-by: default avatarDmitry Baryshkov <dbaryshkov@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      aef7db4b
    • Marcin Slusarz's avatar
      rtc: fix kernel panic on second use of SIGIO nofitication · 2e4a75cd
      Marcin Slusarz authored
      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: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: default avatarAlessandro Zummo <alessandro.zummo@towertech.it>
      Acked-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2e4a75cd
  2. 03 Oct, 2008 18 commits
  3. 02 Oct, 2008 14 commits
  4. 01 Oct, 2008 6 commits
    • Mike Rapoport's avatar
      pxa2xx_spi: fix build breakage · 20b918dc
      Mike Rapoport authored
      This patch fixes a build error in the pxa2xx-spi driver,
      introduced by commit 7e964455
      ("pxa2xx_spi: dma bugfixes")
      
        CC      drivers/spi/pxa2xx_spi.o
      drivers/spi/pxa2xx_spi.c: In function 'map_dma_buffers':
      drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary &
      drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary &
      drivers/spi/pxa2xx_spi.c: In function 'pump_transfers':
      drivers/spi/pxa2xx_spi.c:897: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
      
      [dbrownell@users.sourceforge.net: fix warning too ]
      Signed-off-by: default avatarMike Rapoport <mike@compulab.co.il>
      Acked-by: default avatarEric Miao <eric.miao@marvell.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      20b918dc
    • Linus Torvalds's avatar
      Merge branch 'x86-fixes-for-linus' of... · edfd222f
      Linus Torvalds authored
      Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86, vmi: fix broken LDT access
        x86: fix typo in enable_mtrr_cleanup early parameter
      edfd222f
    • David Howells's avatar
      MN10300: Fix IRQ handling · d6478fad
      David Howells authored
      Fix the IRQ handling on the MN10300 arch.
      
      This patch makes a number of significant changes:
      
       (1) It separates the irq_chip definition for edge-triggered interrupts from
           the one for level-triggered interrupts.
      
           This is necessary because the MN10300 PIC latches the IRQ channel's
           interrupt request bit (GxICR_REQUEST), even after the device has ceased to
           assert its interrupt line and the interrupt channel has been disabled in
           the PIC.  So for level-triggered interrupts we need to clear this bit when
           we re-enable - which is achieved by setting GxICR_DETECT but not
           GxICR_REQUEST when writing to the register.
      
           Not doing this results in spurious interrupts occurring because calling
           mask_ack() at the start of handle_level_irq() is insufficient - it fails
           to clear the REQUEST latch because the device that caused the interrupt is
           still asserting its interrupt line at this point.
      
       (2) IRQ disablement [irq_chip::disable_irq()] shouldn't clear the interrupt
           request flag for edge-triggered interrupts lest it lose an interrupt.
      
       (3) IRQ unmasking [irq_chip::unmask_irq()] also shouldn't clear the interrupt
           request flag for edge-triggered interrupts lest it lose an interrupt.
      
       (4) The end() operation is now left to the default (no-operation) as
           __do_IRQ() is compiled out.  This may affect misrouted_irq(), but
           according to Thomas Gleixner it's the correct thing to do.
      
       (5) handle_level_irq() is used for edge-triggered interrupts rather than
           handle_edge_irq() as the MN10300 PIC latches interrupt events even on
           masked IRQ channels, thus rendering IRQ_PENDING unnecessary.  It is
           sufficient to call mask_ack() at the start and unmask() at the end.
      
       (6) For level-triggered interrupts, ack() is now NULL as it's not used, and
           there is no effective ACK function on the PIC.  mask_ack() is now the
           same as mask() as the latch continues to latch, even when the channel is
           masked.
      
      Further, the patch discards the disable() op implementation as its now the same
      as the mask() op implementation, which is used instead.
      
      It also discards the enable() op implementations as they're now the same as
      the unmask() op implementations, which are used instead.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d6478fad
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm · 7ac9c1c2
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm:
        dm mpath: add missing path switching locking
        dm: cope with access beyond end of device in dm_merge_bvec
        dm: always allow one page in dm_merge_bvec
      7ac9c1c2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · ae1cfb11
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        af_key: Free dumping state on socket close
        XFRM,IPv6: initialize ip6_dst_blackhole_ops.kmem_cachep
        ipv6: NULL pointer dereferrence in tcp_v6_send_ack
        tcp: Fix NULL dereference in tcp_4_send_ack()
        sctp: Fix kernel panic while process protocol violation parameter
        iucv: Fix mismerge again.
        ipsec: Fix pskb_expand_head corruption in xfrm_state_check_space
      ae1cfb11
    • Chandra Seetharaman's avatar
      dm mpath: add missing path switching locking · 7253a334
      Chandra Seetharaman authored
      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: default avatarChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      7253a334