- 15 Mar, 2010 37 commits
-
-
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 <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
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:
Eric Paris <eparis@redhat.com> Tested-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Tested-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> 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:
John W. Linville <linville@tuxdriver.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:
James Bottomley <James.Bottomley@suse.de> 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:
-
Len Brown authored
commit 49bf83a4 upstream. We broke "acpi=ht" in 2.6.32 by disabling MADT parsing for acpi=disabled. e5b8fc6a This also broke systems which invoked acpi=ht via DMI blacklist. acpi=ht is a really ugly hack, but restore it for those that still use it. http://bugzilla.kernel.org/show_bug.cgi?id=14886Signed-off-by:
-
Len Brown authored
commit 97c169d3 upstream. We realized when we broke acpi=ht http://bugzilla.kernel.org/show_bug.cgi?id=14886 that acpi=ht is not needed on this box and folks have been using acpi=force on it anyway. Signed-off-by:
-
Andrew Morton authored
commit ba02b242 upstream. check ioremap() return value. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Chandru authored
commit b0fc889c upstream. ibmphp driver currently maps only 1KB of ebda memory area into kernel address space during driver initialization. This causes kernel oops when the driver is modprobe'd and it accesses memory beyond 1KB within ebda segment. The first byte of ebda segment actually stores the length of the ebda region in Kilobytes. Hence make use of the length parameter and map the entire ebda region. Signed-off-by:
Chandru Siddalingappa <chandru@linux.vnet.ibm.com> Signed-off-by:
-
Robert Hancock authored
commit 453d3131 upstream. Mike Cui reported that his system with an NVIDIA MCP79 (aka MCP7A) chipset stopped working with 2.6.32. The problem appears to be that 2.6.32 now enables the FPDMA auto-activate optimization in the ahci driver. The drive works fine with this enabled on an Intel AHCI so this appears to be a chipset bug. Since MCP79 is a fairly recent NVIDIA chipset and we don't have any info on whether any other NVIDIA chipsets have this issue, disable FPDMA AA optimization on all NVIDIA AHCI controllers for now. Should address http://bugzilla.kernel.org/show_bug.cgi?id=14922Signed-off-by:
Robert Hancock <hancockrwd@gmail.com> While-we-investigate-issue-this-patch-looks-good-to-me-by:
Prajakta Gudadhe <pgudadhe@nvidia.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Joshua Roys authored
commit c36f74e6 upstream. This fixes corrupted CIPSO packets when SELinux categories greater than 127 are used. The bug occured on the second (and later) loops through the while; the inner for loop through the ebitmap->maps array used the same index as the NetLabel catmap->bitmap array, even though the NetLabel bitmap is twice as long as the SELinux bitmap. Signed-off-by:
Joshua Roys <joshua.roys@gtri.gatech.edu> Acked-by:
Paul Moore <paul.moore@hp.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit a120e912 upstream. Check the frame control for ieee80211_is_data_qos() is true before counting the number of tfds can be free, the tfds_in_queue only increment when ieee80211_is_data_qos() is true before transmit; so it should only decrement if the type match. Remove ieee80211_is_data_qos check for frame_ctrl in tx_resp to avoid invalid information pass from uCode. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Dan Halperin authored
commit 5e2f75b8 upstream. The HT extension channel settings require priv->staging_rxon.channel to be accurate. However, iwl_set_rxon_ht was being called before iwl_set_rxon_channel and thus HT40 could be broken unless another call to iwl_mac_config came in. This problem was recently introduced by "iwlwifi: Fix to set correct ht configuration" The particular setting in which I noticed this was monitor mode: iwconfig wlan0 mode monitor ifconfig wlan0 up ./iw wlan0 set channel 64 HT40- #./iw wlan0 set channel 64 HT40- tcpdump -i wlan0 -y IEEE802_11_RADIO would only catch HT40 packets if I issued the IW command twice. From visual inspection, iwl_set_rxon_channel does not depend on iwl_set_rxon_ht, so simply swapping them should be safe and fixes this problem. Signed-off-by:
Daniel Halperin <dhalperi@cs.washington.edu> Acked-by:
-
Wey-Yi Guy authored
commit a239a8b4 upstream. When receive reply_tx and ready to decrement the count for number of tfds in queue, do error checking to prevent error condition and tfds_in_queue become negative number. Signed-off-by:
-
Michael Neuling authored
commit a17e1879 upstream. 803bf5ec ("fs/exec.c: restrict initial stack space expansion to rlimit") attempts to limit the initial stack to 20*PAGE_SIZE. Unfortunately, in attempting ensure the stack is not reduced in size, we ended up not changing the stack at all. This size reduction check is not necessary as the expand_stack call does this already. This caused a regression in UML resulting in most guest processes being killed. Signed-off-by:
Michael Neuling <mikey@neuling.org> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
WANG Cong <xiyou.wangcong@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: James Morris <jmorris@namei.org> Cc: Serge Hallyn <serue@us.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Jouni Malinen <j@w1.fi> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
commit 5a2d4196 upstream. Presently the oom-killer is memcg aware and it finds the worst process from processes under memcg(s) in oom. Then, it kills victim's child first. It may kill a child in another cgroup and may not be any help for recovery. And it will break the assumption users have. This patch fixes it. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Reviewed-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
Ben Hutchings authored
commit fc4a7f93 upstream. cxusb uses the atbm8830 and lgs8gxx (not lgs8gl5) frontends and the max2165 tuner, so it needs to select them. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Jean Delvare authored
commit 24344664 upstream. Move I2C IR initialization from just after I2C bus setup to right before non-I2C IR initialization. This avoids the case where an I2C IR device is blocking audio support (at least the PV951 suffers from this). It is also more logical to group IR support together, regardless of the connectivity. This fixes bug #15184: http://bugzilla.kernel.org/show_bug.cgi?id=15184Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Martin Fuzzey authored
V4L/DVB: Video : pwc : Fix regression in pwc_set_shutter_speed caused by bad constant => sizeof conversion. commit 53f68607 upstream. Regression was caused by my commit 6b35ca0d which determined message size using sizeof rather than hardcoded constants. Unfortunately pwc_set_shutter_speed reuses a 2 byte buffer for a one byte message too so the sizeof was bogus in this case. All other uses of sizeof checked and are ok. Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Martin Fuzzey <mfuzzey@gmail.com> Signed-off-by:
-
Mike Frysinger authored
commit 3dae93ec upstream. Relying on overflow/wrap around isn't exact because if you wrap far enough, you get back to "valid" values. Reported-by:
Thorsten Pohlmann <pohlmann@tetronik.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Richard Guenther authored
commit c1db53b3 upstream. I'm trying to fix it on the GCC side (PR43007), but the module is quite stupid in using ULL constants to operate on u32 values: static int apply_frontend_param (struct dvb_frontend* fe, struct dvb_frontend_parameters *param) { ... static const u32 ppm = 8000; u32 spi_bias; ... spi_bias *= 1000ULL; spi_bias /= 1000ULL + ppm/1000; which causes current GCC 4.5 to emit calls to __udivdi3 for i?86 again. This patch fixes this issue. Signed-off-by:
Richard Guenther <rguenther@suse.de> Signed-off-by:
-
Guennadi Liakhovetski authored
commit b857df1a upstream. mod_timer() takes an absolute time and not a delay as its argument. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Al Viro authored
commit ac278a9c upstream. Make sure that automount "symlinks" are followed regardless of LOOKUP_FOLLOW; it should have no effect on them. Signed-off-by:
-
- 23 Feb, 2010 3 commits
-
-
Greg Kroah-Hartman authored
-
Jonathan Brassow authored
commit ebfd32bb upstream. This patch fixes two bugs that revolve around the miscalculation and misuse of the variable 'overhead_size'. 'overhead_size' is the size of the various header structures used during communication. The first bug is the use of 'sizeof' with the pointer of a structure instead of the structure itself - resulting in the wrong size being computed. This is then used in a check to see if the payload (data_size) would be to large for the preallocated structure. Since the bug produces a smaller value for the overhead, it was possible for the structure to be breached. (Although the current users of the code do not currently send enough data to trigger this bug.) The second bug is that the 'overhead_size' value is used to compute how much of the preallocated space should be cleared before populating it with fresh data. This should have simply been 'sizeof(struct cn_msg)' not overhead_size. The fact that 'overhead_size' was computed incorrectly made this problem "less bad" - leaving only a pointer's worth of space at the end uncleared. Thus, this bug was never producing a bad result, but still needs to be fixed - especially now that the value is computed correctly. Signed-off-by:
Jonathan Brassow <jbrassow@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Nikanth Karthikesan authored
commit 781248c1 upstream. If a table containing zero as stripe count is passed into stripe_ctr the code attempts to divide by zero. This patch changes DM_TABLE_LOAD to return -EINVAL if the stripe count is zero. We now get the following error messages: device-mapper: table: 253:0: striped: Invalid stripe count device-mapper: ioctl: error adding target to table Signed-off-by:
Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
-
