- 02 Aug, 2010 40 commits
-
-
Tony Luck authored
commit b70f4e85 upstream. Typo in down_spin() meant it only read the low 32 bits of the "serve" value, instead of the full 64 bits. This results in the system hanging when the values in ticket/serve get larger than 32-bits. A big enough system running the right test can hit this in a just a few hours. Broken since 883a3acf [IA64] Re-implement spinaphores using ticket lock concepts Reported via IRC by Bjorn Helgaas Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Jenkins authored
commit bc9d24a3 upstream. Before we mark the wireless device as unplugged, check PCI config space to see whether the wireless device is really disabled (and vice versa). This works around newer models which don't want the hotplug code, where we end up disabling the wired network device. My old 701 still works correctly with this. I can also simulate an afflicted model by changing the hardcoded PCI bus/slot number in the driver, and it seems to work nicely (although it is a bit noisy). In future this type of hotplug support will be implemented by the PCI core. The existing blacklist and the new warning message will be removed at that point. Signed-off-by:
Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by:
Corentin Chary <corentincj@iksaif.net> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Krzysztof Halasa authored
commit 1c938663 upstream. Alan <alan@clueserver.org> writes: > program: /home/alan/GitTrees/linux-2.6-mid-ref/scripts/mod/modpost -o > Module.symvers -S vmlinux.o > > Program received signal SIGSEGV, Segmentation fault. It just hit me. It's the offset calculation in reloc_location() which overflows: return (void *)elf->hdr + sechdrs[section].sh_offset + (r->r_offset - sechdrs[section].sh_addr); E.g. for the first rodata r entry: r->r_offset < sechdrs[section].sh_addr and the expression in the parenthesis produces 0xFFFFFFE0 or something equally wise. Reported-by:
Alan <alan@clueserver.org> Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl> Tested-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Shanyu Zhao authored
commit b561e827 upstream. The flow id (scd_flow) in a compressed BA packet should match the txq_id of the queue from which the aggregated packets were sent. However, in some hardware like the 1000 series, sometimes the flow id is 0 for the txq_id (10 to 19). This can cause the annoying message: [ 2213.306191] iwlagn 0000:01:00.0: Received BA when not expected [ 2213.310178] iwlagn 0000:01:00.0: Read index for DMA queue txq id (0), index 5, is out of range [0-256] 7 7. And even worse, if agg->wait_for_ba is true when the bad BA is arriving, this can cause system hang due to NULL pointer dereference because the code is operating in a wrong tx queue! Signed-off-by:
Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by:
Pradeep Kulkarni <pradeepx.kulkarni@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Laurent Pinchart authored
commit 61421206 upstream. The Miricle 307K (17dc:0202) camera reports a 16-bit greyscale format, support it in the driver. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Laurent Pinchart authored
commit f129b03b upstream. The camera requires the STREAM_NO_FID quirk. Add a corresponding entry in the device IDs list. Signed-off-by:
-
Laurent Pinchart authored
commit 1e4d05bc upstream. The camera requires the PROBE_DEF quirk. Add a corresponding entry in the device IDs list. Signed-off-by:
-
Stanislaw Gruszka authored
commit 76f27364 upstream. If AP do not provide us supported rates before assiociation, send all rates we are supporting instead of empty information element. v1 -> v2: Add comment. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Hiroshi Shimamoto authored
commit 9441cad9 upstream. I encountered an issue that not to link up on cxgb3 fabric. I bisected and found that this regression was introduced by 0f07c4ee. Correct to pass phy_addr to cphy_init() at t3_xaui_direct_phy_prep(). Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Acked-by:
Divy Le Ray <divy@chelsio.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ben Hutchings authored
commit d46b36e7 upstream. Update the Kconfig selections to match the code. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Shane McDonald authored
commit 95e8f634 upstream. In the FPU emulator code of the MIPS, the Cause bits of the FCSR register are not currently writeable by the ctc1 instruction. In odd corner cases, this can cause problems. For example, a case existed where a divide-by-zero exception was generated by the FPU, and the signal handler attempted to restore the FPU registers to their state before the exception occurred. In this particular setup, writing the old value to the FCSR register would cause another divide-by-zero exception to occur immediately. The solution is to change the ctc1 instruction emulator code to allow the Cause bits of the FCSR register to be writeable. This is the behaviour of the hardware that the code is emulating. This problem was found by Shane McDonald, but the credit for the fix goes to Kevin Kissell. In Kevin's words: I submit that the bug is indeed in that ctc_op: case of the emulator. The Cause bits (17:12) are supposed to be writable by that instruction, but the CTC1 emulation won't let them be updated by the instruction. I think that actually if you just completely removed lines 387-388 [...] things would work a good deal better. At least, it would be a more accurate emulation of the architecturally defined FPU. If I wanted to be really, really pedantic (which I sometimes do), I'd also protect the reserved bits that aren't necessarily writable. Signed-off-by:
Shane McDonald <mcdonald.shane@gmail.com> To: anemo@mba.ocn.ne.jp To: kevink@paralogos.com To: sshtylyov@mvista.com Patchwork: http://patchwork.linux-mips.org/patch/1205/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Richard Airlie authored
commit d615da09 upstream. Please find attached a patch which adds the device ID for the Belkin F5D8053 v6 to the rtl8192su driver. I've tested this in 2.6.34-rc3 (Ubuntu 9.10 amd64) and the network adapter is working flawlessly. Signed-off-by:
Richard Airlie <richard@backtrace.co.uk> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ayaz Abdulla authored
commit 5c659322 upstream. This is a fix for bug 572201 @ bugs.debian.org This patch fixes the TX_LIMIT feature flag. The previous logic check for TX_LIMIT2 also took into account a device that only had TX_LIMIT set. Reported-by:
Stephen Mulcahu <stephen.mulcahy@deri.org> Reported-by:
Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by:
-
Jean Delvare authored
commit 806b07c2 upstream. IR support on FusionHDTV cards is broken since kernel 2.6.31. One side effect of the switch to the standard binding model for IR I2C devices was to let i2c-core do the probing instead of the ir-kbd-i2c driver. There is a slight difference between the two probe methods: i2c-core uses 0-byte writes, while the ir-kbd-i2c was using 0-byte reads. As some IR I2C devices only support reads, the new probe method fails to detect them. For now, revert to letting the driver do the probe, using 0-byte reads. In the future, i2c-core will be extended to let callers of i2c_new_probed_device() provide a custom probing function. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
"Timothy D. Lenz" <tlenz@vorgon.com> Signed-off-by:
-
Ang Way Chuang authored
commit 5c331fc8 upstream. Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. Signed-off-by:
Ang Way Chuang <wcang@nav6.org> Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Giuliano Pochini authored
commit b721e68b upstream. This patch fixes a division by zero error in the irq handler. There is a small window between the hw_params() callback and when runtime->frame_bits is set by ALSA middle layer. When another substream is already running, if an interrupt is delivered during that window the irq handler calls pcm_pointer() which does a division by zero. The patch below makes the irq handler skip substreams that are initialized but not started yet. Cc to Clemens Ladisch because he proposed an alternate fix. For more information, please read the original thread in the linux-kernel mailing list: http://lkml.org/lkml/2010/2/2/187Signed-off-by:
Giuliano Pochini <pochini@shiny.it> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Andrej Gelenberg authored
commit accd8466 upstream. 395913d0 ("[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)") is not needed, because there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative anymore. Lock should not be released until the work done. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=1594Signed-off-by:
Andrej Gelenberg <andrej.gelenberg@udo.edu> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
David Woodhouse authored
commit dd336c55 upstream. fix memory leak introduced by the patch 6e03a201: firmware: speed up request_firmware() 1. vfree won't release pages there were allocated explicitly and mapped using vmap. The memory has to be vunmap-ed and the pages needs to be freed explicitly 2. page array is moved into the 'struct firmware' so that we can free it from release_firmware() and not only in fw_dev_release() The fix doesn't break the firmware load speed. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Singed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Baruch Siach authored
commit 380fefb2 upstream. dm9000_set_rx_csum and dm9000_hash_table are called from atomic context (in dm9000_init_dm9000), and from non-atomic context (via ethtool_ops and net_device_ops respectively). This causes a spinlock recursion BUG. Fix this by renaming these functions to *_unlocked for the atomic context, and make the original functions locking wrappers for use in the non-atomic context. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
-
Daniel Mack authored
commit 8a64c0f6 upstream. When operating in 1-bit mode, SDAT1 is used as dedicated interrupt line. However, the 8686 will only drive this line when the ECSI bit is set in the CCCR_IF register. Thanks to Alagu Sankar for pointing me in the right direction. Signed-off-by:
Daniel Mack <daniel@caiaq.de> Cc: Alagu Sankar <alagusankar@embwise.com> Cc: Volker Ernst <volker.ernst@txtr.com> Cc: Dan Williams <dcbw@redhat.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Holger Schurig <hs4233@mail.mn-solutions.de> Cc: Bing Zhao <bzhao@marvell.com> Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@vger.kernel.org Cc: linux-mmc@vger.kernel.org Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Matthew Garrett authored
commit b6dacf63 upstream. The ACPI spec tells us that the firmware will reenable SCI_EN on resume. Reality disagrees in some cases. The ACPI spec tells us that the only way to set SCI_EN is via an SMM call. https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so may break machines. Tracing the ACPI calls made by Windows shows that it unconditionally sets SCI_EN on resume with a direct register write, and therefore the overwhelming probability is that everything is fine with this behaviour. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Tested-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Len Brown authored
commit 718be4aa upstream. It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not. Linux has been unconditionally checking BM_STS. If the chip-set is configured to enable BM_STS, it can retard or completely prevent entry into deep C-states -- as illustrated by turbostat: http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/ ref: Intel Processor Vendor-Specific ACPI Interface Specification table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state https://bugzilla.kernel.org/show_bug.cgi?id=15886Signed-off-by:
-
Ondrej Zary authored
commit 85a0e753 upstream. Save/restore MISC_ENABLE register on suspend/resume. This fixes OOPS (invalid opcode) on resume from STR on Asus P4P800-VM, which wakes up with MWAIT disabled. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15385Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Tested-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Steven Whitehouse authored
commit 2646a1f6 upstream. This code has been shamelessly stolen from XFS at the suggestion of Christoph Hellwig. I've not added support for cached ACLs so far... watch for that in a later patch, although this is designed in such a way that they should be easy to add. Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Michal Hocko authored
commit 7a0ea09a upstream. futex_find_get_task is currently used (through lookup_pi_state) from two contexts, futex_requeue and futex_lock_pi_atomic. None of the paths looks it needs the credentials check, though. Different (e)uids shouldn't matter at all because the only thing that is important for shared futex is the accessibility of the shared memory. The credentail check results in glibc assert failure or process hang (if glibc is compiled without assert support) for shared robust pthread mutex with priority inheritance if a process tries to lock already held lock owned by a process with a different euid: pthread_mutex_lock.c:312: __pthread_mutex_lock_full: Assertion `(-(e)) != 3 || !robust' failed. The problem is that futex_lock_pi_atomic which is called when we try to lock already held lock checks the current holder (tid is stored in the futex value) to get the PI state. It uses lookup_pi_state which in turn gets task struct from futex_find_get_task. ESRCH is returned either when the task is not found or if credentials check fails. futex_lock_pi_atomic simply returns if it gets ESRCH. glibc code, however, doesn't expect that robust lock returns with ESRCH because it should get either success or owner died. Signed-off-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Darren Hart <dvhltc@us.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Nick Piggin <npiggin@suse.de> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Marcelo Tosatti authored
Always invalidate spte and flush TLBs when changing page size, to make sure different sized translations for the same address are never cached in a CPU's TLB. Currently the only case where this occurs is when a non-leaf spte pointer is overwritten by a leaf, large spte entry. This can happen after dirty logging is disabled on a memslot, for example. Noticed by Andrea. KVM-Stable-Tag Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> (cherry picked from commit 3be2264b)
-
Joerg Roedel authored
This patch implements a workaround for AMD erratum 383 into KVM. Without this erratum fix it is possible for a guest to kill the host machine. This patch implements the suggested workaround for hypervisors which will be published by the next revision guide update. [jan: fix overflow warning on i386] [xiao: fix unused variable warning] Cc: stable@kernel.org Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
-
Joerg Roedel authored
This patch moves handling of the MC vmexits to an earlier point in the vmexit. The handle_exit function is too late because the vcpu might alreadry have changed its physical cpu. Cc: stable@kernel.org Signed-off-by:
-
Avi Kivity authored
If cr0.wp=0, we have to allow the guest kernel access to a page with pte.w=0. We do that by setting spte.w=1, since the host cr0.wp must remain set so the host can write protect pages. Once we allow write access, we must remove user access otherwise we mistakenly allow the user to write the page. Reviewed-by:
-
Frank Mayhar authored
commit 14ece102 upstream (as of v2.6.34-git13) Add a new ext4 state to tell us when a file has been newly created; use that state in ext4_sync_file in no-journal mode to tell us when we need to sync the parent directory as well as the inode and data itself. This fixes a problem in which a panic or power failure may lose the entire file even when using fsync, since the parent directory entry is lost. Addresses-Google-Bug: #2480057 Signed-off-by:
Frank Mayhar <fmayhar@google.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Ben Hutchings authored
commit 4d92dc0f upstream (as of v2.6.34-git13) struct ext4_new_group_input needs to be converted because u64 has only 32-bit alignment on some 32-bit architectures, notably i386. Signed-off-by:
-
Ben Hutchings authored
commit 899ad0ce upstream (as of v2.6.34-git13) It is unnecessary, and in general impossible, to define the compat ioctl numbers except when building the filesystem with CONFIG_COMPAT defined. Signed-off-by:
-
Dmitry Monakhov authored
commit 0617b83f upstream (as of v2.6.34-git13) If i_data_sem was internally dropped due to transaction restart, it is necessary to restart path look-up because extents tree was possibly modified by ext4_get_block(). https://bugzilla.kernel.org/show_bug.cgi?id=15827Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Theodore Ts'o authored
commit 786ec791 upstream (as of v2.6.34-git13) Dimitry Monakhov discovered an edge case where it was possible for the EXT4_EOFBLOCKS_FL flag could get cleared unnecessarily. This is true; I have a test case that can be exercised via downloading and decompressing the file: wget ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-testcases/eofblocks-fl-test-case.img.bz2 bunzip2 eofblocks-fl-test-case.img dd if=/dev/zero of=eofblocks-fl-test-case.img bs=1k seek=17925 bs=1k count=1 conv=notrunc However, triggering it in real life is highly unlikely since it requires an extremely fragmented sparse file with a hole in exactly the right place in the extent tree. (It actually took quite a bit of work to generate this test case.) Still, it's nice to get even extreme corner cases to be correct, so this patch makes sure that we don't clear the EXT4_EOFBLOCKS_FL incorrectly even in this corner case. Signed-off-by:
-
Theodore Ts'o authored
commit f70f362b upstream (as of v2.6.34-git13) If the EOFBLOCK_FL flag is set when it should not be and the inode is zero length, then eh_entries is zero, and ex is NULL, so dereferencing ex to print ex->ee_block causes a kernel OOPS in ext4_ext_map_blocks(). On top of that, the error message which is printed isn't very helpful. So we fix this by printing something more explanatory which doesn't involve trying to print ex->ee_block. Addresses-Google-Bug: #2655740 Signed-off-by:
-
Dmitry Monakhov authored
commit 12e9b892 upstream (as of v2.6.34-git13) At several places we modify EXT4_I(inode)->i_flags without holding i_mutex (ext4_do_update_inode, ...). These modifications are racy and we can lose updates to i_flags. So convert handling of i_flags to use bitops which are atomic. https://bugzilla.kernel.org/show_bug.cgi?id=15792Signed-off-by:
-
Jan Kara authored
commit 39a4bade upstream (as of v2.6.34-git13) We failed to show journal_checksum option in /proc/mounts. Fix it. Signed-off-by:
-
Curt Wohlgemuth authored
commit 8a57d9d6 upstream (as of v2.6.34-git13) This adds a new field in ext4_group_info to cache the largest available block range in a block group; and don't load the buddy pages until *after* we've done a sanity check on the block group. With large allocation requests (e.g., fallocate(), 8MiB) and relatively full partitions, it's easy to have no block groups with a block extent large enough to satisfy the input request length. This currently causes the loop during cr == 0 in ext4_mb_regular_allocator() to load the buddy bitmap pages for EVERY block group. That can be a lot of pages. The patch below allows us to call ext4_mb_good_group() BEFORE we load the buddy pages (although we have check again after we lock the block group). Addresses-Google-Bug: #2578108 Addresses-Google-Bug: #2704453 Signed-off-by:
Curt Wohlgemuth <curtw@google.com> Signed-off-by:
-
Nikanth Karthikesan authored
commit 6d19c42b upstream (as of v2.6.34-git13) Currently using posix_fallocate one can bypass an RLIMIT_FSIZE limit and create a file larger than the limit. Add a check for that. Signed-off-by:
Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
Amit Arora <aarora@in.ibm.com> Signed-off-by:
-
Curt Wohlgemuth authored
commit fbe845dd upstream (as of v2.6.34-git13) Addresses-Google-Bug: #2562325 Signed-off-by:
-
