Home Home > GIT Browse
AgeCommit message (Collapse)Author
2010-08-02Linux Kroah-Hartman
2010-08-02V4L/DVB (13830): uvcvideo: add another YUYV format GUID for iSight camerasDaniel Ritz
commit 68f194e027ecfbbc8d5515bc40787e542eed59e9 upstream. For some unknown reason, on a MacBookPro5,3 the iSight sometimes report a different video format GUID. This patch add the other (wrong) GUID to the format table, making the iSight work always w/o other problems. What it should report: 32595559-0000-0010-8000-00aa00389b71 What it often reports: 32595559-0000-0010-8000-000000389b71 Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02Input: RX51 keymap - fix recent compile breakageDmitry Torokhov
commit 2e65a2075cc740b485ab203430bdf3459d5551b6 upstream. Commit 3fea60261e73 ("Input: twl40300-keypad - fix handling of "all ground" rows") broke compilation as I managed to use non-existent keycodes. Reported-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ath5k: initialize ah->ah_current_channelBob Copeland
commit b6855772f4a22c4fbdd4fcaceff5c8a527035123 upstream. ath5k assumes ah_current_channel is always a valid pointer in several places, but a newly created interface may not have a channel. To avoid null pointer dereferences, set it up to point to the first available channel until later reconfigured. This fixes the following oops: $ rmmod ath5k $ insmod ath5k $ iw phy0 set distance 11000 BUG: unable to handle kernel NULL pointer dereference at 00000006 IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] *pde = 00000000 Oops: 0000 [#1] last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90 scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci 8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc Pid: 1597, comm: iw Not tainted ( #8) EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0 EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080 ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000) Stack: d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0 <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7 <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000 Call Trace: [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k] [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211] [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211] [<c10f5db9>] ? nla_parse+0x59/0xc0 [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0 [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0 [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90 [<c11c9649>] ? genl_rcv+0x19/0x30 [<c11c7c03>] ? netlink_unicast+0x1b3/0x220 [<c11c893e>] ? netlink_sendmsg+0x26e/0x290 [<c11a409e>] ? sock_sendmsg+0xbe/0xf0 [<c1032780>] ? autoremove_wake_function+0x0/0x50 [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530 [<c1074933>] ? do_lookup+0x53/0x1b0 [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0 [<c11acab0>] ? verify_iovec+0x50/0x90 [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270 [<c1048e50>] ? find_get_page+0x10/0x50 [<c104a96f>] ? filemap_fault+0x5f/0x370 [<c1059159>] ? __do_fault+0x319/0x370 [<c11a55b4>] ? sys_socketcall+0x244/0x290 [<c101962c>] ? do_page_fault+0x1ec/0x270 [<c1019440>] ? do_page_fault+0x0/0x270 [<c1002ae5>] ? syscall_call+0x7/0xb Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24 0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7 43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2 EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP 0068:cfa09bf4 CR2: 0000000000000006 ---[ end trace 54f73d6b10ceb87b ]--- Reported-by: Steve Brown <sbrown@cortland.com> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ecryptfs: Bugfix for error related to ecryptfs_hash_bucketsAndre Osterhues
commit a6f80fb7b5986fda663d94079d3bba0937a6b6ff upstream. The function ecryptfs_uid_hash wrongly assumes that the second parameter to hash_long() is the number of hash buckets instead of the number of hash bits. This patch fixes that and renames the variable ecryptfs_hash_buckets to ecryptfs_hash_bits to make it clearer. Fixes: CVE-2010-2492 Signed-off-by: Andre Osterhues <aosterhues@escrypt.com> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02Fix spinaphore down_spin()Tony Luck
commit b70f4e85bfc4d7000036355b714a92d5c574f1be 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 883a3acf5b0d4782ac35981227a0d094e8b44850 [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>
2010-08-02eeepc-laptop: check wireless hotplug eventsAlan Jenkins
commit bc9d24a3aeb1532fc3e234907a8b6d671f7ed68f 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02kbuild: Fix modpost segfaultKrzysztof Halasa
commit 1c938663d58b5b2965976a6f54cc51b5d6f691aa 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: Alan <alan@clueserver.org> Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02iwlagn: verify flow id in compressed BA packetShanyu Zhao
commit b561e8274f75831ee87e4ea378cbb1f9f050a51a 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02V4L/DVB: uvcvideo: Add support for V4L2_PIX_FMT_Y16Laurent Pinchart
commit 61421206833a4085d9bdf35b2b84cd9a67dfdfac 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02V4L/DVB: uvcvideo: Add support for Packard Bell EasyNote MX52 integrated webcamLaurent Pinchart
commit f129b03ba272c86c42ad476684caa0d6109cb383 upstream. The camera requires the STREAM_NO_FID quirk. Add a corresponding entry in the device IDs list. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02V4L/DVB: uvcvideo: Add support for unbranded Arkmicro 18ec:3290 webcamsLaurent Pinchart
commit 1e4d05bc95a0fe2972c5c91ed45466587d07cd2c upstream. The camera requires the PROBE_DEF quirk. Add a corresponding entry in the device IDs list. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02mac80211: fix supported rates IE if AP doesn't give us it's ratesStanislaw Gruszka
commit 76f273640134f3eb8257179cd5b3bc6ba5fe4a96 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02cxgb3: fix linkup issueHiroshi Shimamoto
commit 9441cad99b4b09d6b627351c2d282833868c116c upstream. I encountered an issue that not to link up on cxgb3 fabric. I bisected and found that this regression was introduced by 0f07c4ee8c800923ae7918c231532a9256233eed. 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02V4L/DVB: budget: Select correct frontendsBen Hutchings
commit d46b36e7f927772bb72524dc9f1e384e3cb4a975 upstream. Update the Kconfig selections to match the code. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02MIPS FPU emulator: allow Cause bits of FCSR to be writeable by ctc1Shane McDonald
commit 95e8f634d7a3ea5af40ec3fa42c8a152fd3a0624 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02staging: rtl8192su: add Support for Belkin F5D8053 v6Richard Airlie
commit d615da093eb0f691a73a754589e2a4a24a6f1ca7 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02forcedeth: fix tx limit2 flag checkAyaz Abdulla
commit 5c659322a904a7cc0265e7b183372b9bdebec6db 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: Ben Huchings <ben@decadent.org.uk> Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02V4L/DVB: FusionHDTV: Use quick reads for I2C IR device probingJean Delvare
commit 806b07c29b711aaf90c81d2a19711607769f8246 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: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02V4L/DVB: dvb-core: Fix ULE decapsulation bugAng Way Chuang
commit 5c331fc8c19e181bffab46e9d18e1637cdc47170 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: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ALSA: Echoaudio, fix Guru Meditation #00000005.48454C50Giuliano Pochini
commit b721e68bdc5b39c51bf6a1469f8d3663fbe03243 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/187 Signed-off-by: Giuliano Pochini <pochini@shiny.it> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02revert "[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call ↵Andrej Gelenberg
site)" commit accd846698439ba18250e8fd5681af280446b853 upstream. 395913d0b1db37092ea3d9d69b832183b1dd84c5 ("[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=1594 Signed-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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02firmware_class: fix memory leak - free allocated pagesDavid Woodhouse
commit dd336c554d8926c3348a2d5f2a5ef5597f6d1a06 upstream. fix memory leak introduced by the patch 6e03a201bbe: 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02dm9000: fix "BUG: spinlock recursion"Baruch Siach
commit 380fefb2ddabd4cd5f14dbe090481f0544e65078 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: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02libertas/sdio: 8686: set ECSI bit for 1-bit transfersDaniel Mack
commit 8a64c0f6b7ec7f758c4ef445e49f479e27fa2236 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: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ACPI: Unconditionally set SCI_EN on resumeMatthew Garrett
commit b6dacf63e9fb2e7a1369843d6cef332f76fca6a3 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ACPI: skip checking BM_STS if the BIOS doesn't ask for itLen Brown
commit 718be4aaf3613cf7c2d097f925abc3d3553c0605 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=15886 Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02PM / x86: Save/restore MISC_ENABLE registerOndrej Zary
commit 85a0e7539781dad4bfcffd98e72fa9f130f4e40d 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=15385 Signed-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: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02GFS2: Fix up system xattrsSteven Whitehouse
commit 2646a1f61a3b5525914757f10fa12b5b94713648 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02futex: futex_find_get_task remove credentails checkMichal Hocko
commit 7a0ea09ad5352efce8fe79ed853150449903b9f5 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02KVM: MMU: invalidate and flush on spte small->large page size changeMarcelo Tosatti
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 3be2264be3c00865116f997dc53ebcc90fe7fc4b)
2010-08-02KVM: SVM: Implement workaround for Erratum 383Joerg Roedel
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: Avi Kivity <avi@redhat.com> (cherry picked from commit 67ec66077799f2fef84b21a643912b179c422281)
2010-08-02KVM: SVM: Handle MCEs early in the vmexit processJoerg Roedel
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: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@redhat.com> (cherry picked from commit fe5913e4e1700cbfc337f4b1da9ddb26f6a55586)
2010-08-02KVM: MMU: Remove user access when allowing kernel access to gpte.w=0 pageAvi Kivity
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: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by: Avi Kivity <avi@redhat.com> (cherry picked from commit 69325a122580d3a7b26589e8efdd6663001c3297)
2010-08-02ext4: Make fsync sync new parent directories in no-journal modeFrank Mayhar
commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c 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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Fix compat EXT4_IOC_ADD_GROUPBen Hutchings
commit 4d92dc0f00a775dc2e1267b0e00befb783902fe7 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 <ben@decadent.org.uk> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Conditionally define compat ioctl numbersBen Hutchings
commit 899ad0cea6ad7ff4ba24b16318edbc3cbbe03fad 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: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: restart ext4_ext_remove_space() after transaction restartDmitry Monakhov
commit 0617b83fa239db9743a18ce6cc0e556f4d0fd567 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=15827 Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Acked-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Clear the EXT4_EOFBLOCKS_FL flag only when warrantedTheodore Ts'o
commit 786ec7915e530936b9eb2e3d12274145cab7aa7d 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" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Avoid crashing on NULL ptr dereference on a filesystem errorTheodore Ts'o
commit f70f362b4a6fe47c239dbfb3efc0cc2c10e4f09c 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: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Use bitops to read/modify i_flags in struct ext4_inode_infoDmitry Monakhov
commit 12e9b892002d9af057655d35b44db8ee9243b0dc 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=15792 Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Show journal_checksum optionJan Kara
commit 39a4bade8c1826b658316d66ee81c09b0a4d7d42 upstream (as of v2.6.34-git13) We failed to show journal_checksum option in /proc/mounts. Fix it. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: check for a good block group before loading buddy pagesCurt Wohlgemuth
commit 8a57d9d61a6e361c7bb159dda797672c1df1a691 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: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Prevent creation of files larger than RLIMIT_FSIZE using fallocateNikanth Karthikesan
commit 6d19c42b7cf81c39632b6d4dbc514e8449bcd346 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: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Remove extraneous newlines in ext4_msg() callsCurt Wohlgemuth
commit fbe845ddf368f77f86aa7500f8fd2690f54c66a8 upstream (as of v2.6.34-git13) Addresses-Google-Bug: #2562325 Signed-off-by: Curt Wohlgemuth <curtw@google.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: init statistics after journal recoveryDmitry Monakhov
commit 84061e07c5fbbbf9dc8aef8fb750fc3a2dfc31f3 upstream (as of v2.6.34-git13) Currently block/inode/dir counters initialized before journal was recovered. In fact after journal recovery this info will probably change. And freeblocks it critical for correct delalloc mode accounting. https://bugzilla.kernel.org/show_bug.cgi?id=15768 Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Acked-by: Jan Kara <jack@suse.cz> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: clean up inode bitmaps manipulation in ext4_free_inodeDmitry Monakhov
commit d17413c08cd2b1dd2bf2cfdbb0f7b736b2b2b15c upstrea (as of v2..34-git13) - Reorganize locking scheme to batch two atomic operation in to one. This also allow us to state what healthy group must obey following rule ext4_free_inodes_count(sb, gdp) == ext4_count_free(inode_bitmap, NUM); - Fix possible undefined pointer dereference. - Even if group descriptor stats aren't accessible we have to update inode bitmaps. - Move non-group members update out of group_lock. Note: this commit has been observed to fix fs corruption problems under heavy fs load Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: Do not zero out uninitialized extents beyond i_sizeDmitry Monakhov
commit 21ca087a3891efab4d45488db8febee474d26c68 upstream (as of v2.6.34-git13) The extents code will sometimes zero out blocks and mark them as initialized instead of splitting an extent into several smaller ones. This optimization however, causes problems if the extent is beyond i_size because fsck will complain if there are uninitialized blocks after i_size as this can not be distinguished from an inode that has an incorrect i_size field. https://bugzilla.kernel.org/show_bug.cgi?id=15742 Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: don't scan/accumulate more pages than mballoc will allocateEric Sandeen
commit c445e3e0a5c2804524dec6e55f66d63f6bc5bc3e upstream (as of v2.6.34-git13) There was a bug reported on RHEL5 that a 10G dd on a 12G box had a very, very slow sync after that. At issue was the loop in write_cache_pages scanning all the way to the end of the 10G file, even though the subsequent call to mpage_da_submit_io would only actually write a smallish amt; then we went back to the write_cache_pages loop ... wasting tons of time in calling __mpage_da_writepage for thousands of pages we would just revisit (many times) later. Upstream it's not such a big issue for sys_sync because we get to the loop with a much smaller nr_to_write, which limits the loop. However, talking with Aneesh he realized that fsync upstream still gets here with a very large nr_to_write and we face the same problem. This patch makes mpage_add_bh_to_extent stop the loop after we've accumulated 2048 pages, by setting mpd->io_done = 1; which ultimately causes the write_cache_pages loop to break. Repeating the test with a dirty_ratio of 80 (to leave something for fsync to do), I don't see huge IO performance gains, but the reduction in cpu usage is striking: 80% usage with stock, and 2% with the below patch. Instrumenting the loop in write_cache_pages clearly shows that we are wasting time here. Eventually we need to change mpage_da_map_pages() also submit its I/O to the block layer, subsuming mpage_da_submit_io(), and then change it call ext4_get_blocks() multiple times. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ext4: stop issuing discards if not supported by deviceEric Sandeen
commit a30eec2a8650a77f754e84b2e15f062fe652baa7 upstream (as of v2.6.34-git13) Turn off issuance of discard requests if the device does not support it - similar to the action we take for barriers. This will save a little computation time if a non-discardable device is mounted with -o discard, and also makes it obvious that it's not doing what was asked at mount time ... Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>