summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2009-04-27skge: fix occasional BUG during MTU changeMichal Schmidt
upstream commit: d119b3927994e3d620d6adb0dd1ea6bf24427875 The BUG_ON(skge->tx_ring.to_use != skge->tx_ring.to_clean) in skge_up() was sometimes observed when setting MTU. skge_down() disables the TX queue, but then reenables it by mistake via skge_tx_clean(). Fix it by moving the waking of the queue from skge_tx_clean() to the other caller. And to make sure start_xmit is not in progress on another CPU, skge_down() should call netif_tx_disable(). The bug was reported to me by Jiri Jilek whose Debian system sometimes failed to boot. He tested the patch and the bug did not happen anymore. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27scsi: mpt: suppress debugobjects warningEric Paris
upstream commit: b298cecb3deddf76d60022473a57f1cb776cbdcd Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13133 ODEBUG: object is on stack, but not annotated ------------[ cut here ]------------ WARNING: at lib/debugobjects.c:253 __debug_object_init+0x1f3/0x276() Hardware name: VMware Virtual Platform Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi ext3 jbd mbcache Pid: 540, comm: insmod Not tainted 2.6.28-mm1 #2 Call Trace: [<c042c51c>] warn_slowpath+0x74/0x8a [<c0469600>] ? start_critical_timing+0x96/0xb7 [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c0446fad>] ? trace_hardirqs_off_caller+0x18/0xaf [<c044704f>] ? trace_hardirqs_off+0xb/0xd [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c042cb84>] ? release_console_sem+0x1a5/0x1ad [<c05013e6>] __debug_object_init+0x1f3/0x276 [<c0501494>] debug_object_init+0x13/0x17 [<c0433c56>] init_timer+0x10/0x1a [<e08e5b54>] mpt_config+0x1c1/0x2b7 [mptbase] [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase] [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase] [<e08e6fa2>] mpt_do_ioc_recovery+0x950/0x1212 [mptbase] [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c [<c060c3af>] ? _spin_unlock_irq+0x22/0x26 [<c04f2d8b>] ? string+0x2b/0x76 [<c04f310e>] ? vsnprintf+0x338/0x7b3 [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c044897d>] ? debug_check_no_locks_freed+0xeb/0x105 [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c [<c04488bc>] ? debug_check_no_locks_freed+0x2a/0x105 [<c0446b8c>] ? lock_release_holdtime+0x43/0x48 [<c043f742>] ? up_read+0x16/0x29 [<c05076f8>] ? pci_get_slot+0x66/0x72 [<e08e89ca>] mpt_attach+0x881/0x9b1 [mptbase] [<e091c8e5>] mptspi_probe+0x11/0x354 [mptspi] Noticing that every caller of mpt_config has its CONFIGPARMS struct declared on the stack and thus the &pCfg->timer is always on the stack I changed init_timer() to init_timer_on_stack() and it seems to have shut up..... Cc: "Moore, Eric Dean" <Eric.Moore@lsil.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: "Desai, Kashyap" <Kashyap.Desai@lsi.com> Cc: <stable@kernel.org> [2.6.29.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27agp: zero pages before sending to userspaceShaohua Li
upstream commit: 59de2bebabc5027f93df999d59cc65df591c3e6e CVE-2009-1192 AGP pages might be mapped into userspace finally, so the pages should be set to zero before userspace can use it. Otherwise there is potential information leakage. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27virtio: fix suspend when using virtio_balloonMarcelo Tosatti
upstream commit: 84a139a985300901dfad99bd93c7345d180af860 Break out of wait_event_interruptible() if freezing has been requested, in the vballoon thread. Without this change vballoon refuses to stop and the system can't suspend. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27Revert "console ASCII glyph 1:1 mapping"Samuel Thibault
upstream commit: c0b7988200a82290287c6f4cd49585007f73175a This reverts commit 1c55f18717304100a5f624c923f7cb6511b4116d. Ingo Brueckl was assuming that reverting to 1:1 mapping for chars >= 128 was not useful, but it happens to be: due to the limitations of the Linux console, when a blind user wants to read BIG5 on it, he has no other way than loading a font without SFM and let the 1:1 mapping permit the screen reader to get the BIG5 encoding. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27Input: gameport - fix attach driver codeDmitry Torokhov
upstream commit: 4ced8e7cb990a2c3bbf0ac7f27b35c890e7ce895 The commit 6902c0bead4ce266226fc0c5b3828b850bdc884a that moved driver registration out of kgameportd thread was incomplete and did not add the code necessary to actually attach driver to already registered devices, rectify that. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27USB: usb-storage: augment unusual_devs entry for Simple Tech/DatafabAlan Stern
upstream commit: e4813eec8d47c8299d968bd5349dc881fa481c26 This patch (as1227) adds the MAX_SECTORS_64 flag to the unusual_devs entry for the Simple Tech/Datafab controller. This fixes Bugzilla #12882. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: binbin <binbinsh@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27USB: fix oops in cdc-wdm in case of malformed descriptorsOliver Neukum
upstream commit: e13c594f3a1fc2c78e7a20d1a07974f71e4b448f cdc-wdm needs to ignore extremely malformed descriptors. Signed-off-by: Oliver Neukum <oliver@neukum.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27USB: ftdi_sio: add vendor/project id for JETI specbos 1201 spectrometerPeter Korsgaard
upstream commit: ae27d84351f1f3568118318a8c40ff3a154bd629 Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27usb gadget: fix ethernet link reports to ethtoolJonathan McDowell
upstream commit: 237e75bf1e558f7330f8deb167fa3116405bef2c The g_ether USB gadget driver currently decides whether or not there's a link to report back for eth_get_link based on if the USB link speed is set. The USB gadget speed is however often set even before the device is enumerated. It seems more sensible to only report a "link" if we're actually connected to a host that wants to talk to us. The patch below does this for me - tested with the PXA27x UDC driver. Signed-off-by: Jonathan McDowell <noodles@earth.li> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27SCSI: sg: fix q->queue_lock on scsi_error_handler pathFUJITA Tomonori
upstream commit: 015640edb1f346e0b2eda703587c4cd1c310ec1d sg_rq_end_io() is called via rq->end_io. In some rare cases, sg_rq_end_io calls blk_put_request/blk_rq_unmap_user (when a program issuing a command has gone before the command completion; e.g. by interrupting a program issuing a command before the command completes). We can't call blk_put_request/blk_rq_unmap_user in interrupt so the commit c96952ed7031e7c576ecf90cf95b8ec099d5295a uses execute_in_process_context(). The problem is that scsi_error_handler() calls rq->end_io too. We can't call blk_put_request/blk_rq_unmap_user too in this path (we hold q->queue_lock). To avoid the above problem, in these rare cases, this patch always uses schedule_work() instead of execute_in_process_context(). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Cc: Stable Tree <stable@kernel.org> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27SCSI: sg: avoid blk_put_request/blk_rq_unmap_user in interruptFUJITA Tomonori
upstream commit: c96952ed7031e7c576ecf90cf95b8ec099d5295a This fixes the following oops: http://marc.info/?l=linux-kernel&m=123316111415677&w=2 You can reproduce this bug by interrupting a program before a sg response completes. This leads to the special sg state (the orphan state), then sg calls blk_put_request in interrupt (rq->end_io). The above bug report shows the recursive lock problem because sg calls blk_put_request in interrupt. We could call __blk_put_request here instead however we also need to handle blk_rq_unmap_user here, which can't be called in interrupt too. In the orphan state, we don't need to care about the data transfer (the program revoked the command) so adding 'just free the resource' mode to blk_rq_unmap_user is a possible option. I prefer to avoid complicating the blk mapping API when possible. I change the orphan state to call sg_finish_rem_req via execute_in_process_context. We hold sg_fd->kref so sg_fd doesn't go away until keventd_wq finishes our work. copy_from_user/to_user fails so blk_rq_unmap_user just frees the resource without the data transfer. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27SCSI: sg: fix races with ioctl(SG_IO)Tony Battersby
upstream commit: a2dd3b4cea335713b58996bb07b3abcde1175f47 sg_io_owned needs to be set before the command is sent to the midlevel; otherwise, a quickly-completing command may cause a different CPU to see "srp->done == 1 && !srp->sg_io_owned", which would lead to incorrect behavior. Check srp->done and set srp->orphan while holding rq_list_lock to prevent races with sg_rq_end_io(). There is no need to check sfp->closed from read/write/ioctl/poll/etc. since the kernel guarantees that this won't happen. The usefulness of sg_srp_done() was questionable before; now it is definitely not needed. Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27SCSI: sg: fix races during device removalTony Battersby
upstream commit: c6517b7942fad663cc1cf3235cbe4207cf769332 sg has the following problems related to device removal: * opening a sg fd races with removing a device * closing a sg fd races with removing a device * /proc/scsi/sg/* access races with removing a device * command completion races with removing a device * command completion races with closing a sg fd * can rmmod sg with active commands These problems can cause kernel oopses, memory-use-after-free, or double-free errors. This patch fixes these problems by using krefs to manage the lifetime of sg_device and sg_fd. Each command submitted to the midlevel holds a reference to sg_fd until the completion callback. This ensures that sg_fd doesn't go away if the fd is closed with commands still outstanding. sg_fd gets the reference of sg_device (with scsi_device) and also makes sure that the sg module doesn't go away. /proc/scsi/sg/* functions don't play nicely with krefs because they give information about sg_fds which have been closed but not yet freed due to still having outstanding commands and sg_devices which have been removed but not yet freed due to still being referenced by one or more sg_fds. To deal with this safely without removing functionality, /proc functions now access sg_device and sg_fd while holding a lock instead of using kref_get()/kref_put(). Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> [chrisw: big for -stable, helps fix real bug, and made it through rc2 upstream] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27pata_hpt37x: fix HPT370 DMA timeoutsSergei Shtylyov
upstream commit: 265b7215aed36941620b65ecfff516200fb190c1 The libata driver has copied the code from the IDE driver which caused a post 2.4.18 regression on many HPT370[A] chips -- DMA stopped to work completely, only causing timeouts. Now remove hpt370_bmdma_start() for good... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27hpt366: fix HPT370 DMA timeoutsSergei Shtylyov
upstream commit: c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac The big driver change in 2.4.19-rc1 introduced a regression for many HPT370[A] chips -- DMA stopped to work completely, only causing endless timeouts... The culprit has been identified (at last!): it turned to be the code resetting the DMA state machine before each transfer. Stop doing it now as this counter- measure has clearly caused more harm than good. This should fix the kernel.org bug #7703. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27sfc: Match calls to netif_napi_add() and netif_napi_del()Ben Hutchings
upstream commit: 718cff1eec595ce6ab0635b8160a51ee37d9268d sfc could call netif_napi_add() multiple times for the same napi_struct, corrupting the list of napi_structs for the associated device and leading to a busy-loop on device removal. Move the call to netif_napi_add() and add a call to netif_napi_del() in the obvious places. [bhutchings: backport to 2.6.29] Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27tty: Fix leak in ti-usbAlan Cox
upstream commit: cf5450930db0ae308584e5361f3345e0ff73e643 If the ti-usb adapter returns an zero data length frame (which happens) then we leak a kref. Found by Christoph Mair <christoph.mair@gmail.com> who proposed a patch. The patch here is different as Christoph's patch didn't work for the case where tty = NULL and data arrived but Christoph did all the hard work chasing it down. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27spi: spi_write_then_read() bugfixesDavid Brownell
upstream commit: bdff549ebeff92b1a6952e5501caf16a6f8898c8 The "simplify spi_write_then_read()" patch included two regressions from the 2.6.27 behaviors: - The data it wrote out during the (full duplex) read side of the transfer was not zeroed. - It fails completely on half duplex hardware, such as Microwire and most "3-wire" SPI variants. So, revert that patch. A revised version should be submitted at some point, which can get the speedup on standard hardware (full duplex) without breaking on less-capable half-duplex stuff. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: <stable@kernel.org> [2.6.28.x, 2.6.29.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm kcopyd: fix callback raceMikulas Patocka
upstream commit: 340cd44451fb0bfa542365e6b4b565bbd44836e2 If the thread calling dm_kcopyd_copy is delayed due to scheduling inside split_job/segment_complete and the subjobs complete before the loop in split_job completes, the kcopyd callback could be invoked from the thread that called dm_kcopyd_copy instead of the kcopyd workqueue. dm_kcopyd_copy -> split_job -> segment_complete -> job->fn() Snapshots depend on the fact that callbacks are called from the singlethreaded kcopyd workqueue and expect that there is no racing between individual callbacks. The racing between callbacks can lead to corruption of exception store and it can also mean that exception store callbacks are called twice for the same exception - a likely reason for crashes reported inside pending_complete() / remove_exception(). This patch fixes two problems: 1. job->fn being called from the thread that submitted the job (see above). - Fix: hand over the completion callback to the kcopyd thread. 2. job->fn(read_err, write_err, job->context); in segment_complete reports the error of the last subjob, not the union of all errors. - Fix: pass job->write_err to the callback to report all error bits (it is done already in run_complete_job) Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm kcopyd: prepare for callback race fixMikulas Patocka
upstream commit: 73830857bca6f6c9dbd48e906daea50bea42d676 Use a variable in segment_complete() to point to the dm_kcopyd_client struct and only release job->pages in run_complete_job() if any are defined. These changes are needed by the next patch. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27SCSI: libiscsi: fix iscsi pool error pathJean Delvare
upstream commit: fd6e1c14b73dbab89cb76af895d5612e4a8b5522 Le lundi 30 mars 2009, Chris Wright a écrit : > q->queue could be ERR_PTR(-ENOMEM) which will break unwinding > on error. Make iscsi_pool_free more defensive. > Making the freeing of q->queue dependent on q->pool being set looks really weird (although it is correct at the moment. But this seems to be fixable in a much simpler way. With the benefit that only the error case is slowed down. In both cases we have a problem if q->queue contains an error value but it's not -ENOMEM. Apparently this can't happen today, but it doesn't feel right to assume this will always be true. Maybe it's the right time to fix this as well. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> [chrisw: this is a fixlet to f474a37b, also in -stable] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27SCSI: libiscsi: fix iscsi pool error pathJean Delvare
upstream commit: f474a37bc48667595b5653a983b635c95ed82a3b Memory freeing in iscsi_pool_free() looks wrong to me. Either q->pool can be NULL and this should be tested before dereferencing it, or it can't be NULL and it shouldn't be tested at all. As far as I can see, the only case where q->pool is NULL is on early error in iscsi_pool_init(). One possible way to fix the bug is thus to not call iscsi_pool_free() in this case (nothing needs to be freed anyway) and then we can get rid of the q->pool check. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27acer-wmi: Blacklist Acer Aspire OneCarlos Corbacho
upstream commit: a74dd5fdabcd34c93e17e9c7024eeb503c92b048 The Aspire One's ACPI-WMI interface is a placeholder that does nothing, and the invalid results that we get from it are now causing userspace problems as acer-wmi always returns that the rfkill is enabled (i.e. the radio is off, when it isn't). As it's hardware controlled, acer-wmi isn't needed on the Aspire One either. Thanks to Andy Whitcroft at Canonical for tracking down Ubuntu's userspace issues to this. Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Reported-by: Andy Whitcroft <apw@canonical.com> Cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm table: fix upgrade mode raceAlasdair G Kergon
upstream commit: 570b9d968bf9b16974252ef7cbce73fa6dac34f3 upgrade_mode() sets bdev to NULL temporarily, and does not have any locking to exclude anything from seeing that NULL. In dm_table_any_congested() bdev_get_queue() can dereference that NULL and cause a reported oops. Fix this by not changing that field during the mode upgrade. Cc: stable@kernel.org Cc: Neil Brown <neilb@suse.de> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm: path selector use module refcount directlyJun'ichi Nomura
upstream commit: aea9058801c0acfa2831af1714da412dfb0018c2 Fix refcount corruption in dm-path-selector Refcounting with non-atomic ops under shared lock will corrupt the counter in multi-processor system and may trigger BUG_ON(). Use module refcount. # same approach as dm-target-use-module-refcount-directly.patch here # https://www.redhat.com/archives/dm-devel/2008-December/msg00075.html Typical oops: kernel BUG at linux-2.6.29-rc3/drivers/md/dm-path-selector.c:90! Pid: 11148, comm: dmsetup Not tainted 2.6.29-rc3-nm #1 dm_put_path_selector+0x4d/0x61 [dm_multipath] Call Trace: [<ffffffffa031d3f9>] free_priority_group+0x33/0xb3 [dm_multipath] [<ffffffffa031d4aa>] free_multipath+0x31/0x67 [dm_multipath] [<ffffffffa031d50d>] multipath_dtr+0x2d/0x32 [dm_multipath] [<ffffffffa015d6c2>] dm_table_destroy+0x64/0xd8 [dm_mod] [<ffffffffa015b73a>] __unbind+0x46/0x4b [dm_mod] [<ffffffffa015b79f>] dm_swap_table+0x60/0x14d [dm_mod] [<ffffffffa015f963>] dev_suspend+0xfd/0x177 [dm_mod] [<ffffffffa0160250>] dm_ctl_ioctl+0x24c/0x29c [dm_mod] [<ffffffff80288cd3>] ? get_page_from_freelist+0x49c/0x61d [<ffffffffa015f866>] ? dev_suspend+0x0/0x177 [dm_mod] [<ffffffff802bf05c>] vfs_ioctl+0x2a/0x77 [<ffffffff802bf4f1>] do_vfs_ioctl+0x448/0x4a0 [<ffffffff802bf5a0>] sys_ioctl+0x57/0x7a [<ffffffff8020c05b>] system_call_fastpath+0x16/0x1b Cc: stable@kernel.org Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm target: use module refcount directlyCheng Renquan
upstream commit: 5642b8a61a15436231adf27b2b1bd96901b623dd The tt_internal's 'use' field is superfluous: the module's refcount can do the work properly. An acceptable side-effect is that this increases the reference counts reported by 'lsmod'. Remove the superfluous test when removing a target module. [Crash possible without this on SMP - agk] Cc: stable@kernel.org Signed-off-by: Cheng Renquan <crquan@gmail.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Reviewed-by: Alasdair G Kergon <agk@redhat.com> Reviewed-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm snapshot: avoid having two exceptions for the same chunkMikulas Patocka
upstream commit: 35bf659b008e83e725dcd30f542e38461dbb867c We need to check if the exception was completed after dropping the lock. After regaining the lock, __find_pending_exception checks if the exception was already placed into &s->pending hash. But we don't check if the exception was already completed and placed into &s->complete hash. If the process waiting in alloc_pending_exception was delayed at this point because of a scheduling latency and the exception was meanwhile completed, we'd miss that and allocate another pending exception for already completed chunk. It would lead to a situation where two records for the same chunk exist and potential data corruption because multiple snapshot I/Os to the affected chunk could be redirected to different locations in the snapshot. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm snapshot: avoid dropping lock in __find_pending_exceptionMikulas Patocka
upstream commit: c66213921c816f6b1b16a84911618ba9a363b134 It is uncommon and bug-prone to drop a lock in a function that is called with the lock held, so this is moved to the caller. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm snapshot: refactor __find_pending_exceptionMikulas Patocka
upstream commit: 2913808eb56a6445a7b277eb8d17651c8defb035 Move looking-up of a pending exception from __find_pending_exception to another function. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm io: make sync_io uninterruptibleMikulas Patocka
upstream commit: b64b6bf4fd8b678a9f8477c11773c38a0a246a6d If someone sends signal to a process performing synchronous dm-io call, the kernel may crash. The function sync_io attempts to exit with -EINTR if it has pending signal, however the structure "io" is allocated on stack, so already submitted io requests end up touching unallocated stack space and corrupting kernel memory. sync_io sets its state to TASK_UNINTERRUPTIBLE, so the signal can't break out of io_schedule() --- however, if the signal was pending before sync_io entered while (1) loop, the corruption of kernel memory will happen. There is no way to cancel in-progress IOs, so the best solution is to ignore signals at this point. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm raid1: switch read_record from kmalloc to slab to save memoryMikulas Patocka
upstream commit: 95f8fac8dc6139fedfb87746e0c8fda9b803cb46 With my previous patch to save bi_io_vec, the size of dm_raid1_read_record is significantly increased (the vector list takes 3072 bytes on 32-bit machines and 4096 bytes on 64-bit machines). The structure dm_raid1_read_record used to be allocated with kmalloc, but kmalloc aligns the size on the next power-of-two so an object slightly greater than 4096 will allocate 8192 bytes of memory and half of that memory will be wasted. This patch turns kmalloc into a slab cache which doesn't have this padding so it will reduce the memory consumed. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dm: preserve bi_io_vec when resubmitting biosMikulas Patocka
upstream commit: a920f6b3accc77d9dddbc98a7426be23ee479625 Device mapper saves and restores various fields in the bio, but it doesn't save bi_io_vec. If the device driver modifies this after a partially successful request, dm-raid1 and dm-multipath may attempt to resubmit a bio that has bi_size inconsistent with the size of vector. To make requests resubmittable in dm-raid1 and dm-multipath, we must save and restore the bio vector as well. To reduce the memory overhead involved in this, we do not save the pages in a vector and use a 16-bit field size if the page size is less than 65536. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27ixgbe: Fix potential memory leak/driver panic issue while setting up Tx & Rx ↵Mallikarjuna R Chilakala
ring parameters upstream commit: f9ed88549e2ec73922b788e3865282d221233662 While setting up the ring parameters using ethtool the driver can panic or leak memory as ixgbe_open tries to setup tx & rx resources. The updated logic will use ixgbe_down/up after successful allocation of tx & rx resources Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27ide-atapi: start DMA after issuing a packet commandBorislav Petkov
upstream commit: 2eba08270990b99fb5429b76ee97184ddd272f7f Apparently¹, some ATAPI devices want to see the packet command first before enabling DMA otherwise they simply hang indefinitely. Reorder the two steps and start DMA only after having issued the command first. [1] http://marc.info/?l=linux-kernel&m=123835520317235&w=2 Signed-off-by: Borislav Petkov <petkovbb@gmail.com> Reported-by: Michael Roth <mroth@nessie.de> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27ide: drivers/ide/ide-atapi.c needs <linux/scatterlist.h>Geert Uytterhoeven
upstream commit: 479edf065576aeed7ac99d10838bb3b4f870b5f9 On m68k: | drivers/ide/ide-atapi.c: In function 'ide_io_buffers': | drivers/ide/ide-atapi.c:87: error: implicit declaration of function 'sg_page' | drivers/ide/ide-atapi.c:87: warning: passing argument 1 of 'PageHighMem' makes pointer from integer without a cast | drivers/ide/ide-atapi.c:91: warning: passing argument 1 of 'kmap_atomic' makes pointer from integer without a cast | drivers/ide/ide-atapi.c:96: error: implicit declaration of function 'sg_virt' | drivers/ide/ide-atapi.c:96: warning: assignment makes pointer from integer without a cast | drivers/ide/ide-atapi.c:107: error: implicit declaration of function 'sg_next' | drivers/ide/ide-atapi.c:107: warning: assignment makes pointer from integer without a cast [bart: Dmitri Vorobiev submitted similar patch fixing MIPS] Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Dmitri Vorobiev <dmitri.vorobiev@movial.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27V4L/DVB (10943): cx88: Prevent general protection fault on rmmodJean Delvare
upstream commit: 569b7ec73abf576f9a9e4070d213aadf2cce73cb When unloading the cx8800 driver I sometimes get a general protection fault. Analysis revealed a race in cx88_ir_stop(). It can be solved by using a delayed work instead of a timer for infrared input polling. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27r8169: Reset IntrStatus after chip resetFrancois Romieu
upstream commit: d78ad8cbfe73ad568de38814a75e9c92ad0a907c Original comment (Karsten): On a MSI MS-6702E mainboard, when in rtl8169_init_one() for the first time after BIOS has run, IntrStatus reads 5 after chip has been reset. IntrStatus should equal 0 there, so patch changes IntrStatus reset to happen after chip reset instead of before. Remark (Francois): Assuming that the loglevel of the driver is increased above NETIF_MSG_INTR, the bug reveals itself with a typical "interrupt 0025 in poll" message at startup. In retrospect, the message should had been read as an hint of an unexpected hardware state several months ago :o( Fixes (at least part of) https://bugzilla.redhat.com/show_bug.cgi?id=460747 Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Josep <josep.puigdemont@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27md/raid1 - don't assume newly allocated bvecs are initialised.NeilBrown
upstream commit: 303a0e11d0ee136ad8f53f747f3c377daece763b Since commit d3f761104b097738932afcc310fbbbbfb007ef92 newly allocated bvecs aren't initialised to NULL, so we have to be more careful about freeing a bio which only managed to get a few pages allocated to it. Otherwise the resync process crashes. This patch is appropriate for 2.6.29-stable. Cc: stable@kernel.org Cc: "Jens Axboe" <jens.axboe@oracle.com> Reported-by: Gabriele Tozzi <gabriele@tozzi.eu> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27SCSI: sg: fix iovec bugs introduced by the block layer conversionFUJITA Tomonori
upstream commit: 0fdf96b67ac2649cc1ddb29b316a0db11586c6a8 - needs to use copy_from_user for iovec before passing it to blk_rq_map_user_iov(). - before the block layer conversion, if ->dxfer_len and sum of iovec disagrees, the shorter one wins. However, currently sg returns -EINVAL. This restores the old behavior. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Cc: stable@kernel.org Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm/i915: fix TV mode setting in property changeZhenyu Wang
upstream commit: 7d6ff7851c23740c3813bdf457be638381774b69 Only set TV DAC in property change seems doesn't work, we have to setup whole crtc pipe which assigned to TV alone. Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com> [anholt: Note that this should also fix the oops at startup with new 2D] Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm/i915: only set TV mode when any property changedZhenyu Wang
upstream commit: ebcc8f2eade76946dbb5d5c545b91f8157051aa8 If there's no real property change, don't need to set TV mode again. Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com> [anholt: checkpatch.pl fix] Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm: Use pgprot_writecombine in GEM GTT mapping to get the right bits for !PAT.Jesse Barnes
upstream commit: 1055f9ddad093f54dfd708a0f976582034d4ce1a Otherwise, the PAGE_CACHE_WC would end up getting us a UC-only mapping, and the write performance of GTT maps dropped 10x. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: cleaned up unused var] Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm/i915: check for -EINVAL from vm_insert_pfnJesse Barnes
upstream commit: 959b887cf42fd63cf10e28a7f26126f78aa1c0b0 Indicates something is wrong with the mapping; and apparently triggers in current kernels. Signed-off-by: Jesse Barnes <jbarnes@virtuosugeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm/i915: Check for dev->primary->master before dereference.Chris Wilson
upstream commit: 98787c057fdefdce6230ff46f2c1105835005a4c I've hit the occasional oops inside i915_wait_ring() with an indication of a NULL derefence of dev->primary->master. Adding a NULL check is consistent with the other potential users of dev->primary->master. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm/i915: Sync crt hotplug detection with intel video driverZhao Yakui
upstream commit: 771cb081354161eea21534ba58e5cc1a2db94a25 This covers: Use long crt hotplug activation time on GM45. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm/i915: Read the right SDVO register when detecting SVDO/HDMI.Kristian Høgsberg
upstream commit: 13520b051e8888dd3af9bda639d83e7df76613d1 This fixes incorrect detection of the second SDVO/HDMI output on G4X, and extra boot time on pre-G4X. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27drm/i915: Change DCC tiling detection case to cover only mobile parts.Eric Anholt
upstream commit: 568d9a8f6d4bf81e0672c74573dc02981d31e3ea Later spec investigation has revealed that every 9xx mobile part has had this register in this format. Also, no non-mobile parts have been shown to have this register. So make all mobile use the same code, and all non-mobile use the hack 965 detection. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27dock: fix dereference after kfree()Dan Carpenter
upstream commit: f240729832dff3785104d950dad2d3ced4387f6d dock_remove() calls kfree() on dock_station so we should use list_for_each_entry_safe() to avoid dereferencing freed memory. Found by smatch (http://repo.or.cz/w/smatch.git/). Compile tested. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27rt2x00: Fix SLAB corruption during rmmodGertjan van Wingerde
At rmmod stage, the code path is the following one : rt2x00lib_remove_dev   ->  rt2x00lib_uninitialize()         -> rt2x00rfkill_unregister()              -> rfkill_unregister()         -> rt2x00rfkill_free()              -> rfkill_free() The problem is that rfkill_free should not be called after rfkill_register otherwise put_device(&rfkill->dev) will be called 2 times. This patch fixes this by only calling rt2x00rfkill_free() when rt2x00rfkill_register() hasn't been called or has failed. This patch is for 2.6.29 only. The code in question has completely disappeared in 2.6.30 and does not contain this bug. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Tested-by: Arnaud Patard <apatard@mandriva.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-11-16 21:34:52 +0000