- 08 Aug, 2011 37 commits
-
-
Alan Stern authored
commit e04f5f7e upstream. This patch (as1480) fixes a rather obscure bug in ehci-hcd. The qh_update() routine needs to know the number and direction of the endpoint corresponding to its QH argument. The number can be taken directly from the QH data structure, but the direction isn't stored there. The direction is taken instead from the first qTD linked to the QH. However, it turns out that for interrupt transfers, qh_update() gets called before the qTDs are linked to the QH. As a result, qh_update() computes a bogus direction value, which messes up the endpoint toggle handling. Under the right combination of circumstances this causes usb_reset_endpoint() not to work correctly, which causes packets to be dropped and communications to fail. Now, it's silly for the QH structure not to have direct access to all the descriptor information for the corresponding endpoint. Ultimately it may get a pointer to the usb_host_endpoint structure; for now, adding a copy of the direction flag solves the immediate problem. This allows the Spyder2 color-calibration system (a low-speed USB device that sends all its interrupt data packets with the toggle set to 0 and hance requires constant use of usb_reset_endpoint) to work when connected through a high-speed hub. Thanks to Graeme Gill for supplying the hardware that allowed me to track down this bug. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Graeme Gill <graeme@argyllcms.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sergei Shtylyov authored
commit 81463c1d upstream. MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by:
-
J. Bruce Fields authored
commit ebc63e53 upstream. After commit 3262c816 "[PATCH] knfsd: split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no longer removed its xpt_ready (then sk_ready) field from whatever list it was on, noting that there was no point since the whole list was about to be destroyed anyway. That was mostly true, but forgot that a few svc_xprt_enqueue()'s might still be hanging around playing with the about-to-be-destroyed list, and could get themselves into trouble writing to freed memory if we left this xprt on the list after freeing it. (This is actually functionally identical to a patch made first by Ben Greear, but with more comments.) Cc: gnb@fmeh.org Reported-by:
Ben Greear <greearb@candelatech.com> Tested-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Jan Kara authored
commit ad95c5e9 upstream. Block allocation is called from two places: ext3_get_blocks_handle() and ext3_xattr_block_set(). These two callers are not necessarily synchronized because xattr code holds only xattr_sem and i_mutex, and ext3_get_blocks_handle() may hold only truncate_mutex when called from writepage() path. Block reservation code does not expect two concurrent allocations to happen to the same inode and thus assertions can be triggered or reservation structure corruption can occur. Fix the problem by taking truncate_mutex in xattr code to serialize allocations. CC: Sage Weil <sage@newdream.net> Reported-by:
Fyodor Ustinov <ufm@ufm.su> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Dan Rosenberg authored
commit 0d0138eb upstream. Prevent an arbitrary kernel read. Check the user pointer with access_ok() before copying data in. [akpm@linux-foundation.org: s/EIO/EFAULT/] Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Cc: Christian Zankel <chris@zankel.net> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Stephen M. Cameron authored
commit 07d0c38e upstream. Most smartarrays will tolerate it, but some new ones don't. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Note: this is a regression caused by commit 1ddd5049Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Chris Wright authored
commit 864d296c upstream. The function pci_enable_ari() may mistakenly set the downstream port of a v1 PCIe switch in ARI Forwarding mode. This is a PCIe v2 feature, and with an SR-IOV device on that switch port believing the switch above is ARI capable it may attempt to use functions 8-255, translating into invalid (non-zero) device numbers for that bus. This has been seen to cause Completion Timeouts and general misbehaviour including hangs and panics. Acked-by:
Don Dutile <ddutile@redhat.com> Tested-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Michael Neuling authored
commit 63f21a56 upstream. The existing code it pretty ugly. How about we clean it up even more like this? From: Anton Blanchard <anton@samba.org> We check for timeout expiry in the outer loop, but we also need to check it in the inner loop or we can lock up forever waiting for a CPU to hit real mode. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Huang Ying authored
commit 050438ed upstream. In kexec jump support, jump back address passed to the kexeced kernel via function calling ABI, that is, the function call return address is the jump back entry. Furthermore, jump back entry == 0 should be used to signal that the jump back or preserve context is not enabled in the original kernel. But in the current implementation the stack position used for function call return address is not cleared context preservation is disabled. The patch fixes this bug. Reported-and-tested-by:
Yin Kangkai <kangkai.yin@intel.com> Signed-off-by:
Huang Ying <ying.huang@intel.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@redhat.com> Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Dan Rosenberg authored
commit b5b51544 upstream. There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. First, the user can call pmcraid_chr_ioctl(), with a type PMCRAID_PASSTHROUGH_IOCTL. This calls through to pmcraid_ioctl_passthrough(). Next, a pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user. If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked. It looks like preventing this value from being negative in pmcraid_ioctl_passthrough() would be sufficient. Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Douglas Gilbert authored
commit 2a350cab upstream. Noticed that when the sysfs interface of the SCSI SES driver was used to request a fault indication the LED flashed but the buzzer didn't sound. So it was doing what REQUEST IDENT (locate) should do. Changelog: - fix the setting of REQUEST FAULT for the device slot and array device slot elements in the enclosure control diagnostic page - note the potentially defective code that reads the FAULT SENSED and FAULT REQUESTED bits from the enclosure status diagnostic page The attached patch is against git/scsi-misc-2.6 Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Werner Fink authored
commit 82103978 upstream. This patch resulted from the discussion at https://bugzilla.novell.com/show_bug.cgi?id=679277, https://bugzilla.novell.com/show_bug.cgi?id=681840 . Signed-off-by:
Werner Fink <werner@novell.com> Signed-off-by:
Ankit Jain <jankit@suse.de> Signed-off-by:
-
Rajkumar Manoharan authored
commit 676b58c2 upstream. A panic was observed when the device is failed to resume properly, and there are no running interfaces. ieee80211_reconfig tries to restart STA timers on unassociated state. Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Luben Tuikov authored
commit 5911e963 upstream. If expander discovery fails (sas_discover_expander()), remove the expander from the port device list (sas_ex_discover_expander()), before freeing it. Else the list is corrupted and, e.g., when we attempt to send SMP commands to other devices, the kernel oopses. Signed-off-by:
Luben Tuikov <ltuikov@yahoo.com> Reviewed-by:
Jack Wang <jack_wang@usish.com> Signed-off-by:
-
Guo-Fu Tseng authored
commit 94c5b41b upstream. This patch add the missing dma_unmap(). Which solved the critical issue of system freeze on heavy load. Michal Miroslaw's rejected patch: [PATCH v2 10/46] net: jme: convert to generic DMA API Pointed out the issue also, thank you Michal. But the fix was incorrect. It would unmap needed address when low memory. Got lots of feedback from End user and Gentoo Bugzilla. https://bugs.gentoo.org/show_bug.cgi?id=373109 Thank you all. :) Signed-off-by:
Guo-Fu Tseng <cooldavid@cooldavid.org> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Igor Grinberg authored
commit 6c7b3ea5 upstream. While in sleep mode the CS# and other V3020 RTC GPIOs must be driven high, otherwise V3020 RTC fails to keep the right time in sleep mode. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Alan Stern authored
commit c5c69f3f upstream. Like with other host controllers capable of operating at both high speed and full speed, we need to indicate that the emulated controller presented by dummy-hcd has this ability. Otherwise usbcore will not accept full-speed gadgets under dummy-hcd. This patch (as1469) sets the appropriate has_tt flag. Signed-off-by:
-
Ajay Kumar Gupta authored
commit 3c5fec75 upstream. Restoring the missing INDEX register value in musb_restore_context(). Without this suspend resume functionality is broken with offmode enabled. Acked-by:
Anand Gadiyar <gadiyar@ti.com> Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alan Stern authored
commit 6ea12a04 upstream. The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related. It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware). The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly. This fixes Bugzilla #22052. Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Vasiliy Kulikov authored
commit 819cbb12 upstream. driver_name and board_name are pointers to strings, not buffers of size COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Signed-off-by:
-
Wolfgang Denk authored
commit 026dfaf1 upstream. Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with Prolifec PL2303 chipset Signed-off-by:
Wolfgang Denk <wd@denx.de> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 5d78fcb0 upstream. Minor whitespace cleanups to make checkpatch happy. Signed-off-by:
-
Manuel Jander authored
commit 9a61d726 upstream. I read a rumor that the AdLink ND6530 USB RS232, RS422 and RS485 isolated adapter is actually a PL2303 based usb serial adapter. I tried it out, and as far as I can tell it works. Signed-off-by:
Manuel Jander <manuel.jander@gmail.com> Signed-off-by:
-
Daniel J Blueman authored
commit b7798d28 upstream. Rebooting on the Dell E5420 often hangs with the keyboard or ACPI methods, but is reliable via the PCI method. [ hpa: this was deferred because we believed for a long time that the recent reshuffling of the boot priorities in commit 660e34ce fixed this platform. Unfortunately that turned out to be incorrect. ] Signed-off-by:
Daniel J Blueman <daniel.blueman@gmail.com> Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.comSigned-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Tejun Heo authored
commit 8c56cacc upstream. To work around controllers which can't properly plug events while reset, ata_eh_reset() clears error states and ATA_PFLAG_EH_PENDING after reset but before RESET is marked done. As reset is the final recovery action and full verification of devices including onlineness and classfication match is done afterwards, this shouldn't lead to lost devices or missed hotplug events. Unfortunately, it forgot to thaw the port when clearing EH_PENDING, so if the condition happens after resetting an empty port, the port could be left frozen and EH will end without thawing it, making the port unresponsive to further hotplug events. Thaw if the port is frozen after clearing EH_PENDING. This problem is reported by Bruce Stenning in the following thread. http://thread.gmane.org/gmane.linux.kernel/1123265 stable: I think we should weather this patch a bit longer in -rcX before sending it to -stable. Please wait at least a month after this patch makes upstream. Thanks. -v2: Fixed spelling in the comment per Dave Howorth. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Bruce Stenning <b.stenning@indigovision.com> Cc: Dave Howorth <dhoworth@mrc-lmb.cam.ac.uk> Signed-off-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Jon Povey authored
commit 9daedd83 upstream. Video input mux settings for tvp7002 and imager inputs were swapped. Comment was correct. Tested on EVM with tvp7002 input. Signed-off-by:
Jon Povey <jon.povey@racelogic.co.uk> Acked-by:
Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
stephen hemminger authored
commit 0c03150e upstream. A bridge topology with three systems: +------+ +------+ | A(2) |--| B(1) | +------+ +------+ \ / +------+ | C(3) | +------+ What is supposed to happen: * bridge with the lowest ID is elected root (for example: B) * C detects that A->C is higher cost path and puts in blocking state What happens. Bridge with lowest id (B) is elected correctly as root and things start out fine initially. But then config BPDU doesn't get transmitted from A -> C. Because of that the link from A-C is transistioned to the forwarding state. The root cause of this is that the configuration messages is generated with bogus message age, and dropped before sending. In the standardmessage_age is supposed to be: the time since the generation of the Configuration BPDU by the Root that instigated the generation of this Configuration BPDU. Reimplement this by recording the timestamp (age + jiffies) when recording config information. The old code incorrectly used the time elapsed on the ageing timer which was incorrect. See also: https://bugzilla.vyatta.com/show_bug.cgi?id=7164Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Pavel Herrmann authored
commit d3f684f2 upstream. spi_sync call uses its spi_message parameter to keep completion information, using a drvdata structure is not thread-safe. Use a mutex to prevent multiple access to shared driver data. Signed-off-by:
Pavel Herrmann <morpheus.ibis@gmail.com> Acked-by:
Russell King <rmk+kernel@arm.linux.org.uk> Acked-by:
Pavel Machek <pavel@ucw.cz> Acked-by:
Marek Vasut <marek.vasut@gmail.com> Acked-by:
Cyril Hrubis <metan@ucw.cz> Tested-by:
Stanislav Brabec <utx@penguin.cz> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit dc6b8450 upstream. While compiling it with Fedora 15, I noticed this issue: inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24: arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by:
Sakari Ailus <sakari.ailus@maxwell.research.nokia.com> Acked-by:
Eduardo Valentin <edubezval@gmail.com> Reviewed-by:
Eugene Teo <eugeneteo@kernel.sg> Signed-off-by:
-
Ben Greear authored
commit ec0dd267 upstream. Because struct rpcbind_args *map was declared static, if two threads entered this method at the same time, the values assigned to map could be sent two two differen tasks. This could cause all sorts of problems, include use-after-free and double-free of memory. Fix this by removing the static declaration so that the map pointer is on the stack. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit b55c5989 upstream. Since rpc_killall_tasks may modify the rpc_task's tk_action field without any locking, we need to be careful when dereferencing it. Reported-by:
-
Andy Adamson authored
commit e5012d1f upstream. Attribute IDs assigned in RFC 5661 now require three bitmaps. Fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs. Signed-off-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
-
Herbert Xu authored
commit 17dd759c upstream. Currently skb_gro_header_slow unconditionally resets frag0 and frag0_len. However, when we can't pull on the skb this leaves the GRO fields in an inconsistent state. This patch fixes this by only resetting those fields after the pskb_may_pull test. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Hans Verkuil authored
commit a024c1a6 upstream. Fix typo: g_tuner should have been s_tuner. Tested with a bttv card. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
commit 50e9efd6 upstream. The tuner-core subdev requires that the type field of v4l2_tuner is filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't use that yet, so we have to do it manually based on whether the current input is radio or not. Tested with my pvrusb2. Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Hans Verkuil authored
commit 227690df upstream. The subdevs are supposed to receive a valid tuner type for the g_frequency and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill this in v4l2-ioctl.c based on whether the device node from which this is called is a radio node or not. The spec does not require applications to fill in the type, and if they leave it at 0 then the 'check_mode' call in tuner-core.c will return an error and the ioctl does nothing. Signed-off-by:
-
Mark Brown authored
commit e999dc50 upstream. The Blackfin DMA controller can report one frame beyond the end of the buffer in the wraparound case but ALSA requires that the pointer always be in the buffer. Do the wraparound to handle this. A similar bug is likely to apply to the other Blackfin PCM drivers but the code is less obvious to inspection and I don't have a user to test. Reported-by:
Kieran O'Leary <Kieran.O'Leary@wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
- 13 Jul, 2011 3 commits
-
-
Greg Kroah-Hartman authored
-
Miklos Szeredi authored
commit 2aa15890 upstream. Michael Leun reported that running parallel opens on a fuse filesystem can trigger a "kernel BUG at mm/truncate.c:475" Gurudas Pai reported the same bug on NFS. The reason is, unmap_mapping_range() is not prepared for more than one concurrent invocation per inode. For example: thread1: going through a big range, stops in the middle of a vma and stores the restart address in vm_truncate_count. thread2: comes in with a small (e.g. single page) unmap request on the same vma, somewhere before restart_address, finds that the vma was already unmapped up to the restart address and happily returns without doing anything. Another scenario would be two big unmap requests, both having to restart the unmapping and each one setting vm_truncate_count to its own value. This could go on forever without any of them being able to finish. Truncate and hole punching already serialize with i_mutex. Other callers of unmap_mapping_range() do not, and it's difficult to get i_mutex protection for all callers. In particular ->d_revalidate(), which calls invalidate_inode_pages2_range() in fuse, may be called with or without i_mutex. This patch adds a new mutex to 'struct address_space' to prevent running multiple concurrent unmap_mapping_range() on the same mapping. [ We'll hopefully get rid of all this with the upcoming mm preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex lockbreak" patch in particular. But that is for 2.6.39 ] Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Reported-by:
Michael Leun <lkml20101129@newton.leun.net> Reported-by:
Gurudas Pai <gurudas.pai@oracle.com> Tested-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
Xufeng Zhang authored
[ Upstream commit 9cfaa8de ] Consider this scenario: When the size of the first received udp packet is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags. However, if checksum error happens and this is a blocking socket, it will goto try_again loop to receive the next packet. But if the size of the next udp packet is smaller than receive buffer, MSG_TRUNC flag should not be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before receive the next packet, MSG_TRUNC is still set, which is wrong. Fix this problem by clearing MSG_TRUNC flag when starting over for a new packet. Signed-off-by:
Xufeng Zhang <xufeng.zhang@windriver.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
