- 15 Mar, 2010 40 commits
-
-
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:
Greg Kroah-Hartman <gregkh@suse.de>
-
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:
Benjamin Herrenschmidt <benh@kernel.crashing.org> 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:
Linus Torvalds <torvalds@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:
James Bottomley <James.Bottomley@suse.de> 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:
-
Jiri Kosina authored
commit 4bb9508b upstream. There were multiple reports which indicate that vendor messed up horribly and the same VID/PID combination is used for completely different devices, some of them requiring the blacklist entry and other not. Remove the blacklist entry for this combination of VID/PID completely, and let the user decide and unbind the driver via sysfs eventually, if needed. Proper fix would be fixing the vendor. References: http://lkml.org/lkml/2009/2/10/434 http://bugzilla.kernel.org/show_bug.cgi?id=13411Signed-off-by:
-
Wu Fengguang authored
commit 0141450f upstream. This fixes inefficient page-by-page reads on POSIX_FADV_RANDOM. POSIX_FADV_RANDOM used to set ra_pages=0, which leads to poor performance: a 16K read will be carried out in 4 _sync_ 1-page reads. In other places, ra_pages==0 means - it's ramfs/tmpfs/hugetlbfs/sysfs/configfs - some IO error happened where multi-page read IO won't help or should be avoided. POSIX_FADV_RANDOM actually want a different semantics: to disable the *heuristic* readahead algorithm, and to use a dumb one which faithfully submit read IO for whatever application requests. So introduce a flag FMODE_RANDOM for POSIX_FADV_RANDOM. Note that the random hint is not likely to help random reads performance noticeably. And it may be too permissive on huge request size (its IO size is not limited by read_ahead_kb). In Quentin's report (http://lkml.org/lkml/2009/12/24/145), the overall (NFS read) performance of the application increased by 313%! Tested-by:
Quentin Barnes <qbarnes+nfs@yahoo-inc.com> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Andi Kleen <andi@firstfloor.org> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Chuck Lever <chuck.lever@oracle.com> Cc: <qbarnes+nfs@yahoo-inc.com> Signed-off-by:
-
Wu Fengguang authored
commit 42e49608 upstream. We'll introduce FMODE_RANDOM which will be runtime modified. So protect all runtime modification to f_mode with f_lock to avoid races. Signed-off-by:
-
Theodore Kilgore authored
commit 70136081 upstream. If you read the mail to Oliver Neukum on the linux-usb list, then you know that I found a cure for the mysterious problem that the MR97310a CIF "type 1" cameras have been freezing up and refusing to stream if hooked up to a machine with a UHCI controller. Namely, the cure is that if the camera is an mr97310a CIF type 1 camera, you have to send it 0xa0, 0x00. Somehow, this is a timing reset command, or such. It un-blocks whatever was previously stopping the CIF type 1 cameras from working on the UHCI-based machines. Signed-off-by:
Theodore Kilgore <kilgota@auburn.edu> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Zhu Yi authored
commit 3dc1de0b upstream. Make addba_resp_timer aware the HT_AGG_STATE_REQ_STOP_BA_MSK mask so that when ___ieee80211_stop_tx_ba_session() is issued the timer will quit. Otherwise when suspend happens before the timer expired, the timer handler will be called immediately after resume and messes up driver status. Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Haicheng Li authored
commit f3186a9c upstream. Comparing with existing code, it's a simpler way to use kzalloc_node() to ensure that each unused alien cache entry is NULL. CC: Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
Andi Kleen <ak@linux.intel.com> Acked-by:
Christoph Lameter <cl@linux-foundation.org> Acked-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
Haicheng Li <haicheng.li@linux.intel.com> Signed-off-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
-
Kashyap, Desai authored
commit d7384b28 upstream. The driver hangs when doing `rmmod mpt2sas` if there are any IR volumes present.The hang is due the scsi midlayer trying to access the IR volumes after the driver releases controller resources. Perhaps when scsi_remove_host is called,the scsi mid layer is sending some request. This doesn't occur for bare drives becuase the driver is already reporting those drives deleted prior to calling mpt2sas_base_detach. To solve this issue, we need to delete the volumes as well. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Reviewed-by:
Eric Moore <eric.moore@lsi.com> Signed-off-by:
-
Pallipadi, Venkatesh authored
commit d306ebc2 upstream. ACPI deep C-state entry had a long standing bug/missing feature, wherein we were sending resched IPIs when an idle CPU is in mwait based deep C-state. Only mwait based C1 was using the write to the monitored address to wake up mwait'ing CPU. This patch changes the code to retain TS_POLLING bit if we are entering an mwait based deep C-state. The patch has been verified to reduce the number of resched IPIs in general and also improves the performance/power on workloads with low system utilization (i.e., when mwait based deep C-states are being used). Fixes "netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f6" http://marc.info/?l=linux-kernel&m=126441481427331&w=4Reported-by:
Lin Ming <ming.m.lin@intel.com> Tested-by:
Alex Shi <alex.shi@intel.com> Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Zhang Rui authored
commit 1379d2fe upstream. Wrong Lid state reported. Need to blacklist this machine for LVDS detection. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Roel Kluin authored
commit f04d5e01 upstream. sysfs_remove_group() removed the wrong attribute_group for thermal_read_mode TPEC_8, ACPI_TMP07 and ACPI_UPDT Signed-off-by:
Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br> Signed-off-by:
-
