aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2010-04-26NFSv4: fix delegated lockingTrond Myklebust
commit 0df5dd4aae211edeeeb84f7f84f6d093406d7c22 upstream. Arnaud Giersch reports that NFSv4 locking is broken when we hold a delegation since commit 8e469ebd6dc32cbaf620e134d79f740bf0ebab79 (NFSv4: Don't allow posix locking against servers that don't support it). According to Arnaud, the lock succeeds the first time he opens the file (since we cannot do a delegated open) but then fails after we start using delegated opens. The following patch fixes it by ensuring that locking behaviour is governed by a per-filesystem capability flag that is initially set, but gets cleared if the server ever returns an OPEN without the NFS4_OPEN_RESULT_LOCKTYPE_POSIX flag being set. Reported-by: Arnaud Giersch <arnaud.giersch@iut-bm.univ-fcomte.fr> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26NFSv4: Fall back to ordinary lookup if nfs4_atomic_open() returns EISDIRTrond Myklebust
commit 80e60639f1b7c121a7fea53920c5a4b94009361a upstream. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26sched: Fix sched_getaffinity()Anton Blanchard
commit 84fba5ec91f11c0efb27d0ed6098f7447491f0df upstream. taskset on 2.6.34-rc3 fails on one of my ppc64 test boxes with the following error: sched_getaffinity(0, 16, 0x10029650030) = -1 EINVAL (Invalid argument) This box has 128 threads and 16 bytes is enough to cover it. Commit cd3d8031eb4311e516329aee03c79a08333141f1 (sched: sched_getaffinity(): Allow less than NR_CPUS length) is comparing this 16 bytes agains nr_cpu_ids. Fix it by comparing nr_cpu_ids to the number of bits in the cpumask we pass in. Signed-off-by: Anton Blanchard <anton@samba.org> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Sharyathi Nagesh <sharyath@in.ibm.com> Cc: Ulrich Drepper <drepper@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jack Steiner <steiner@sgi.com> Cc: Russ Anderson <rja@sgi.com> Cc: Mike Travis <travis@sgi.com> LKML-Reference: <20100406070218.GM5594@kryten> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26sched: sched_getaffinity(): Allow less than NR_CPUS lengthKOSAKI Motohiro
commit cd3d8031eb4311e516329aee03c79a08333141f1 upstream. [ Note, this commit changes the syscall ABI for > 1024 CPUs systems. ] Recently, some distro decided to use NR_CPUS=4096 for mysterious reasons. Unfortunately, glibc sched interface has the following definition: # define __CPU_SETSIZE 1024 # define __NCPUBITS (8 * sizeof (__cpu_mask)) typedef unsigned long int __cpu_mask; typedef struct { __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS]; } cpu_set_t; It mean, if NR_CPUS is bigger than 1024, cpu_set_t makes an ABI issue ... More recently, Sharyathi Nagesh reported following test program makes misterious syscall failure: ----------------------------------------------------------------------- #define _GNU_SOURCE #include<stdio.h> #include<errno.h> #include<sched.h> int main() { cpu_set_t set; if (sched_getaffinity(0, sizeof(cpu_set_t), &set) < 0) printf("\n Call is failing with:%d", errno); } ----------------------------------------------------------------------- Because the kernel assumes len argument of sched_getaffinity() is bigger than NR_CPUS. But now it is not correct. Now we are faced with the following annoying dilemma, due to the limitations of the glibc interface built in years ago: (1) if we change glibc's __CPU_SETSIZE definition, we lost binary compatibility of _all_ application. (2) if we don't change it, we also lost binary compatibility of Sharyathi's use case. Then, I would propse to change the rule of the len argument of sched_getaffinity(). Old: len should be bigger than NR_CPUS New: len should be bigger than maximum possible cpu id This creates the following behavior: (A) In the real 4096 cpus machine, the above test program still return -EINVAL. (B) NR_CPUS=4096 but the machine have less than 1024 cpus (almost all machines in the world), the above can run successfully. Fortunatelly, BIG SGI machine is mainly used for HPC use case. It means they can rebuild their programs. IOW we hope they are not annoyed by this issue ... Reported-by: Sharyathi Nagesh <sharyath@in.ibm.com> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by: Ulrich Drepper <drepper@redhat.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jack Steiner <steiner@sgi.com> Cc: Russ Anderson <rja@sgi.com> Cc: Mike Travis <travis@sgi.com> LKML-Reference: <20100312161316.9520.A69D9226@jp.fujitsu.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boardsSuresh Siddha
commit 472a474c6630efd195d3738339fd1bdc8aa3b1aa upstream. Jan Grossmann reported kernel boot panic while booting SMP kernel on his system with a single core cpu. SMP kernels call enable_IR_x2apic() from native_smp_prepare_cpus() and on platforms where the kernel doesn't find SMP configuration we ended up again calling enable_IR_x2apic() from the APIC_init_uniprocessor() call in the smp_sanity_check(). Thus leading to kernel panic. Don't call enable_IR_x2apic() and default_setup_apic_routing() from APIC_init_uniprocessor() in CONFIG_SMP case. NOTE: this kind of non-idempotent and assymetric initialization sequence is rather fragile and unclean, we'll clean that up in v2.6.35. This is the minimal fix for v2.6.34. Reported-by: Jan.Grossmann@kielnet.net Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: <jbarnes@virtuousgeek.org> Cc: <david.woodhouse@intel.com> Cc: <weidong.han@intel.com> Cc: <youquan.song@intel.com> Cc: <Jan.Grossmann@kielnet.net> LKML-Reference: <1270083887.7835.78.camel@sbs-t61.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26x86, hpet: Erratum workaround for read after write of HPET comparatorPallipadi, Venkatesh
commit 8da854cb02156c90028233ae1e85ce46a1d3f82c upstream. On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote: > Hello, > > Again, on the Intel DP55KG board: > > # uname -a > Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux > > [ 1.237600] ------------[ cut here ]------------ > [ 1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80() > [ 1.238221] Hardware name: > [ 1.238504] hpet: compare register read back failed. > [ 1.238793] Modules linked in: > [ 1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1 > [ 1.239605] Call Trace: > [ 1.239886] <IRQ> [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0 > [ 1.240409] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.240699] [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50 > [ 1.240992] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.241281] [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80 > [ 1.241573] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.241859] [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100 > [ 1.246533] [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30 > [ 1.246826] [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0 > [ 1.247118] [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160 > [ 1.247407] [<ffffffff81029f55>] ? handle_irq+0x15/0x20 > [ 1.247689] [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0 > [ 1.247976] [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa > [ 1.248262] <EOI> [<ffffffff8102f277>] ? mwait_idle+0x57/0x80 > [ 1.248796] [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0 > [ 1.249080] ---[ end trace db7f668fb6fef4e1 ]--- > > Is this something Intel has to fix or is it a bug in the kernel? This is a chipset erratum. Thomas: You mentioned we can retain this check only for known-buggy and hpet debug kind of options. But here is the simple workaround patch for this particular erratum. Some chipsets have a erratum due to which read immediately following a write of HPET comparator returns old comparator value instead of most recently written value. Erratum 15 in "Intel I/O Controller Hub 9 (ICH9) Family Specification Update" (http://www.intel.com/assets/pdf/specupdate/316973.pdf) Workaround for the errata is to read the comparator twice if the first one fails. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26x86: hpet: Make WARN_ON understandableThomas Gleixner
commit 18ed61da985c57eea3fe8038b13fa2837c9b3c3f upstream. Andrew complained rightly that the WARN_ON in hpet_next_event() is confusing and the code comment not really helpful. Change it to WARN_ONCE and print the reason in clear text. Change the comment to explain what kind of hardware wreckage we deal with. Pointed-out-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Venki Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26x86-32, resume: do a global tlb flush in S4 resumeShaohua Li
commit 8ae06d223f8203c72104e5c0c4ee49a000aedb42 upstream. Colin King reported a strange oops in S4 resume code path (see below). The test system has i5/i7 CPU. The kernel doesn't open PAE, so 4M page table is used. The oops always happen a virtual address 0xc03ff000, which is mapped to the last 4k of first 4M memory. Doing a global tlb flush fixes the issue. EIP: 0060:[<c0493a01>] EFLAGS: 00010086 CPU: 0 EIP is at copy_loop+0xe/0x15 EAX: 36aeb000 EBX: 00000000 ECX: 00000400 EDX: f55ad46c ESI: 0f800000 EDI: c03ff000 EBP: f67fbec4 ESP: f67fbea8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 ... ... CR2: 00000000c03ff000 Tested-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> LKML-Reference: <20100305005932.GA22675@sli10-desk.sh.intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26drm/radeon/kms: fix washed out image on legacy tv dacAlex Deucher
commit 643acacf02679befd0f98ac3c5fecb805f1c9548 upstream. bad cast was overwriting the tvdac adj values Fixes fdo bug 27478 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26drm/radeon: R300 AD only has one quad pipe.Michel Dänzer
commit 57b54ea6b7863ccfeb41851b5f58f9fd1b83c79e upstream. Gleaned from the Mesa code. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=27355 . Signed-off-by: Michel Dänzer <daenzer@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26drm/edid/quirks: Envision EN2028Adam Jackson
commit ba1163de2f74d624e7b0e530c4104c98ede0045a upstream. Claims 1280x1024 preferred, physically 1600x1200 cf. http://bugzilla.redhat.com/530399 Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26ARM: 6031/1: fix Thumb-2 decompressorRabin Vincent
commit d4d9959c099751158c5cf14813fe378e206339c6 upstream. 98e12b5a6e05413 ("ARM: Fix decompressor's kernel size estimation for ROM=y") broke the Thumb-2 decompressor because it added an entry in the LC0 table but didn't adjust the offset the Thumb-2 code uses to load the SP from that table. Fix it. Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26iwlwifi: need check for valid qos packet before freeWey-Yi Guy
commit ece6444c2fe80dab679beb5f0d58b091f1933b00 upstream. For 4965, need to check it is valid qos frame before free, only valid QoS frame has the tid used to free the packets. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26CIFS: initialize nbytes at the beginning of CIFSSMBWrite()Steve French
commit a24e2d7d8f512340991ef0a59cb5d08d491b8e98 upstream. By doing this we always overwrite nbytes value that is being passed on to CIFSSMBWrite() and need not rely on the callers to initialize. CIFSSMBWrite2 is doing this already. Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Reviewed-by: Jeff Layton <jlayton@samba.org> Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26cifs: Fix a kernel BUG with remote OS/2 server (try #3)Suresh Jayaraman
commit 6513a81e9325d712f1bfb9a1d7b750134e49ff18 upstream. While chasing a bug report involving a OS/2 server, I noticed the server sets pSMBr->CountHigh to a incorrect value even in case of normal writes. This results in 'nbytes' being computed wrongly and triggers a kernel BUG at mm/filemap.c. void iov_iter_advance(struct iov_iter *i, size_t bytes) { BUG_ON(i->count < bytes); <--- BUG here Why the server is setting 'CountHigh' is not clear but only does so after writing 64k bytes. Though this looks like the server bug, the client side crash may not be acceptable. The workaround is to mask off high 16 bits if the number of bytes written as returned by the server is greater than the bytes requested by the client as suggested by Jeff Layton. Reviewed-by: Jeff Layton <jlayton@samba.org> Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26libata: disable NCQ on Crucial C300 SSDTejun Heo
commit 68b0ddb289220b6d4d865be128939663be34959d upstream. Crucial said, Thank you for contacting us. We know that with our M225 line of SSDs you sometimes need to disable NCQ (native command queuing) to avoid just the type of errors you're seeing. Our recommendation for the M225 is to add libata.force=noncq to your Linux kernel boot options, under the kernel ATA library option. I have sent your feedback to the engineers working on the C300, and asked them to please pass it on to the firmware team. I have been notified that they are in the process of testing and finalizing a new firmware version, that you can expect to see released around the end of April. We’ll keep you posted as to when it will be available for download. So, turn off NCQ on the drive w/ the current firmware revision. Reported in the following bug. https://bugzilla.kernel.org/show_bug.cgi?id=15573 Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: lethalwp@scarlet.be Reported-by: Luke Macken <lmacken@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26eeepc-laptop: disable wireless hotplug for 1005PEAlan Jenkins
commit ced69c59811f05b2f8378467cbb82ac6ed3c6a5a upstream. The wireless hotplug code is not needed on this model, and it disables the wired ethernet card. (Like on the 1005HA and 1201N). References: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-February/003281.html> [bwh: Backported to 2.6.32] Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Reported-by: Ansgar Burchardt <ansgar@43-1.org> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26eeepc-laptop: disable wireless hotplug for 1201NCorentin Chary
commit 4194e2f551a6308e6ab34ac88210bf54858aa7df upstream. [bwh: Backported to 2.6.32] Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26eeepc-laptop: add hotplug_disable parameterCorentin Chary
commit 322a1356be96bcc4b97e8e370f6468c821330077 upstream. Some new models need to disable wireless hotplug. For the moment, we don't know excactly what models need that, except 1005HA. Users will be able to use that param as a workaround. [bwh: Backported to 2.6.32] Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26eeepc-laptop: dmi blacklist to disable pci hotplug codeCorentin Chary
commit 10ae4b5663ff3092553bfbd867e7bd474ce6c553 upstream. This is a short term workaround for Eeepc 1005HA. refs: <http://bugzilla.kernel.org/show_bug.cgi?id=14570> [bwh: Backported to 2.6.32] Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26eeepc-laptop: disable cpu speed control on EeePC 701Alan Jenkins
commit da8ba01deb98f3dc0558b1f5a37e64f40bba7904 upstream. The EeePC 4G ("701") implements CFVS, but it is not supported by the pre-installed OS, and the original option to change it in the BIOS setup screen was removed in later versions. Judging by the lack of "Super Hybrid Engine" on Asus product pages, this applies to all "701" models (4G/4G Surf/2G Surf). So Asus made a deliberate decision not to support it on this model. We have several reports that using it can cause the system to hang [1]. That said, it does not happen all the time. Some users do not experience it at all (and apparently wish to continue "right-clocking"). Check for the EeePC 701 using DMI. If met, then disable writes to the "cpufv" sysfs attribute and log an explanatory message. Add a "cpufv_disabled" attribute which allow users to override this policy. Writing to this attribute will log a second message. The sysfs attribute is more useful than a module option, because it makes it easier for userspace scripts to provide consistent behaviour (according to user configuration), regardless of whether the kernel includes this change. [1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578> [bwh: Backported to 2.6.32] Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: lock down video output state accessHenrique de Moraes Holschuh
commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream. Given the right combination of ThinkPad and X.org, just reading the video output control state is enough to hard-crash X.org. Until the day I somehow find out a model or BIOS cut date to not provide this feature to ThinkPads that can do video switching through X RandR, change permissions so that only processes with CAP_SYS_ADMIN can access any sort of video output control state. This bug could be considered a local DoS I suppose, as it allows any non-privledged local user to cause some versions of X.org to hard-crash some ThinkPads. Reported-by: Jidanni <jidanni@jidanni.org> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: convert to seq_fileAlexey Dobriyan
commit 887965e6576a78f71b9b98dec43fd1c73becd2e8 upstream. (hmh@hmh.eng.br: Updated to apply to 2.6.32.y) Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: log initial state of rfkill switchesHenrique de Moraes Holschuh
commit 5451a923bbdcff6ae665947e120af7238b21a9d2 upstream. We already log the initial state of the hardware rfkill switch (WLSW), might as well log the state of the softswitches as well. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Josip Rodin <joy+kernel@entuzijast.net> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: sync input device EV_SW initial stateHenrique de Moraes Holschuh
commit d89a727aff649f6768f7a34ee57f031ebf8bab4c upstream. Before we register the input device, sync the input layer EV_SW state through a call to input_report_switch(), to avoid issuing a gratuitous event for the initial state of these switches. This fixes some annoyances caused by the interaction with rfkill and EV_SW SW_RFKILL_ALL events. Reported-by: Kevin Locke <kevin@kevinlocke.name> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: use input_set_capabilityHenrique de Moraes Holschuh
commit 792979c8032b8f5adb77ea986db7082fff04c8e7 upstream. Use input_set_capability() instead of set_bit. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: log temperatures on termal alarm (v2)Henrique de Moraes Holschuh
commit 9ebd9e833648745fa5ac6998b9e0153ccd3ba839 upstream. Log temperatures on any of the EC thermal alarms. It could be useful to help tracking down what is happening... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: expose module parametersHenrique de Moraes Holschuh
commit b09c72259e88cec3d602aef987a3209297f3a9c2 upstream. Export the normal (non-command) module paramenters as mode 0444, so that they will show up in sysfs. These parameters must not be changed at runtime as a rule, with very few exceptions. Reported-by: Ferenc Wagner <wferi@niif.hu> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: adopt input deviceHenrique de Moraes Holschuh
commit d112ef95d4ec1ee7fe7123e3f21e4aac0d57570c upstream. Properly init the parent field of the input device. Thanks to Alan Jenkins, who noted this problem in a different driver. Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: silence bogus complain during rmmodHenrique de Moraes Holschuh
commit 6b30eb7d211840ba1a03f855d9e7b80a921368f2 upstream. Fix this bogus warning during module shutdown, when backlight event reporting is enabled: "thinkpad_acpi: required events 0x00018000 not enabled!" Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26thinkpad-acpi: issue backlight class eventsHenrique de Moraes Holschuh
commit 347a26860e2293b1347996876d3550499c7bb31f upstream. Take advantage of the new events capabilities of the backlight class to notify userspace of backlight changes. This depends on "backlight: Allow drivers to update the core, and generate events on changes", by Matthew Garrett. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-26thinkpad-acpi: fix some version quirksHenrique de Moraes Holschuh
commit 90765c6aee568137521ba19347c744b5abde8161 upstream. Update some of the BIOS/EC version quirks. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26ext3: journal all modifications in ext3_xattr_set_handleEric Sandeen
commit d965736b8cb42ae51ba9c3f13488035a98d025c6 upstream. ext3_xattr_set_handle() was zeroing out an inode outside of journaling constraints; this is one of the accesses that was causing the crc errors in journal replay as seen in kernel.org bugzilla #14354. Although ext3 doesn't have the crc issue, modifications out of journal control are a Bad Thing. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26ext3: Don't update the superblock in ext3_statfs()Eric Sandeen
commit b918397542388de75bd86c32fbfa820e5d629fa9 upstream. commit a71ce8c6c9bf269b192f352ea555217815cf027e updated ext3_statfs() to update the on-disk superblock counters, but modified this buffer directly without any journaling of the change. This is one of the accesses that was causing the crc errors in journal replay as seen in kernel.org bugzilla #14354. The modifications were originally to keep the sb "more" in sync, so that a readonly fsck of the device didn't flag this as an error (as often), but apparently e2fsprogs deals with this differently now, anyway. Based on Ted's patch for ext4, which was in turn based on my work on that bug and another preliminary patch... Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26pata_via: Add VIA VX900 supportJosephChan@via.com.tw
commit 4f1deba435ef75380c1d06fda860c7a15ea16fdf upstream. Signed-off-by: Joseph Chan <josephchan@via.com.tw> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: x86: disable paravirt mmu reportingMarcelo Tosatti
commit a68a6a7282373bedba8a2ed751b6384edb983a64 upstream Disable paravirt MMU capability reporting, so that new (or rebooted) guests switch to native operation. Paravirt MMU is a burden to maintain and does not bring significant advantages compared to shadow anymore. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: VMX: Disable unrestricted guest when EPT disabledSheng Yang
commit 046d87103addc117f0d397196e85189722d4d7de upstream Otherwise would cause VMEntry failure when using ept=0 on unrestricted guest supported processors. Signed-off-by: Sheng Yang <sheng@linux.intel.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: SVM: Reset cr0 properly on vcpu resetEduardo Habkost
commit 18fa000ae453767b59ab97477925895a3f0c46ea upstream svm_vcpu_reset() was not properly resetting the contents of the guest-visible cr0 register, causing the following issue: https://bugzilla.redhat.com/show_bug.cgi?id=525699 Without resetting cr0 properly, the vcpu was running the SIPI bootstrap routine with paging enabled, making the vcpu get a pagefault exception while trying to run it. Instead of setting vmcb->save.cr0 directly, the new code just resets kvm->arch.cr0 and calls kvm_set_cr0(). The bits that were set/cleared on vmcb->save.cr0 (PG, WP, !CD, !NW) will be set properly by svm_set_cr0(). kvm_set_cr0() is used instead of calling svm_set_cr0() directly to make sure kvm_mmu_reset_context() is called to reset the mmu to nonpaging mode. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: VMX: Use macros instead of hex value on cr0 initializationEduardo Habkost
commit fa40052ca04bdbbeb20b839cc8ffe9fa7beefbe9 upstream This should have no effect, it is just to make the code clearer. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: VMX: Update instruction length on intercepted BPJan Kiszka
commit c573cd22939e54fc1b8e672054a505048987a7cb upstream We intercept #BP while in guest debugging mode. As VM exits due to intercepted exceptions do not necessarily come with valid idt_vectoring, we have to update event_exit_inst_len explicitly in such cases. At least in the absence of migration, this ensures that re-injections of #BP will find and use the correct instruction length. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: Fix segment descriptor loadingGleb Natapov
commit c697518a861e6c43b92b848895f9926580ee63c3 upstream Add proper error and permission checking. This patch also change task switching code to load segment selectors before segment descriptors, like SDM requires, otherwise permission checking during segment descriptor loading will be incorrect. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: x86 emulator: Fix popf emulationGleb Natapov
commit d4c6a1549c056f1d817e8f6f2f97d8b44933472f upstream POPF behaves differently depending on current CPU mode. Emulate correct logic to prevent guest from changing flags that it can't change otherwise. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: x86 emulator: Check IOPL level during io instruction emulationGleb Natapov
commit f850e2e603bf5a05b0aee7901857cf85715aa694 upstream Make emulator check that vcpu is allowed to execute IN, INS, OUT, OUTS, CLI, STI. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: x86 emulator: fix memory access during x86 emulationGleb Natapov
commit 1871c6020d7308afb99127bba51f04548e7ca84e upstream Currently when x86 emulator needs to access memory, page walk is done with broadest permission possible, so if emulated instruction was executed by userspace process it can still access kernel memory. Fix that by providing correct memory access to page walker during emulation. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26KVM: x86 emulator: Add Virtual-8086 mode of emulationGleb Natapov
commit a0044755679f3e761b8b95995e5f2db2b7efd0f6 upstream For some instructions CPU behaves differently for real-mode and virtual 8086. Let emulator know which mode cpu is in, so it will not poke into vcpu state directly. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26backlight: mbp_nvidia_bl - add five more MacBook variantsEvan McClain
commit 36bc5ee6a8d13333980fa54e97d3469d3d4cda98 upstream. This adds the MacBook 1,1 2,1 3,1 4,1 and 4,2 to the DMI tables. Signed-off-by: Evan McClain <evan.mcclain@gatech.edu> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26resource: move kernel function inside __KERNEL__Jiri Slaby
commit 96d07d211739fd2450ac54e81d00fa40fcd4b1bd upstream From: Jiri Slaby <jslaby@suse.cz> resource: move kernel function inside __KERNEL__ It is an internal function. Move it inside __KERNEL__ ifdef, along with task_struct declaration. Then we get: #--- /usr/include/linux/resource.h 2009-09-14 15:09:29.000000000 +0200 #+++ usr/include/linux/resource.h 2010-01-04 11:30:54.000000000 +0100 #@@ -3,8 +3,6 @@ # ##include <linux/time.h> # #-struct task_struct; #- #/* #* Resource control/accounting header file for linux #*/ #@@ -70,6 +68,5 @@ #*/ ##include <asm/resource.h> # #-int getrusage(struct task_struct *p, int who, struct rusage *ru); # ##endif # #*********** include/linux/Kbuild is untouched, since unifdef is run even on headers-y nowadays. backport to 2.6.32 by maximilian attems <max@stro.at> Patch commented out by gregkh due to quilt complaining. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: maximilian attems <max@stro.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26x86, amd: Get multi-node CPU info from NodeId MSR instead of PCI config spaceAndreas Herrmann
commit 9d260ebc09a0ad6b5c73e17676df42c7bc75ff64 upstream. Use NodeId MSR to get NodeId and number of nodes per processor. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20091216144355.GB28798@alberich.amd.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26ALSA: hda: Fix 0 dB offset for Lenovo Thinkpad models using AD1981Daniel T Chen
commit b8e80cf386419453678b01bef830f53445ebb15d upstream. BugLink: https://launchpad.net/bugs/551606 The OR's hardware distorts at PCM 100% because it does not correspond to 0 dB. Fix this in patch_ad1981() for all models using the Thinkpad quirk. Reported-by: Jane Silber Signed-off-by: Daniel T Chen <crimsun@ubuntu.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-26ALSA: mixart: range checking proc fileDan Carpenter
commit b0cc58a25d04160d39a80e436847eaa2fbc5aa09 upstream. The original code doesn't take into consideration that the value of MIXART_BA0_SIZE - pos can be less than zero which would lead to a large unsigned value for "count". Also I moved the check that read size is a multiple of 4 bytes below the code that adjusts "count". Signed-off-by: Dan Carpenter <error27@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-08-12 16:46:11 +0000