- 12 May, 2010 21 commits
-
-
Alan Stern authored
commit 62f9cfa3 upstream. This patch (as1372) fixes a bug in the routine that chooses the default configuration to install when a new USB device is detected. The algorithm is supposed to look for a config whose first interface is for a non-vendor-specific class. But the way it's currently written, it will also accept a config with no interfaces at all, which is not very useful. (Believe it or not, such things do exist.) Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Andrew Victor <avictor.za@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit fa7fe7af upstream. There is a typo here. We should be testing "*dentry" which was just assigned instead of "dentry". This could result in dereferencing an ERR_PTR inside either usbfs_mkdir() or usbfs_create(). Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
William Lightning authored
commit cfbaa393 upstream. Signed-off-by:
William Lightning <kassah@gmail.com> Signed-off-by:
-
Alan Stern authored
This is a backport of commit 5f677f1d. Some of the functionality had to be removed, but it should still fix the webcam problem. This patch (as1363b) changes the way USB remote wakeup is handled during system sleeps. It won't be enabled unless an interface driver specifically needs it. Also, it won't be enabled during the FREEZE or QUIESCE phases of hibernation, when the system doesn't respond to wakeup events anyway. This will fix problems people have reported with certain USB webcams that generate wakeup requests when they shouldn't, and as a result cause system suspends to fail. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/515109Signed-off-by:
-
Eric Lescouet authored
commit d01f42a2 upstream. When detaching a port from the client side (usbip --detach 0), the event thread, on the server side, is going to deadlock. The "eh" server thread is getting USBIP_EH_RESET event and calls: -> stub_device_reset() -> usb_reset_device() the USB framework is then calling back _in the same "eh" thread_ : -> stub_disconnect() -> usbip_stop_eh() -> wait_for_completion() the "eh" thread is being asleep forever, waiting for its own completion. This patch checks if "eh" is the current thread, in usbip_stop_eh(). Signed-off-by:
Eric Lescouet <eric@lescouet.org> Signed-off-by:
-
David Howells authored
commit 03449cd9 upstream. The request_key() system call and request_key_and_link() should make a link from an existing key to the destination keyring (if supplied), not just from a new key to the destination keyring. This can be tested by: ring=`keyctl newring fred @s` keyctl request2 user debug:a a keyctl request user debug:a $ring keyctl list $ring If it says: keyring is empty then it didn't work. If it shows something like: 1 key in keyring: 1070462727: --alswrv 0 0 user: debug:a then it did. request_key() system call is meant to recursively search all your keyrings for the key you desire, and, optionally, if it doesn't exist, call out to userspace to create one for you. If request_key() finds or creates a key, it should, optionally, create a link to that key from the destination keyring specified. Therefore, if, after a successful call to request_key() with a desination keyring specified, you see the destination keyring empty, the code didn't work correctly. If you see the found key in the keyring, then it did - which is what the patch is required for. Signed-off-by:
David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Neil Brown authored
commit 2bc3c117 upstream. When read_buf is called to move over to the next page in the pagelist of an NFSv4 request, it sets argp->end to essentially a random number, certainly not an address within the page which argp->p now points to. So subsequent calls to READ_BUF will think there is much more than a page of spare space (the cast to u32 ensures an unsigned comparison) so we can expect to fall off the end of the second page. We never encountered thsi in testing because typically the only operations which use more than two pages are write-like operations, which have their own decoding logic. Something like a getattr after a write may cross a page boundary, but it would be very unusual for it to cross another boundary after that. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Jeff Mahoney authored
commit fb2162df upstream. Commit 48b32a35 ("reiserfs: use generic xattr handlers") introduced a problem that causes corruption when extended attributes are replaced with a smaller value. The issue is that the reiserfs_setattr to shrink the xattr file was moved from before the write to after the write. The root issue has always been in the reiserfs xattr code, but was papered over by the fact that in the shrink case, the file would just be expanded again while the xattr was written. The end result is that the last 8 bytes of xattr data are lost. This patch fixes it to use new_size. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=14826Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Reported-by:
Christian Kujau <lists@nerdbynature.de> Tested-by:
-
Jeff Mahoney authored
commit cac36f70 upstream. Commit 677c9b2e ("reiserfs: remove privroot hiding in lookup") removed the magic from the lookup code to hide the .reiserfs_priv directory since it was getting loaded at mount-time instead. The intent was that the entry would be hidden from the user via a poisoned d_compare, but this was faulty. This introduced a security issue where unprivileged users could access and modify extended attributes or ACLs belonging to other users, including root. This patch resolves the issue by properly hiding .reiserfs_priv. This was the intent of the xattr poisoning code, but it appears to have never worked as expected. This is fixed by using d_revalidate instead of d_compare. This patch makes -oexpose_privroot a no-op. I'm fine leaving it this way. The effort involved in working out the corner cases wrt permissions and caching outweigh the benefit of the feature. Signed-off-by:
Edward Shishkin <edward.shishkin@gmail.com> Reported-by:
Matt McCutchen <matt@mattmccutchen.net> Tested-by:
-
Mel Gorman authored
commit 23be7468 upstream. If a futex key happens to be located within a huge page mapped MAP_PRIVATE, get_futex_key() can go into an infinite loop waiting for a page->mapping that will never exist. See https://bugzilla.redhat.com/show_bug.cgi?id=552257 for more details about the problem. This patch makes page->mapping a poisoned value that includes PAGE_MAPPING_ANON mapped MAP_PRIVATE. This is enough for futex to continue but because of PAGE_MAPPING_ANON, the poisoned value is not dereferenced or used by futex. No other part of the VM should be dereferencing the page->mapping of a hugetlbfs page as its page cache is not on the LRU. This patch fixes the problem with the test case described in the bugzilla. [akpm@linux-foundation.org: mel cant spel] Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Acked-by:
Peter Zijlstra <peterz@infradead.org> Acked-by:
Darren Hart <darren@dvhart.com> Signed-off-by:
-
Avi Kivity authored
commit a29815a3 upstream. The list macros use LIST_POISON1 and LIST_POISON2 as undereferencable pointers in order to trap erronous use of freed list_heads. Unfortunately userspace can arrange for those pointers to actually be dereferencable, potentially turning an oops to an expolit. To avoid this allow architectures (currently x86_64 only) to override the default values for these pointers with truly-undereferencable values. This is easy on x86_64 as the virtual address space is large and contains areas that cannot be mapped. Other 64-bit architectures will likely find similar unmapped ranges. [ingo: switch to 0xdead000000000000 as the unmapped area] [ingo: add comments, cleanup] [jaswinder: eliminate sparse warnings] Acked-by:
Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Changli Gao authored
commit e59464c7 upstream. memset() is called with the wrong address and the kernel panics. Signed-off-by:
Changli Gao <xiaosuo@gmail.com> Cc: Patrick McHardy <kaber@trash.net> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
Johannes Berg authored
commit b4bb5c3f upstream. When the addba timer expires but has no work to do, it should not affect the state machine. If it does, TX will not see the successfully established and we can also crash trying to re-establish the session. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Andrea Arcangeli authored
commit 93d5c9be upstream. If a signal is pending (task being killed by sigkill) __mem_cgroup_try_charge will write NULL into &mem, and css_put will oops on null pointer dereference. BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffff810fc6cc>] mem_cgroup_prepare_migration+0x7c/0xc0 PGD a5d89067 PUD a5d8a067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/platform/microcode/firmware/microcode/loading CPU 0 Modules linked in: nfs lockd nfs_acl auth_rpcgss sunrpc acpi_cpufreq pcspkr sg [last unloaded: microcode] Pid: 5299, comm: largepages Tainted: G W 2.6.34-rc3 #3 Penryn1600SLI-110dB/To Be Filled By O.E.M. RIP: 0010:[<ffffffff810fc6cc>] [<ffffffff810fc6cc>] mem_cgroup_prepare_migration+0x7c/0xc0 [nishimura@mxp.nes.nec.co.jp: fix merge issues] Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Balbir Singh <balbir@in.ibm.com> Signed-off-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Signed-off-by:
-
Ian Dall authored
commit 9a6a1ecd upstream. Fix regression caused by commit 507e2fba ("w1: w1 temp calculation overflow fix") whereby negative temperatures for the DS18B20 are not converted properly. When the temperature exceeds 32767 milli-degrees the temperature overflows to -32768 millidegrees. These are both well within the -55 - +125 degree range for the sensor. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=12646Signed-of-by:
Ian Dall <ian@beware.dropbear.id.au> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Tested-by:
Karsten Elfenbein <kelfe@gmx.de> Signed-off-by:
-
Jeff Garzik authored
libata: ensure NCQ error result taskfile is fully initialized before returning it via qc->result_tf. commit a09bf4cd upstream. Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Tejun Heo authored
commit fa41efda upstream. blk_abort_request() expectes queue lock to be held by the caller. Grab it before calling the function. Lack of this synchronization led to infinite loop on corrupt q->timeout_list. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
NeilBrown authored
commit 6e3b96ed upstream. Previous patch changes stripe and chunk_number to sector_t but mistakenly did not update all of the divisions to use sector_dev(). This patch changes all the those divisions (actually the '%' operator) to sector_div. Signed-off-by:
NeilBrown <neilb@suse.de> Tested-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by:
-
NeilBrown authored
commit 35f2a591 upstream. With many large drives and small chunk sizes it is possible to create a RAID5 with more than 2^31 chunks. Make sure this works. Reported-by:
Brett King <king.br@gmail.com> Signed-off-by:
-
Shimada Hirofumi authored
commit 15a69a81 upstream. Signed-off-by:
Shimada Hirofumi <hirofumi@flycat.org> Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Alan Stern authored
commit 0e5f231b upstream. This patch (as1369) fixes a problem in ehci-hcd. Some controllers occasionally run into trouble when the driver reclaims siTDs too quickly. This can happen while streaming audio; it causes the controller to crash. The patch changes siTD reclamation to work the same way as iTD reclamation: Completed siTDs are stored on a list and not reused until at least one frame has passed. Signed-off-by:
Nate Case <ncase@xes-inc.com> Signed-off-by:
-
- 26 Apr, 2010 19 commits
-
-
Greg Kroah-Hartman authored
-
Neil Horman authored
commit 93f4d91d upstream. Fix formatting on r8169 printk Brandon Philips noted that I had a spacing issue in my printk for the last r8169 patch that made it quite ugly. Fix that up and add the PFX macro to it as well so it looks like the other r8169 printks Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Joerg Roedel authored
commit 4b83873d upstream. If we boot into a crash-kernel the gart might still be enabled and its caches might be dirty. This can result in undefined behavior later. Fix it by explicitly disabling the gart hardware before initialization and flushing the caches after enablement. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Jan Kiszka authored
(Cherry-picked from commit e8861cfe) A 16-bit TSS is only 44 bytes long. So make sure to test for the correct size on task switch. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
Sridhar Samudrala authored
(Cherry-picked from commit e80e2a60) This patch increases the current hardcoded limit of NR_IOBUS_DEVS from 6 to 200. We are hitting this limit when creating a guest with more than 1 virtio-net device using vhost-net backend. Each virtio-net device requires 2 such devices to service notifications from rx/tx queues. Signed-off-by:
Sridhar Samudrala <sri@us.ibm.com> Signed-off-by:
-
Takuya Yoshikawa authored
(Cherry-picked from commit 87bf6e7d) Int is not long enough to store the size of a dirty bitmap. This patch fixes this problem with the introduction of a wrapper function to calculate the sizes of dirty bitmaps. Note: in mark_page_dirty(), we have to consider the fact that __set_bit() takes the offset as int, not long. Signed-off-by:
Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Xiao Guangrong authored
(Cherry-picked from commit 77662e00) This patch fix: - calculate zapped page number properly in mmu_zap_unsync_children() - calculate freeed page number properly kvm_mmu_change_mmu_pages() - if zapped children page it shoud restart hlist walking KVM-Stable-Tag. Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
-
Avi Kivity authored
(Cherry-picked from commit 78ac8b47) Currently we set eflags.vm unconditionally when entering real mode emulation through virtual-8086 mode, and clear it unconditionally when we enter protected mode. The means that the following sequence KVM_SET_REGS (rflags.vm=1) KVM_SET_SREGS (cr0.pe=1) Ends up with rflags.vm clear due to KVM_SET_SREGS triggering enter_pmode(). Fix by shadowing rflags.vm (and rflags.iopl) correctly while in real mode: reads and writes to those bits access a shadow register instead of the actual register. Signed-off-by:
-
Andre Przywara authored
(Cherry-picked from commit 114be429) There is a quirk for AMD K8 CPUs in many Linux kernels (see arch/x86/kernel/cpu/mcheck/mce.c:__mcheck_cpu_apply_quirks()) that clears bit 10 in that MCE related MSR. KVM can only cope with all zeros or all ones, so it will inject a #GP into the guest, which will let it panic. So lets add a quirk to the quirk and ignore this single cleared bit. This fixes -cpu kvm64 on all machines and -cpu host on K8 machines with some guest Linux kernels. Signed-off-by:
Andre Przywara <andre.przywara@amd.com> Signed-off-by:
-
Avi Kivity authored
(Cherry-picked from commit d6a23895) These are guest-triggerable. Signed-off-by:
-
Takuya Yoshikawa authored
(Cherry-picked from commit b7af4043) svm_create_vcpu() does not free the pages allocated during the creation when it fails to complete the allocations. This patch fixes it. Signed-off-by:
-
KOSAKI Motohiro authored
commit 8bc037fb upstream. Using the proper type fixes the following compiler warning: kernel/sched.c:4850: warning: comparison of distinct pointer types lacks a cast Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: torvalds@linux-foundation.org Cc: travis@sgi.com Cc: peterz@infradead.org Cc: drepper@redhat.com Cc: rja@sgi.com Cc: sharyath@in.ibm.com Cc: steiner@sgi.com LKML-Reference: <20100317090046.4C79.A69D9226@jp.fujitsu.com> Signed-off-by:
-
Kashyap, Desai authored
commit 9b53b392 upstream. Errata: Certain conditions on the scsi bus may casue the 53C1030 to incorrectly signal a SCSI_DATA_UNDERRUN to the host. Workaround 1: For an Errata on LSI53C1030 When the length of request data and transfer data are different with result of command (READ or VERIFY), DID_SOFT_ERROR is set. Workaround 2: For potential trouble on LSI53C1030. It is checked whether the length of request data is equal to the length of transfer and residual. MEDIUM_ERROR is set by incorrect data. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Kashyap, Desai authored
commit e39e145d upstream. Signed-off-by:
-
Or Gerlitz authored
commit c1ccaf24 upstream. After dma-mapping an SG list provided by the SCSI midlayer, iser has to make sure the mapped SG is "aligned for RDMA" in the sense that its possible to produce one mapping in the HCA IOMMU which represents the whole SG. Next, the mapped SG is formatted for registration with the HCA. This patch re-writes the logic that does the above, to make it clearer and simpler. It also fixes a bug in the being aligned for RDMA checks, where a "start" check wasn't done but rather only "end" check. [commit message in RH kernel tree: "Under heavy load, without the patch, the HCA can be programmed to write (corrupt) into pages/location which doesn't belong to the SG associated with the actual I/O and cause a kernel oops."] Signed-off-by:
Alexander Nezhinsky <alexandern@voltaire.com> Signed-off-by:
Or Gerlitz <ogerlitz@voltaire.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Matt Domsch authored
commit 31bde71c upstream. The tpm_tis driver already has a list of supported pnp_device_ids. This patch simply exports that list as a MODULE_DEVICE_TABLE() so that the module autoloader will discover and load the module at boottime. Signed-off-by:
Matt Domsch <Matt_Domsch@dell.com> Acked-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eric Sandeen authored
commit a1de02dc upstream. The "offset" member in ext4_io_end holds bytes, not blocks, so ext4_lblk_t is wrong - and too small (u32). This caused the async i/o writes to sparse files beyond 4GB to fail when they wrapped around to 0. Also fix up the type of arguments to ext4_convert_unwritten_extents(), it gets ssize_t from ext4_end_aio_dio_nolock() and ext4_ext_direct_IO(). Reported-by:
Giel de Nijs <giel@vectorwise.com> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eric Sandeen authored
commit c8afb446 upstream. Creating many small files in rapid succession on a small filesystem can lead to spurious ENOSPC; on a 104MB filesystem: for i in `seq 1 22500`; do echo -n > $SCRATCH_MNT/$i echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i done leads to ENOSPC even though after a sync, 40% of the fs is free again. This is because we reserve worst-case metadata for delalloc writes, and when data is allocated that worst-case reservation is not usually needed. When freespace is low, kicking off an async writeback will start converting that worst-case space usage into something more realistic, almost always freeing up space to continue. This resolves the testcase for me, and survives all 4 generic ENOSPC tests in xfstests. We'll still need a hard synchronous sync to squeeze out the last bit, but this fixes things up to a large degree. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Eric Sandeen authored
commit 17bd55d0 upstream. ext4, at least, would like to start pushing on writeback if it starts to get close to ENOSPC when reserving worst-case blocks for delalloc writes. Writing out delalloc data will convert those worst-case predictions into usually smaller actual usage, freeing up space before we hit ENOSPC based on this speculation. Thanks to Jens for the suggestion for the helper function, & the naming help. I've made the helper return status on whether writeback was started even though I don't plan to use it in the ext4 patch; it seems like it would be potentially useful to test this in some cases. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
