- 15 Mar, 2010 40 commits
-
-
Jean Delvare authored
commit 98ceb75c upstream. Some code that is in ams_exit() (the module exit code) should instead be called when the device (not module) is removed. It probably doesn't make much of a difference in the PMU case, but in the I2C case it does matter. I make no guarantee that my fix isn't racy, I'm not familiar enough with the ams driver code to tell for sure. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
Christian Kujau <lists@nerdbynature.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Stelian Pop <stelian@popies.net> Cc: Michael Hanselmann <linux-kernel@hansmi.ch> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
commit 33a470f6 upstream. Looking at drivers/macintosh/therm_adt746x.c, the sysfs files are created in thermostat_init() and removed in thermostat_exit(), which are the driver's init and exit functions. These files are backed-up by a per-device structure, so it looks like the wrong thing to do: the sysfs files have a lifetime longer than the data structure that is backing it up. I think that sysfs files creation should be moved to the end of probe_thermostat() and sysfs files removal should be moved to the beginning of remove_thermostat(). Signed-off-by:
-
Rafael J. Wysocki authored
commit a9c9b442 upstream. The hibernate memory preallocation code allocates memory to push some user space data out of physical RAM, so that the hibernation image is not too large. It allocates more memory than necessary for creating the image, so it has to release some pages to make room for allocations made while suspending devices and disabling nonboot CPUs, or the system will hang due to the lack of free pages to allocate from. Unfortunately, the function used for freeing these pages, free_unnecessary_pages(), contains a bug that prevents it from doing the job on all systems without highmem. Fix this problem, which is a regression from the 2.6.30 kernel, by using the right condition for the termination of the loop in free_unnecessary_pages(). Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by:
Alan Jenkins <sourcejedi.lkml@googlemail.com> Signed-off-by:
-
Laurent Pinchart authored
commit f4eabafe upstream. Return minimum, maximum and step set to 0 without querying the hardware. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Ang Way Chuang authored
commit 29e1fa35 upstream. ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation has a bug that causes endless loop when Payload Pointer of MPEG2-TS frame is 182 or 183. Anyone who sends malicious MPEG2-TS frame will cause the receiver of ULE SNDU to go into endless loop. This patch was generated and tested against linux-2.6.32.9 and should apply cleanly to linux-2.6.33 as well because there was only one typo fix to dvb_net.c since v2.6.32. This bug was brought to you by modern day Santa Claus who decided to shower the satellite dish at Keio University with heavy snow causing huge burst of errors. We, receiver end, received Santa Claus's gift in the form of kernel bug. Care has been taken not to introduce more bug by fixing this bug, but please scrutinize the code for I always produces buggy code. Signed-off-by:
Ang Way Chuang <wcang79@gmail.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Greg Kroah-Hartman authored
commit e37bcc0d upstream. It turns out that Mimio has a userspace solution for this product using libusb, and the in-kernel driver is just getting in the way now and causing problems. So they have asked that the in-kernel driver be removed. As the staging driver wasn't quite working anyway, and Mimio supports their libusb solution for all distros, I am removing the in-kernel driver. The libusb solution can be downloaded from: http://www.mimio.com/downloads/mimio_studio_software/linux.asp Cc: <mwilder@cs.nmsu.edu> Cc: Phil Hannent <phil@hannent.co.uk> Cc: Marc Rousseau <Marc.Rousseau@mimio.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit c22090fa upstream. The HV core mucks around with specific irqs and other low-level stuff and takes forever to determine that it really shouldn't be running on a machine. So instead, trigger off of the DMI system information and error out much sooner. This also allows the module loading tools to recognize that this code should be loaded on this type of system. Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 9a775dbd upstream. This allows the HV core to be properly found and autoloaded by the system tools. It uses the Microsoft virtual VGA device to trigger this. Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
-
Ben Hutchings authored
commit 2cec8029 upstream. request_firmware() may sleep and it appears to be safe to release the spinlock here. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Paul Mundt authored
commit da64c2a8 upstream. All of the SH clocksource drivers follow the scheme that the IRQ is setup prior to registering the clockevent. The interrupt handler in the clockevent cases looks to the event handler function pointer being filled in by the registration code, permitting us to get in to situations where asserted IRQs step in to the handler before registration has had a chance to complete and hitting a NULL pointer deref. In practice this is not an issue for most platforms, but some of them with fairly special loaders (or that are chain-loading from another kernel) may enter in to this situation. This fixes up the oops reported by Rafael on hp6xx. Reported-and-tested-by:
Rafael Ignacio Zurita <rafaelignacio.zurita@gmail.com> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Jarek Poplawski authored
commit c0d7a021 upstream. There are BUGs "scheduling while atomic" triggered by the timer rhine_tx_timeout(). They are caused by calling napi_disable() (with msleep()). This patch fixes it by moving most of the timer content to the workqueue function (similarly to other drivers, like tg3), with spin_lock() changed to BH version. Additionally, there is spin_lock_irq() moved in rhine_close() to exclude napi_disable() etc., also tg3's way. Reported-by:
Andrey Rahmatullin <wrar@altlinux.org> Tested-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jussi Kivilinna authored
commit 77593ae2 upstream. Stall workaround doesn't work with bcm4320a devices like with bcm4320b. This workaround actually causes more stalls/device freeze on bcm4320a. Therefore disable stall workaround by default. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Jussi Kivilinna authored
commit c1f8ca1d upstream. rndis_query_oid overwrites *len which stores buffer size to return full size of received command and then uses *len with memcpy to fill buffer with command. Ofcourse memcpy should be done before replacing buffer size. Signed-off-by:
-
Jussi Kivilinna authored
commit 634a555c upstream. rndis_wlan didn't know about NL80211_AUTHTYPE_AUTOMATIC and simple setup with 'iwconfig wlan essid no-encrypt' would fail (ENOSUPP). v2: use NDIS_80211_AUTH_AUTO_SWITCH instead of _OPEN. This will make device try shared key auth first, then open. Signed-off-by:
-
Rajiv Andrade authored
commit 3507d612 upstream. Some newer Lenovo models are shipped with a TPM that doesn't seem to set the TPM_STS_DATA_EXPECT status bit when sending it a burst of data, so the code understands it as a failure and doesn't proceed sending the chip the intended data. In this patch we bypass this bit check in case the itpm module parameter was set. This patch is based on Andy Isaacson's one: http://marc.info/?l=linux-kernel&m=124650185023495&w=2 It was heavily discussed how should we deal with identifying the chip in kernel space, but the required patch to do so was NACK'd: http://marc.info/?l=linux-kernel&m=124650186423711&w=2 This way we let the user choose using this workaround or not based on his observations on this code behavior when trying to use the TPM. Fixed a checkpatch issue present on the previous patch, thanks to Daniel Walker. Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Acked-by:
Eric Paris <eparis@redhat.com> Tested-by:
Seiji Munetoh <seiji.munetoh@gmail.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Dave Airlie authored
commit ceae8cbe upstream. This allows offb to be used for initial framebuffer, and a kms driver to take over later in the boot sequence. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Zhenyu Wang authored
commit 8fcc5018 upstream. As we removed TV hotplug, don't check its status ever. Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Daniel Vetter authored
commit 43bcd61f upstream. Somehow the case for G33 got dropped while porting from ums code. This made a 400MHz chip into a 133MHz one which resulted in the unnecessary enabling of double wide pipe mode which in turn screwed up the overlay code. Nothing else (than the overlay code) seems to be affected. This fixes fdo.org bug #24835 Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Aaro Koskinen authored
commit 2a7a06a0 upstream. The idr should be destroyed when the module is unloaded. Found with kmemleak. Signed-off-by:
Aaro Koskinen <aaro.koskinen@nokia.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Anirban Chakraborty authored
commit a67093d4 upstream. Original code incorrectly assumed only status-type-0 IOCBs would be queued to the response-queue, and thus all entries would safely reference a VHA from the IOCB 'handle.' Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Jerome Glisse authored
commit c8c15ff1 upstream This patch workaround a possible security issue which can allow user to abuse drm on r6xx/r7xx hw to access any system ram memory. This patch doesn't break userspace, it detect "valid" old use of CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte the address these registers are pointing to with the one of the last color buffer. This workaround will work for old mesa & xf86-video-ati and any old user which did use similar register programming pattern as those (we expect that there is no others user of those ioctl except possibly a malicious one). This patch add a warning if it detects such usage, warning encourage people to update their mesa & xf86-video-ati. New userspace will submit proper relocation. Fix for xf86-video-ati / mesa (this kernel patch is enough to prevent abuse, fix for userspace are to set proper cs stream and avoid kernel warning) : http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f Abusing this register to perform system ram memory is not easy, here is outline on how it could be achieve. First attacker must have access to the drm device and be able to submit command stream throught cs ioctl. Then attacker must build a proper command stream for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to overwrite the GPU GART which is in VRAM. To achieve so attacker as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point to the GPU GART, then it has to find a way to write predictable value into those buffer (with little cleverness i believe this can be done but this is an hard task). Once attacker have such program it can overwritte GPU GART to program GPU gart to point anywhere in system memory. It then can reusse same method as he used to reprogram GART to overwritte the system ram through the GART mapping. In the process the attacker has to be carefull to not overwritte any sensitive area of the GART table, like ring or IB gart entry as it will more then likely lead to GPU lockup. Bottom line is that i think it's very hard to use this flaw to get system ram access but in theory one can achieve so. Side note: I am not aware of anyone ever using the GPU as an attack vector, nevertheless we take great care in the opensource driver to try to detect and forbid malicious use of GPU. I don't think the closed source driver are as cautious as we are. [bwh: Adjusted context for 2.6.32] Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Jerome Glisse authored
commit db96380e upstream If ib initialization failed don't try to test ib as it will result in an oops (accessing NULL ib buffer ptr). [bwh: Adjusted context for 2.6.32] Signed-off-by:
-
Jerome Glisse authored
commit 7e71c9e2 upstream. This will avoid oops if at later point the fb is use. Trying to create a framebuffer with no valid GEM object is bogus and should be forbidden as this patch does. Signed-off-by:
-
stephen hemminger authored
[ Upstream commit f6815077 ] The book keeping structure for transmit always had the flags value cleared so transmit DMA maps were never released correctly. Based on patch by Jarek Poplawski, problem observed by Michael Breuer. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Choi, David authored
[ Upstream commit aeedba8b ] Hello David Miller, I fix a bug in ks8851_mll driver, which has existed since 2.6.32-rc6. >From : David J. Choi <david.choi@micrel.com> Fix a bug that the data pointers in the interrupt handler are set wrong, which is related with the 5th parameter of request_irq(). Signed-off-by:
David J. Choi <david.choi@micrel.com> Signed-off-by:
-
Shan Wei authored
[ Upstream commit c92b544b ] The commit 0b5ccb2e(title:ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery) has broken the saddr&&daddr member of nf_ct_frag6_queue when creating new queue. And then hash value generated by nf_hashfn() was not equal with that generated by fq_find(). So, a new received fragment can't be inserted to right queue. The patch fixes the bug with adding member of user to nf_ct_frag6_queue structure. Signed-off-by:
Shan Wei <shanwei@cn.fujitsu.com> Acked-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Herbert Xu authored
[ Upstream commit c6b471e6 ] Currently we treat IGMPv3 reports as if it were an IGMPv2/v1 report. This is broken as IGMPv3 reports are formatted differently. So we end up suppressing a bogus multicast group (which should be harmless as long as the leading reserved field is zero). In fact, IGMPv3 does not allow membership report suppression so we should simply ignore IGMPv3 membership reports as a host. This patch does exactly that. I kept the case statement for it so people won't accidentally add it back thinking that we overlooked this case. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Ajit Khaparde authored
[ Upstream commit e76b69cc ] Traffic (tcp) doesnot start on a vlan interface when gro is enabled. Even the tcp handshake was not taking place. This is because, the eth_type_trans call before the netif_receive_skb in napi_gro_finish() resets the skb->dev to napi->dev from the previously set vlan netdev interface. This causes the ip_route_input to drop the incoming packet considering it as a packet coming from a martian source. I could repro this on 2.6.32.7 (stable) and 2.6.33-rc7. With this fix, the traffic starts and the test runs fine on both vlan and non-vlan interfaces. CC: Herbert Xu <herbert@gondor.apana.org.au> CC: Patrick McHardy <kaber@trash.net> Signed-off-by:
Ajit Khaparde <ajitk@serverengines.com> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit b8afe641 ] The wireless sysfs methods like the rest of the networking sysfs methods are removed with the rtnl_lock held and block until the existing methods stop executing. So use rtnl_trylock and restart_syscall so that the code continues to work. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit 88af182e ] Yuck. It turns out that when we restart sysctls we were restarting with the values already changed. Which unfortunately meant that the second time through we thought there was no change and skipped all kinds of work, despite the fact that there was indeed a change. I have fixed this the simplest way possible by restoring the changed values when we restart the sysctl write. One of my coworkers spotted this bug when after disabling forwarding on an interface pings were still forwarded. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 1f474646 ] Thanks to testcase and report from Brad Spengler: -------------------- #include <stdio.h> typedef int (* _wee)(void); int main(void) { char buf[8] = { '\x81', '\xc7', '\xe0', '\x08', '\x81', '\xe8', '\x00', '\x00' }; _wee wee; printf("%p\n", &buf); wee = (_wee)&buf; wee(); return 0; } -------------------- TSB I-tlb load code tries to use andcc to check the _PAGE_EXEC_4U bit, but that's bit 12 so it gets sign extended all the way up to bit 63 and the test nearly always passes as a result. Use sethi to fix the bug. Signed-off-by:
-
Roel Kluin authored
[ Upstream commit 09317146 ] It should be a 1 byte region. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 2531be41 ] Commit 085219f7 ("sparc32: use proper types in struct stat") Accidently changed the struct stat uid/gid members to uid_t and gid_t, but those get set to __kernel_uid32_t and __kernel_gid32_t respectively. Those are of type 'int' but the structure is meant to have 'short'. So use uid16_t and gid16_t to correct this. Reported-by:
Rob Landley <rob@landley.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 8654164f ] It doesn't account for phys_base like it should, fix by using page_to_pfn(). While we're here, make virt_to_page() use pfn_to_page() as well, so we consistently use the asm/memory-model.h abstractions instead of open-coding memory model assumptions. Tested-by:
Kristoffer Glembo <kristoffer@gaisler.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commits f036d9f3 and 440ab7ac ] This is mandatory for 64-bit processes, and doing it also for 32-bit processes saves a conditional in the compat case. This fixes the glibc/nptl/tst-stdio1 test case, as well as many others, on 64-bit. Signed-off-by:
-
Al Viro authored
commit 7fee4868 upstream. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Tejun Heo authored
commit d2e7276b upstream. This is retry of reverted 859ddf09 ("idr: fix a critical misallocation bug") which contained two bugs. * pa[idp->layers] should be cleared even if it's not used by sub_alloc() because it's used by mark idr_mark_full(). * The original condition check also assigned pa[l] to p which the new code didn't do thus leaving p pointing at the wrong layer. Both problems have been fixed and the idr code has received good amount testing using userland testing setup where simple bitmap allocator is run parallel to verify the result of idr allocation. The bug this patch fixes is caused by sub_alloc() optimization path bypassing out-of-room condition check and restarting allocation loop with starting value higher than maximum allowed value. For detailed description, please read commit message of 859ddf09. Signed-off-by:
Tejun Heo <tj@kernel.org> Based-on-patch-from: Eric Paris <eparis@redhat.com> Reported-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Tested-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit f09c2563 upstream. Patch prevents call set_wep_key() with zero key length. That fix long standing regression since commit c0380693 "airo: clean up WEP key operations". Additionally print call trace when someone will try to use improper parameters, and remove key.len = 0 assignment, because it is in not possible code path. Reported-by:
Chris Siebenmann <cks-rhbugzilla@cs.toronto.edu> Bisected-by:
Chris Siebenmann <cks@cs.toronto.edu> Cc: Dan Williams <dcbw@redhat.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Oliver Neukum authored
commit 858155fb upstream. Some devices do not react to a control request (seen on APC UPS's) resulting in a slow stream of messages, "generic-usb ... control queue full". Therefore request needs a timeout. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
David Fries <david@fries.net> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Peter Hutterer authored
commit 9db630b4 upstream. These touchscreens are mounted onto HP TouchSmart and the Dell Studio One 19. Without a quirk they report a wrong button set and the x/y coordinates through ABS_Z/ABS_RX, confusing the higher levels (most notably X.Org's evdev driver). Device id 0x003 covers models 1900, 2150, and 2700 [1] though testing could only be performed on a model 1900. [1] http://www.nextwindow.com/nextwindow_support/latest_tech_info.htmlSigned-off-by:
Peter Hutterer <peter.hutterer@redhat.com> Signed-off-by:
-
