linux/drivers, branch v2.6.26.6

rtc: fix kernel panic on second use of SIGIO nofitication

2008-10-09T03:23:11Z

commit 2e4a75cdcb89ff53bb182dda3a6dcdc14befe007 upstream 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:[] [] __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: [] lock_acquire+0x85/0xa9 [] ? send_sigio+0x2a/0x184 [] _read_lock+0x3e/0x4a [] ? send_sigio+0x2a/0x184 [] send_sigio+0x2a/0x184 [] ? __lock_acquire+0x6e1/0x73f [] ? kill_fasync+0x2c/0x4e [] __kill_fasync+0x54/0x65 [] kill_fasync+0x3a/0x4e [] rtc_update_irq+0x9c/0xa5 [] cmos_interrupt+0xae/0xc0 [] handle_IRQ_event+0x25/0x5a [] handle_edge_irq+0xdd/0x123 [] do_IRQ+0xe4/0x144 [] ret_from_intr+0x0/0xf [] ? __alloc_pages_internal+0xe7/0x3ad [] ? clear_page_c+0x7/0x10 [] ? get_page_from_freelist+0x385/0x450 [] ? __alloc_pages_internal+0xe7/0x3ad [] ? anon_vma_prepare+0x2e/0xf6 [] ? handle_mm_fault+0x227/0x6a5 [] ? do_page_fault+0x494/0x83f [] ? 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 [] __lock_acquire+0x3db/0x73f RSP ---[ end trace 431877d860448760 ]--- Kernel panic - not syncing: Aiee, killing interrupt handler! Signed-off-by: Marcin Slusarz Acked-by: Alessandro Zummo Acked-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fbcon: fix monochrome color value calculation

2008-10-09T03:23:11Z

commit 08650869e0ec581f8d88cfdb563d37f5383abfe2 upstream Commit 22af89aa0c0b4012a7431114a340efd3665a7617 ("fbcon: replace mono_col macro with static inline") changed the order of operations for computing monochrome color values. This generates 0xffff000f instead of 0x0000000f for a 4 bit monochrome color, leading to image corruption if it is passed to cfb_imageblit or other similar functions. Fix it up. Cc: Harvey Harrison Cc: "Antonino A. Daplas" Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

braille_console: only register notifiers when the braille console is used

2008-10-09T03:23:11Z

commit c0c9209ddd96bc4f1d70a8b9958710671e076080 upstream Only register the braille driver VT and keyboard notifiers when the braille console is used. Avoids eating insert or backspace keys. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11242 Signed-off-by: Pascal Terjan Signed-off-by: Samuel Thibault Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Moritz Muehlenhoff Signed-off-by: Greg Kroah-Hartman

niu: panic on reset

2008-10-09T03:23:06Z

[ Upstream commit cff502a38394fd33693f6233e03fca363dfa956d ] The reset_task function in the niu driver does not reset the tx and rx buffers properly. This leads to panic on reset. This patch is a modified implementation of the previously posted fix. Signed-off-by: Santwona Behera Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

pcmcia: Fix broken abuse of dev->driver_data

2008-10-09T03:23:06Z

[ Upstream commit: cec5eb7be3a104fffd27ca967ee8e15a123050e2 ] PCMCIA abuses dev->private_data in the probe methods. Unfortunately it continues to abuse it after calling drv->probe() which leads to crashes and other nasties (such as bogus probes of multifunction devices) giving errors like pcmcia: registering new device pcmcia0.1 kernel: 0.1: GetNextTuple: No more items Extract the passed data before calling the driver probe function that way we don't blow up when the driver reuses dev->private_data as its right. Signed-off-by: Alan Cox Signed-off-by: Dominik Brodowski Signed-off-by: Greg Kroah-Hartman

ACPI: Avoid bogus EC timeout when EC is in Polling mode

2008-10-09T03:23:01Z

commit 9d699ed92a459cb408e2577e8bbeabc8ec3989e1 upstream When EC is in Polling mode, OS will check the EC status continually by using the following source code: clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags); while (time_before(jiffies, delay)) { if (acpi_ec_check_status(ec, event)) return 0; msleep(1); } But msleep is realized by the function of schedule_timeout. At the same time although one process is already waken up by some events, it won't be scheduled immediately. So maybe there exists the following phenomena: a. The current jiffies is already after the predefined jiffies. But before timeout happens, OS has no chance to check the EC status again. b. If preemptible schedule is enabled, maybe preempt schedule will happen before checking loop. When the process is resumed again, maybe timeout already happens, which means that OS has no chance to check the EC status. In such case maybe EC status is already what OS expects when timeout happens. But OS has no chance to check the EC status and regards it as AE_TIME. So it will be more appropriate that OS will try to check the EC status again when timeout happens. If the EC status is what we expect, it won't be regarded as timeout. Only when the EC status is not what we expect, it will be regarded as timeout, which means that EC controller can't give a response in time. http://bugzilla.kernel.org/show_bug.cgi?id=9823 http://bugzilla.kernel.org/show_bug.cgi?id=11141 Signed-off-by: Zhao Yakui Signed-off-by: Zhang Rui Signed-off-by: Andi Kleen Signed-off-by: Greg Kroah-Hartman

rt2x00: Use ieee80211_hw->workqueue again

2008-10-09T03:22:59Z

commit 8e260c22238dd8b57aefb1f5e4bd114486a9c17d upstream Remove the rt2x00 singlethreaded workqueue and move the link tuner and packet filter scheduled work to the ieee80211_hw->workqueue again. The only exception is the interface scheduled work handler which uses the mac80211 interface iterator under the RTNL lock. This work needs to be handled on the kernel workqueue to prevent lockdep issues. Signed-off-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Defer enablement of RISC interrupts until ISP initialization completes.

2008-10-09T03:22:51Z

commit 048feec5548c0582ee96148c61b87cccbcb5f9be upstream Josip Rodin noted (http://article.gmane.org/gmane.linux.ports.sparc/10152) the driver oopsing during registration of an rport to the FC-transport layer with a backtrace indicating a dereferencing of an shost->shost_data equal to NULL. David Miller identified a small window in driver logic where this could happen: > Look at how the driver registers the IRQ handler before the host has > been registered with the SCSI layer. > > That leads to a window of time where the shost hasn't been setup > fully, yet ISRs can come in and trigger DPC thread events, such as > loop resyncs, which expect the transport area to be setup. > > But it won't be setup, because scsi_add_host() hasn't finished yet. > > Note that in Josip's crash log, we don't even see the > > qla_printk(KERN_INFO, ha, "\n" > " QLogic Fibre Channel HBA Driver: %s\n" > " QLogic %s - %s\n" > " ISP%04X: %s @ %s hdma%c, host#=%ld, fw=%s\n", > ... > > message yet. > > Which means that the crash occurs between qla2x00_request_irqs() > and printing that message. Close this window by enabling RISC interrupts after the host has been registered with the SCSI midlayer. Reported-by: Josip Rodin Signed-off-by: Andrew Vasquez Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

USB: fix hcd interrupt disabling

2008-10-09T03:22:51Z

commit 83a798207361cc26385187b2e71efa2b5d75de7f upstream Commit de85422b94ddb23c021126815ea49414047c13dc, 'USB: fix interrupt disabling for HCDs with shared interrupt handlers' changed usb_add_hcd() to strip IRQF_DISABLED from irqflags prior to calling request_irq() with the justification that such a removal was necessary for shared interrupts to work properly. Unfortunately, the change in that commit unconditionally removes the IRQF_DISABLED flag, causing problems on platforms that don't use a shared interrupt but require IRQF_DISABLED. This change adds a check for IRQF_SHARED prior to removing the IRQF_DISABLED flag. Fixes the PS3 system startup hang reported with recent Fedora and OpenSUSE kernels. Note that this problem is hidden when CONFIG_LOCKDEP=y (ps3_defconfig), as local_irq_enable_in_hardirq() is defined as a null statement for that config. Signed-off-by: Geoff Levand Cc: Alan Stern Cc: Stefan Becker Signed-off-by: Greg Kroah-Hartman

pxa2xx_spi: fix build breakage

2008-10-09T03:22:50Z

commit 20b918dc77b383e9779dafceee3f2198a6f7b0e5 upstream This patch fixes a build error in the pxa2xx-spi driver, introduced by commit 7e96445533ac3f4f7964646a202ff3620602fab4 ("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: Mike Rapoport Acked-by: Eric Miao Signed-off-by: Andrew Morton Signed-off-by: David Brownell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman