- Nov 21, 2011
-
-
Greg Kroah-Hartman authored
-
Ben Hutchings authored
commit 6b76106d upstream. Even after commit 54787556 ("block: check for proper length of iov entries earlier ...") we still won't check for zero-length entries after an unaligned entry. Remove the break-statement, so all entries are checked. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Rabin Vincent authored
commit 7a401a97 upstream. bdi_prune_sb() in bdi_unregister() attempts to removes the bdi links from all super_blocks and then del_timer_sync() the writeback timer. However, this can race with __mark_inode_dirty(), leading to bdi_wakeup_thread_delayed() rearming the writeback timer on the bdi we're unregistering, after we've called del_timer_sync(). This can end up with the bdi being freed with an active timer inside it, as in the case of the following dump after the removal of an SD card. Fix this by redoing the del_timer_sync() in bdi_destory(). ------------[ cut here ]------------ WARNING: at /home/rabin/kernel/arm/lib/debugobjects.c:262 debug_print_object+0x9c/0xc8() ODEBUG: free active (active state 0) object type: timer_list hint: wakeup_timer_fn+0x0/0x180 Modules linked in: Backtrace: [<c00109dc>] (dump_backtrace+0x0/0x110) from [<c0236e4c>] (dump_stack+0x18/0x1c) r6:c02bc638 r5:00000106 r4:c79f5d18 r3:00000000 ...
-
Anton Blanchard authored
commit d715e433 upstream. kdump fails because we try to execute an HV only instruction. Feature fixups are being applied after we copy the exception vectors down to 0 so they miss out on any updates. We have always had this issue but it only became critical in v3.0 when we added CFAR support (breaks POWER5) and v3.1 when we added POWERNV (breaks everyone). Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Geoff Levand authored
commit 72f3bea0 upstream. Fixes the PS3 bootup hang introduced in 3.0-rc1 by: commit 317f3941 sched: Move the second half of ttwu() to the remote cpu Move the PS3's LV1 EOI call lv1_end_of_interrupt_ext() from ps3_chip_eoi() to ps3_get_irq() for IPI messages. If lv1_send_event_locally() is called between a previous call to lv1_send_event_locally() and the coresponding call to lv1_end_of_interrupt_ext() the second event will not be delivered to the target cpu. The PS3's SMP IPIs are implemented using lv1_send_event_locally(), so if two IPI messages of the same type are sent to the same target in a relatively short period of time the second IPI event can become lost when lv1_end_of_interrupt_ext() is called from ps3_chip_eoi(). Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit 99cb2ddc upstream. gref->gref_id is unsigned so the error handling didn't work. gnttab_grant_foreign_access() returns an int type, so we can add a cast here, and it doesn't cause any problems. gnttab_grant_foreign_access() can return a variety of errors including -ENOSPC, -ENOSYS and -ENOMEM. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit 21643e69 upstream. On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Zhenzhong Duan authored
commit 90d4f553 upstream. PVHVM running with more than 32 vcpus and pv_irq/pv_time enabled need VCPU placement to work, or else it will softlockup. Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Weber authored
commit f09ee045 upstream. The codec for Devkit8000 (TWL4030) was not detected except when build with CONFIG_SND_SOC_ALL_CODECS. twl-core.c still uses the CONFIG_TWL4030_CODEC for twl_has_codec(). In commit 57fe7251 the CONFIG_TWL4030_CODEC was renamed into CONFIG_MFD_TWL4030_AUDIO, thatswhy the codec was not detected. This patch renames the CONFIG_ TWL4030_CODEC into CONFIG_MFD_TWL4030_AUDIO in twl-core.c. Signed-off-by: Thomas Weber <weber@corscience.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
NeilBrown authored
commit 9a3f530f upstream. When the number of failed devices exceeds the allowed number we must abort any active parity operations (checks or updates) as they are no longer meaningful, and can lead to a BUG_ON in handle_parity_checks6. This bug was introduce by commit 6c0069c0 in 2.6.29. Reported-by: Manish Katiyar <mkatiyar@gmail.com> Tested-by: Manish Katiyar <mkatiyar@gmail.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Rafał Miłecki authored
[This patch is supposed to be applied in 3.1 (and maybe older) branches only.] New kernels support newer firmware that users may try to incorrectly use with older kernels. Display error and explain the problem in such a case Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Mika Westerberg authored
commit 153b19a3 upstream. SFI tables reside in RAM and should not be modified once they are written. Current code went to set pentry->irq to zero which causes subsequent reads to fail with invalid SFI table checksum. This will break kexec as the second kernel fails to validate SFI tables. To fix this we use temporary variable for irq number. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Kirill A. Shutemov authored
commit a94cc4e6 upstream. According to the SFI specification irq number 0xFF means device has no interrupt or interrupt attached via GPIO. Currently, we don't handle this special case and set irq field in *_board_info structs to 255. It leads to confusion in some drivers. Accelerometer driver tries to register interrupt 255, fails and prints "Cannot get IRQ" to dmesg. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jesse Barnes authored
commit 1c70c0ce upstream. They use the same register interfaces, so we can simply enable the existing code on IVB. v2: - resolve conflict with ring freq scaling, we can enable it too v3: - resolve conflict again, this time on drm-intel-next Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Robert Hooker <robert.hooker@canonical.com> Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Deucher authored
commit b872a374 upstream. Noticed by Egbert. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Egbert Eich <eich@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Johan Hovold authored
commit cb871513 upstream. Revert commit 6123b0e2. The problem this patch intends to solve has alreadqy been fixed by commit 7a5caabd ("drivers/leds/ledtrig-timer.c: fix broken sysfs delay handling"). Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Antonio Ospite <ospite@studenti.unina.it> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit bc5b8a90 upstream. On a corrupted file system the ->len field could be wrong leading to a buffer overflow. Reported-and-acked-by: Clement LECIGNE <clement.lecigne@netasq.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Howells authored
commit 9f35a33b upstream. Fix a NULL pointer deref in the user-defined key type whereby updating a negative key into a fully instantiated key will cause an oops to occur when the code attempts to free the non-existent old payload. This results in an oops that looks something like the following: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff81085fa1>] __call_rcu+0x11/0x13e PGD 3391d067 PUD 3894a067 PMD 0 Oops: 0002 [#1] SMP CPU 1 Pid: 4354, comm: keyctl Not tainted 3.1.0-fsdevel+ #1140 /DG965RY RIP: 0010:[<ffffffff81085fa1>] [<ffffffff81085fa1>] __call_rcu+0x11/0x13e RSP: 0018:ffff88003d591df8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000006e RDX: ffffffff8161d0c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88003d591e18 R08: 0000000000000000 R09: ffffffff8152fa6c R10: 0000000000000000 R11...
-
Takashi Iwai authored
commit dcaaf9f2 upstream. In the recent usb-audio driver, the initialization of volume ranges may be delayed when the device doesn't respond well at the probing time. But the volume quirks for certain devices are applied only in mixer_ctl_feature_info() thus only at the very first probe and will be missing when the volume range is initialized later. This patch moves the volume quirk code to be always called from the volume-range extraction (get_min_max()), so that the quirks are properly applied in the later init time. Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Takashi Iwai authored
commit 9fcd0ab1 upstream. When the initial check of dB-range failed due to the read error, try to check again at the later read, too. When an invalid dB range is found, remove TLV flags and notify the mixer info change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Deucher authored
commit 091264f0 upstream. Can happen when there is no DP panel attached, confusing users. Make it debug only. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Marcin Slusarz authored
commit 5e60ee78 upstream. Fence lock needs to be initialized before any call to nouveau_channel_put because it calls nouveau_channel_idle->nouveau_fence_update which uses fence lock. BUG: spinlock bad magic on CPU#0, test/24134 lock: ffff88019f90dba8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 Pid: 24134, comm: test Not tainted 3.0.0-nv+ #800 Call Trace: spin_bug+0x9c/0xa3 do_raw_spin_lock+0x29/0x13c _raw_spin_lock+0x1e/0x22 nouveau_fence_update+0x2d/0xf1 nouveau_channel_idle+0x22/0xa0 nouveau_channel_put_unlocked+0x84/0x1bd nouveau_channel_put+0x20/0x24 nouveau_channel_alloc+0x4ec/0x585 nouveau_ioctl_fifo_alloc+0x50/0x130 drm_ioctl+0x289/0x361 do_vfs_ioctl+0x4dd/0x52c sys_ioctl+0x42/0x65 system_call_fastpath+0x16/0x1b It's easily triggerable from userspace. Additionally remove double initialization of chan->fence.pending. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Eric Anholt authored
commit 14660ccd upstream. I've been seeing memory leaks on my system in the form of large (300-400MB) GEM objects created by now-dead processes laying around clogging up memory. I usually notice when it gets to about 1.2GB of them. Hopefully this clears up the issue, but I just found this bug by inspection. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Nobuhiro Iwamatsu authored
commit dfd3b596 upstream. In the case of 29bit mode, CAC/UNCAC_ADDR does not return a right address. This revises this problem by using P1SEGADDR and P2SEGADDR in 29bit mode. Reported-by: Yutaro Ebihara <ebiharaml@si-linux.co.jp> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Simon Horman <horms@verge.net.au> Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Mark Brown authored
commit 8eeea521 upstream. The field is no longer initialised so this will crash if running on wm8958. Reported-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Michael S. Tsirkin authored
commit 72103bd1 upstream. Commit 31a3ddda introduced a use after free in virtio-pci. The main issue is that the release method signals removal of the virtio device, while remove signals removal of the pci device. For example, on driver removal or hot-unplug, virtio_pci_release_dev is called before virtio_pci_remove. We then might get a crash as virtio_pci_remove tries to use the device freed by virtio_pci_release_dev. We allocate/free all resources together with the pci device, so we can leave the release method empty. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Takashi Iwai authored
commit aeb4b88e upstream. When a virtual mater control is created, the driver looks for slave elements from the assigned card instance. But this may include the elements of other codecs when multiple codecs are on the same HD-audio bus. This works at the first time, but it'll give Oops when it's once freed and re-created via reconfig sysfs. This patch changes the element-look-up strategy to limit only to the mixer elements of the same codec. Reported-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
- Nov 11, 2011
-
-
Greg Kroah-Hartman authored
-
Linus Torvalds authored
commit 21404b77 upstream. This removes the use of the special "macbookair_fn_keys" keyboard translation table for the MacBookAir4,x models (ie the 2011 refresh). They use the standard apple_fn_keys[] translation. Apparently only the old MacBook Air's need a different translation table. This mirrors the change that commit da617c7c ("HID: consolidate MacbookAir 4,1 mappings") did for the WELLSPRING6A ones, but does it for the WELLSPRING6 model used on the MacBookAir4,2. Reported-and-tested-by: Dirk Hohndel <hohndel@infradead.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Joshua V Dillon <jvdillon@gmail.com> Cc: Chase Douglas <chase.douglas@canonical.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Kosina authored
commit da617c7c upstream. MacbookAir 4,1 doesn't require extra mapping table, as the mappings are identical to apple_fn_keys[]. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Andreas Krist authored
commit ad734bc1 upstream. I've recently bought a Apple wireless aluminum keyboard (model 2011) which is not yet supported by the kernel - it seems they just changed the device id. After applying the attached patch, the device is fully functional. Signed-off-by: Andreas Krist <andreas.krist@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Gökçen Eraslan authored
commit 213f9da8 upstream. This patch adds keyboard support for Macbook Pro 8 models which has WELLSPRING5A model name and 0x0252, 0x0253 and 0x0254 USB IDs. Trackpad support for those models are added to bcm5974 in c331eb58 ("Input: bcm5974 - Add support for newer MacBookPro8,2). Signed-off-by: Gökçen Eraslan <gokcen@pardus.org.tr> Acked-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: Chase Douglas <chase.douglas@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Nobuhiro Iwamatsu authored
commit d762cc29 upstream. Added USB device IDs and keyboard map for MacBookAir 4,1 keyboard. Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Kosina authored
commit f6f554f0 upstream. Otherwise the generic driver wouldn't unbind from it and wouldn't let hid-apple to automatically take over. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jeff Brown authored
commit c50bb1a4 upstream. This panel is also known as the Dell ST2220Tc. Signed-off-by: <jeffbrown@android.com> Reviewed-By: Benjamin Tissoires <Benjamin_Tissoires@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Joshua V. Dillon authored
commit 5d922baa upstream. Added USB device IDs for MacBookAir4,2 keyboard. Device constants were copied from the MacBookAir3,2 constants. The 4,2 device specification is reportedly unchanged from the 3,2 predecessor and seems to work well. Signed-off-by: Joshua V Dillon <jvdillon@gmail.com> Signed-off-by: Chase Douglas <chase.douglas@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Clemens Werther authored
commit 6d1db077 upstream. Create each gamepad as a separate joystick Signed-off-by: Clemens Werther <clemens.werther@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Bastone authored
commit 4a4c8799 upstream. Add USB device ids for the new revision (MB110LL/B) of Apple's wired aluminum keyboard. I have only confirmed that the ANSI version is correct - it is assumed that the ISO and JIS versions follow the standard numbering convention. Signed-off-by: Dan Bastone <dan@pwienterprises.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
THOMSON, Adam (Adam) authored
commit f722013e upstream. In nand_do_write_ops() code it is possible for a caller to provide ops.oobbuf populated and ops.mode == MTD_OOB_AUTO, which currently means that the chip->oob_poi buffer isn't initialised to all 0xFF. The nand_fill_oob() method then carries out the task of copying the provided OOB data to oob_poi, but with MTD_OOB_AUTO it skips areas marked as unavailable by the layout struct, including the bad block marker bytes. An example of this causing issues is when the last OOB data read was from the start of a bad block where the markers are not 0xFF, and the caller wishes to write new OOB data at the beginning of another block. In this scenario the caller would provide OOB data, but nand_fill_oob() would skip the bad block marker bytes in oob_poi before copying the OOB data provided by the caller. This means that when the OOB data is written back to NAND, the block is inadvertently marked as bad without the caller knowing. This has been witnessed when using YAFFS2 where tags are stored in the OOB. To avoid this oob_poi is always initialised to 0xFF to make sure no left over data is inadvertently written back to the OOB area. Credits to Brian Norris <computersforpeace@gmail.com> for fixing this patch. Signed-off-by: Adam Thomson <adam.thomson@alcatel-lucent.com> Signed-off-by: Artem Bityutskiy <dedekind1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Rajkumar Manoharan authored
commit 52d6d4ef upstream. My recent commits (3782c69d, 324c74ad) introduced regression for register offset selection that based on the macversion. Not using parentheses in proper manner for ternary operator leads to select wrong offset for the registers. This issue was observed with AR9462 chip that immediate disconnect after the association with the following message ieee80211 phy3: wlan0: Failed to send nullfunc to AP 00:23:69:12:ea:47 after 500ms, disconnecting. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-