summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2007-12-14KVM: SVM: Intercept the 'invd' and 'wbinvd' instructionsAvi Kivity
patch cf5a94d1331b411b84414c13e43f578260942d6b in mainline. 'invd' can destroy host data, and 'wbinvd' allows the guest to induce long (milliseconds) latencies. Noted by Ben Serebrin. Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14KVM: x86 emulator: invd instructionAvi Kivity
patch 651a3e29b3d19418d7a8a9787906061f9be7cc5f in mainline. Emulate the 'invd' instruction (opcode 0f 08). Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14KVM: x86 emulator: fix access registers for instructions with ModR/M byte ↵Aurelien Jarno
and Mod = 3 patch 4e62417bf317504c0b85e0d7abd236f334f54eaf in mainline. The patch belows changes the access type to register from memory for instructions that are declared as SrcMem or DstMem, but have a ModR/M byte with Mod = 3. It fixes (at least) the lmsw and smsw instructions on an AMD64 CPU, which are needed for FreeBSD. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14KVM: x86 emulator: implement 'movnti mem, reg'Sheng Yang
patch a012e65aee48379a7a87eadafa74f878b61522b9 in mainline. Implement emulation of instruction: movnti m32/m64, r32/r64 opcode: 0x0f 0xc3 Needed to support Linux 2.6.16 as guest (used for mmio). Signed-off-by: Sheng Yang <sheng.yang@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)Thomas Gleixner
patch 62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 in mainline Relative hrtimers with a large timeout value might end up as negative timer values, when the current time is added in hrtimer_start(). This in turn is causing the clockevents_set_next() function to set an huge timeout and sleep for quite a long time when we have a clock source which is capable of long sleeps like HPET. With PIT this almost goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code sorts this out in the next timer interrupt, so we never noticed that problem which has been there since the first day of hrtimers. This bug became more apparent in 2.6.24 which activates HPET on more hardware. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14forcedeth boot delay fixAyaz Abdulla
patch 9e555930bd873d238f5f7b9d76d3bf31e6e3ce93 in mainline. Fix a long boot delay in the forcedeth driver. During initialization, the timeout for the handshake between mgmt unit and driver can be very long. The patch reduces the timeout by eliminating a extra loop around the timeout logic. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9308 Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Alex Howells <astinus@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14forcedeth: new mcp79 pci idsAyaz Abdulla
patch 490dde8990c55662596a4be71b5070bd7d382d4a in mainline. This patch adds new device ids and features for mcp79 devices into the forcedeth driver. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> index 92ce2e3..f9ba0ac 100644
2007-12-14I4L: fix isdn_ioctl memory overrun vulnerabilityKarsten Keil
patch eafe1aa37e6ec2d56f14732b5240c4dd09f0613a in mainline. Fix possible memory overrun issue in the isdn ioctl code. Found by ADLAB <adlab@venustech.com.cn> Signed-off-by: Karsten Keil <kkeil@suse.de> Cc: ADLAB <adlab@venustech.com.cn> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14tmpfs: restore missing clear_highpageHugh Dickins
patch e84e2e132c9c66d8498e7710d4ea532d1feaaac5 in mainline tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual case in which shmem_getpage receives the page from its caller instead of allocating. We must cover this case by clear_highpage before SetPageUptodate, as before. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14USB: fix up EHCI startup synchronizationDavid Brownell
patch 1cb52658b4f5b10a9e91f8e1c21ca2bcc1b9a3ca in mainline. A recent patch added software synchronization during EHCI startup, so ports aren't switched away from the companion controllers after resets have started. This patch adds a short delay letting hardware finish that port switching before any new resets begin ... so both ends of that hardware race window are closed. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Dave Miller <davem@davemloft.net> Cc: Dely Sy <dely.l.sy@intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14USB: make the microtek driver and HAL cooperateOliver Neukum
patch 5cf1973a44bd298e3cfce6f6af8faa8c9d0a6d55 in mainline to make HAL like the microtek driver's devices the parent must be correctly set. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14Input: ALPS - add support for model found in Dell Vostro 1400William Pettersson
changeset dac4ae0daa1be36ab015973ed9e9dc04a2684395 in mainline. Input: ALPS - add support for model found in Dell Vostro 1400 Signed-off-by: William Pettersson <william.pettersson@gmail.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14Fix synchronize_irq races with IRQ handlerHerbert Xu
patch a98ce5c6feead6bfedefabd46cb3d7f5be148d9a in mainline. Fix synchronize_irq races with IRQ handler As it is some callers of synchronize_irq rely on memory barriers to provide synchronisation against the IRQ handlers. For example, the tg3 driver does tp->irq_sync = 1; smp_mb(); synchronize_irq(); and then in the IRQ handler: if (!tp->irq_sync) netif_rx_schedule(dev, &tp->napi); Unfortunately memory barriers only work well when they come in pairs. Because we don't actually have memory barriers on the IRQ path, the memory barrier before the synchronize_irq() doesn't actually protect us. In particular, synchronize_irq() may return followed by the result of netif_rx_schedule being made visible. This patch (mostly written by Linus) fixes this by using spin locks instead of memory barries on the synchronize_irq() path. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Chuck Ebbert <cebbert@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14PKT_SCHED: Check subqueue status before calling hard_start_xmitPeter P Waskiewicz Jr
[PKT_SCHED]: Check subqueue status before calling hard_start_xmit [ Upstream commit: 5f1a485d5905aa641f33009019b3699076666a4c ] The only qdiscs that check subqueue state before dequeue'ing are PRIO and RR. The other qdiscs, including the default pfifo_fast qdisc, will allow traffic bound for subqueue 0 through to hard_start_xmit. The check for netif_queue_stopped() is done above in pkt_sched.h, so it is unnecessary for qdisc_restart(). However, if the underlying driver is multiqueue capable, and only sets queue states on subqueues, this will allow packets to enter the driver when it's currently unable to process packets, resulting in expensive requeues and driver entries. This patch re-adds the check for the subqueue status before calling hard_start_xmit, so we can try and avoid the driver entry when the queues are stopped. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14sched: some proc entries are missed in sched_domain sys_ctl debug codeZou Nan hai
patch ace8b3d633f93da8535921bf3e3679db3c619578 in mainline. cache_nice_tries and flags entry do not appear in proc fs sched_domain directory, because ctl_table entry is skipped. This patch fixes the issue. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14Future of Linux 2.6.22.y seriesChristian Borntraeger
commit 5d0360ee96a5ef953dbea45873c2a8c87e77d59b upstream. We have seen ramdisk based install systems, where some pages of mapped libraries and programs were suddendly zeroed under memory pressure. This should not happen, as the ramdisk avoids freeing its pages by keeping them dirty all the time. It turns out that there is a case, where the VM makes a ramdisk page clean, without telling the ramdisk driver. On memory pressure shrink_zone runs and it starts to run shrink_active_list. There is a check for buffer_heads_over_limit, and if true, pagevec_strip is called. pagevec_strip calls try_to_release_page. If the mapping has no releasepage callback, try_to_free_buffers is called. try_to_free_buffers has now a special logic for some file systems to make a dirty page clean, if all buffers are clean. Thats what happened in our test case. The simplest solution is to provide a noop-releasepage callback for the ramdisk driver. This avoids try_to_free_buffers for ramdisk pages. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Jan Kara <jack@suse.cz> Acked-by: Nick Piggin <npiggin@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14NETFILTER: Fix NULL pointer dereference in nf_nat_move_storage()Evgeniy Polyakov
[NETFILTER]: Fix NULL pointer dereference in nf_nat_move_storage() [ Upstream commit: 7799652557d966e49512479f4d3b9079bbc01fff ] Reported by Chuck Ebbert as: https://bugzilla.redhat.com/show_bug.cgi?id=259501#c14 This routine is called each time hash should be replaced, nf_conn has extension list which contains pointers to connection tracking users (like nat, which is right now the only such user), so when replace takes place it should copy own extensions. Loop above checks for own extension, but tries to move higer-layer one, which can lead to above oops. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14NET: random : secure_tcp_sequence_number should not assume CONFIG_KTIME_SCALAREric Dumazet
[NET] random : secure_tcp_sequence_number should not assume CONFIG_KTIME_SCALAR [ Upstream commit: 6dd10a62353a50b30b30e0c18653650975b29c71 ] All 32 bits machines but i386 dont have CONFIG_KTIME_SCALAR. On these machines, ktime.tv64 is more than 4 times the (correct) result given by ktime_to_ns() Again on these machines, using ktime_get_real().tv64 >> 6 give a 32bits rollover every 64 seconds, which is not wanted (less than the 120 s MSL) Using ktime_to_ns() is the portable way to get nsecs from a ktime, and have correct code. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-14libertas: properly account for queue commandsMarcelo Tosatti
patch 29f5f2a19b055feabfcc6f92e1d40ec092c373ea in mainline. Properly account for queue commands, this fixes a problem reported by Holger Schurig when using the debugfs interface. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26Linux 2.6.23.9v2.6.23.9Greg Kroah-Hartman
2007-11-26ipw2200: batch non-user-requested scan result notificationsDan Williams
patch 0b5316769774d1dc2fdd702e095f9e6992af269a in mainline. ipw2200 makes extensive use of background scanning when unassociated or down. Unfortunately, the firmware sends scan completed events many times per second, which the driver pushes directly up to userspace. This needlessly wakes up processes listening for wireless events many times per second. Batch together scan completed events for non-user-requested scans and send them up to userspace every 4 seconds. Scan completed events resulting from an SIOCSIWSCAN call are pushed up without delay. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26USB: Nikon D40X unusual_devs entryOrtwin Glück
patch d466a9190ff1ceddfee50686e61d63590fc820d9 in mainline. Not surprisingly the Nikon D40X DSC needs the same quirks as the D40, but it has a separate ID. See http://bugs.gentoo.org/show_bug.cgi?id=191431 From: Ortwin Glück <odi@odi.ch> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26USB: unusual_devs modification for Nikon D200Phil Dibowitz
patch 16eb345f4d9189b59bae576ae63cba7ca77817b2 in mainline. Upgrade the unusual_devs.h file to support the Nikon D200 Signed-off-by: Mike Pagano <mpagano-kernel@mpagano.com> Signed-off-by: Phil Dibowitz <phil@ipom.com> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26softlockup: use cpu_clock() instead of sched_clock()Ingo Molnar
patch a3b13c23f186ecb57204580cc1f2dbe9c284953a in mainline. sched_clock() is not a reliable time-source, use cpu_clock() instead. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26softlockup watchdog fixes and cleanupsIngo Molnar
This is a merge of commits a5f2ce3c6024a5bb895647b6bd88ecae5001020a and 43581a10075492445f65234384210492ff333eba in mainline to fix a warning in the 2.6.23.3 kernel release. softlockup watchdog: style cleanups kernel/softirq.c grew a few style uncleanlinesses in the past few months, clean that up. No functional changes: text data bss dec hex filename 1126 76 4 1206 4b6 softlockup.o.before 1129 76 4 1209 4b9 softlockup.o.after ( the 3 bytes .text increase is due to the "<1>" appended to one of the printk messages. ) Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> softlockup: improve debug output Improve the debuggability of kernel lockups by enhancing the debug output of the softlockup detector: print the task that causes the lockup and try to print a more intelligent backtrace. The old format was: BUG: soft lockup detected on CPU#1! [<c0105e4a>] show_trace_log_lvl+0x19/0x2e [<c0105f43>] show_trace+0x12/0x14 [<c0105f59>] dump_stack+0x14/0x16 [<c015f6bc>] softlockup_tick+0xbe/0xd0 [<c013457d>] run_local_timers+0x12/0x14 [<c01346b8>] update_process_times+0x3e/0x63 [<c0145fb8>] tick_sched_timer+0x7c/0xc0 [<c0140a75>] hrtimer_interrupt+0x135/0x1ba [<c011bde7>] smp_apic_timer_interrupt+0x6e/0x80 [<c0105aa3>] apic_timer_interrupt+0x33/0x38 [<c0104f8a>] syscall_call+0x7/0xb ======================= The new format is: BUG: soft lockup detected on CPU#1! [prctl:2363] Pid: 2363, comm: prctl EIP: 0060:[<c013915f>] CPU: 1 EIP is at sys_prctl+0x24/0x18c EFLAGS: 00000213 Not tainted (2.6.22-cfs-v20 #26) EAX: 00000001 EBX: 000003e7 ECX: 00000001 EDX: f6df0000 ESI: 000003e7 EDI: 000003e7 EBP: f6df0fb0 DS: 007b ES: 007b FS: 00d8 CR0: 8005003b CR2: 4d8c3340 CR3: 3731d000 CR4: 000006d0 [<c0105e4a>] show_trace_log_lvl+0x19/0x2e [<c0105f43>] show_trace+0x12/0x14 [<c01040be>] show_regs+0x1ab/0x1b3 [<c015f807>] softlockup_tick+0xef/0x108 [<c013457d>] run_local_timers+0x12/0x14 [<c01346b8>] update_process_times+0x3e/0x63 [<c0145fcc>] tick_sched_timer+0x7c/0xc0 [<c0140a89>] hrtimer_interrupt+0x135/0x1ba [<c011bde7>] smp_apic_timer_interrupt+0x6e/0x80 [<c0105aa3>] apic_timer_interrupt+0x33/0x38 [<c0104f8a>] syscall_call+0x7/0xb ======================= Note that in the old format we only knew that some system call locked up, we didnt know _which_. With the new format we know that it's at a specific place in sys_prctl(). [which was where i created an artificial kernel lockup to test the new format.] This is also useful if the lockup happens in user-space - the user-space EIP (and other registers) will be printed too. (such a lockup would either suggest that the task was running at SCHED_FIFO:99 and looping for more than 10 seconds, or that the softlockup detector has a false-positive.) The task name is printed too first, just in case we dont manage to print a useful backtrace. [satyam@infradead.org: fix warning] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Satyam Sharma <satyam@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26x86: fix freeze in x86_64 RTC update code in time_64.cDavid P. Reed
patch c399da0d97e06803e51085ec076b63a3168aad1b in mainline. x86: fix freeze in x86_64 RTC update code in time_64.c Fix hard freeze on x86_64 when the ntpd service calls update_persistent_clock() A repeatable but randomly timed freeze has been happening in Fedora 6 and 7 for the last year, whenever I run the ntpd service on my AMD64x2 HP Pavilion dv9000z laptop. This freeze is due to the use of spin_lock(&rtc_lock) under the assumption (per a bad comment) that set_rtc_mmss is called only with interrupts disabled. The call from ntp.c to update_persistent_clock is made with interrupts enabled. [ tglx@linutronix.de: ported to 2.6.23.stable ] Signed-off-by: David P. Reed <dpreed@reed.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26ntp: fix typo that makes sync_cmos_clock erraticDavid P. Reed
patch fa6a1a554b50cbb7763f6907e6fef927ead480d9 in mainline. ntp: fix typo that makes sync_cmos_clock erratic Fix a typo in ntp.c that has caused updating of the persistent (RTC) clock when synced to NTP to behave erratically. When debugging a freeze that arises on my AMD64 machines when I run the ntpd service, I added a number of printk's to monitor the sync_cmos_clock procedure. I discovered that it was not syncing to cmos RTC every 11 minutes as documented, but instead would keep trying every second for hours at a time. The reason turned out to be a typo in sync_cmos_clock, where it attempts to ensure that update_persistent_clock is called very close to 500 msec. after a 1 second boundary (required by the PC RTC's spec). That typo referred to "xtime" in one spot, rather than "now", which is derived from "xtime" but not equal to it. This makes the test erratic, creating a "coin-flip" that decides when update_persistent_clock is called - when it is called, which is rarely, it may be at any time during the one second period, rather than close to 500 msec, so the value written is needlessly incorrect, too. Signed-off-by: David P. Reed <dpreed@reed.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26x86: return correct error code from child_rip in x86_64 entry.SAndrey Mirkin
patch 1c5b5cfd290b6cb7c67020ef420e275f746a7236 in mainline. x86: return correct error code from child_rip in x86_64 entry.S Right now register edi is just cleared before calling do_exit. That is wrong because correct return value will be ignored. Value from rax should be copied to rdi instead of clearing edi. AK: changed to 32bit move because it's strictly an int [ tglx: arch/x86 adaptation ] Signed-off-by: Andrey Mirkin <major@openvz.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26x86: NX bit handling in change_page_attr()Huang, Ying
patch 84e0fdb1754d066dd0a8b257de7299f392d1e727 in mainline. x86: NX bit handling in change_page_attr() This patch fixes a bug of change_page_attr/change_page_attr_addr on Intel x86_64 CPUs. After changing page attribute to be executable with these functions, the page remains un-executable on Intel x86_64 CPU. Because on Intel x86_64 CPU, only if the "NX" bits of all four level page tables are cleared, the corresponding page is executable (refer to section 4.13.2 of Intel 64 and IA-32 Architectures Software Developer's Manual). So, the bug is fixed through clearing the "NX" bit of PMD when splitting the huge PMD. Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26x86: mark read_crX() asm code as volatileKirill Korotaev
patch c1217a75ea102d4e69321f210fab60bc47b9a48e in mainline. x86: mark read_crX() asm code as volatile Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from gentoo) can generate incorrect code with read_crX()/write_crX() functions mix up, due to cached results of read_crX(). The small app for x8664 below compiled with -O2 demonstrates this (i686 does the same thing): Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26x86: fix off-by-one in find_next_zero_stringAndrew Hastings
patch 801916c1b369b637ce799e6c71a94963ff63df79 in mainline. x86: fix off-by-one in find_next_zero_string Fix an off-by-one error in find_next_zero_string which prevents allocating the last bit. [ tglx: arch/x86 adaptation ] Signed-off-by: Andrew Hastings <abh@cray.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26i386: avoid temporarily inconsistent pte-sJan Beulich
patch aa506dc7b12d03fbf8fd11aab752aed1aadd9c07 in mainline. i386: avoid temporarily inconsistent pte-s One more of these issues (which were considered fixed a few releases back): other than on x86-64, i386 allows set_fixmap() to replace already present mappings. Consequently, on PAE, care must be taken to not update the high half of a pte while the low half is still holding the old value. [tglx: arch/x86 adaptation] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26libcrc32c: keep intermediate crc state in cpu orderHerbert Xu
It's upstream changeset ef19454bd437b2ba14c9cda1de85debd9f383484. [LIB] crc32c: Keep intermediate crc state in cpu order crypto/crc32.c:chksum_final() is computing the digest as *(__le32 *)out = ~cpu_to_le32(mctx->crc); so the low-level crc32c_le routines should just keep the crc in cpu order, otherwise it is getting swabbed one too many times on big-endian machines. Signed-off-by: Benny Halevy <bhalevy@fs1.bhalevy.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26geode: Fix not inplace encryptionSebastian Siewior
patch 2e21630ddc3fb717dc645356b75771c6a52dc627 in mainline. Currently the Geode AES module fails to encrypt or decrypt if the coherent bits are not set what is currently the case if the encryption does not occur inplace. However, the encryption works on my Geode machine _only_ if the coherent bits are always set. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Acked-by: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26Fix divide-by-zero in the 2.6.23 scheduler codeChuck Ebbert
No patch in mainline as this logic has been removed from 2.6.24 so it is not necessary. https://bugzilla.redhat.com/show_bug.cgi?id=340161 The problem code has been removed in 2.6.24. The below patch disables SCHED_FEAT_PRECISE_CPU_LOAD which causes the offending code to be skipped but does not prevent the user from enabling it. The divide-by-zero is here in kernel/sched.c: static void update_cpu_load(struct rq *this_rq) { u64 fair_delta64, exec_delta64, idle_delta64, sample_interval64, tmp64; unsigned long total_load = this_rq->ls.load.weight; unsigned long this_load = total_load; struct load_stat *ls = &this_rq->ls; int i, scale; this_rq->nr_load_updates++; if (unlikely(!(sysctl_sched_features & SCHED_FEAT_PRECISE_CPU_LOAD))) goto do_avg; /* Update delta_fair/delta_exec fields first */ update_curr_load(this_rq); fair_delta64 = ls->delta_fair + 1; ls->delta_fair = 0; exec_delta64 = ls->delta_exec + 1; ls->delta_exec = 0; sample_interval64 = this_rq->clock - ls->load_update_last; ls->load_update_last = this_rq->clock; if ((s64)sample_interval64 < (s64)TICK_NSEC) sample_interval64 = TICK_NSEC; if (exec_delta64 > sample_interval64) exec_delta64 = sample_interval64; idle_delta64 = sample_interval64 - exec_delta64; ======> tmp64 = div64_64(SCHED_LOAD_SCALE * exec_delta64, fair_delta64); tmp64 = div64_64(tmp64 * exec_delta64, sample_interval64); this_load = (unsigned long)tmp64; do_avg: /* Update our load: */ for (i = 0, scale = 1; i < CPU_LOAD_IDX_MAX; i++, scale += scale) { unsigned long old_load, new_load; /* scale is effectively 1 << i now, and >> i divides by scale */ old_load = this_rq->cpu_load[i]; new_load = this_load; this_rq->cpu_load[i] = (old_load*(scale-1) + new_load) >> i; } } For stable only; the code has been removed in 2.6.24. Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26ACPI: VIDEO: Adjust current level to closest available one.Alexey Starikovskiy
patch 63f0edfc0b7f8058f9d3f9b572615ec97ae011ba in mainline. ACPI: VIDEO: Adjust current level to closest available one. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26libata: sata_sis: use correct S/G table sizeJeff Garzik
patch 96af154710d44b574515431a0bb014888398a741 in mainline. [libata] sata_sis: use correct S/G table size sata_sis has the same restrictions as other SFF controllers, and so must use LIBATA_MAX_PRD to denote that SCSI may only fill ATA_MAX_PRD/2 entries, due to our need to handle IOMMU merging. Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26sata_sis: fix SCR read breakageTejun Heo
patch aaa092a114696f4425cd57c4d7fa05110007e247 in mainline. sata_sis: fix SCR read breakage SCR read for controllers which uses PCI configuration space for SCR access got broken while adding @val argument to SCR accessors. Fix it. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Cc: Tobias Powalowski <t.powa@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty fileFengguang Wu
patch c06a018fa5362fa9ed0768bd747c0fab26bc8849 in mainline. This is not a new problem in 2.6.23-git17. 2.6.22/2.6.23 is buggy in the same way. Reiserfs could accumulate dirty sub-page-size files until umount time. They cannot be synced to disk by pdflush routines or explicit `sync' commands. Only `umount' can do the trick. The direct cause is: the dirty page's PG_dirty is wrongly _cleared_. Call trace: [<ffffffff8027e920>] cancel_dirty_page+0xd0/0xf0 [<ffffffff8816d470>] :reiserfs:reiserfs_cut_from_item+0x660/0x710 [<ffffffff8816d791>] :reiserfs:reiserfs_do_truncate+0x271/0x530 [<ffffffff8815872d>] :reiserfs:reiserfs_truncate_file+0xfd/0x3b0 [<ffffffff8815d3d0>] :reiserfs:reiserfs_file_release+0x1e0/0x340 [<ffffffff802a187c>] __fput+0xcc/0x1b0 [<ffffffff802a1ba6>] fput+0x16/0x20 [<ffffffff8029e676>] filp_close+0x56/0x90 [<ffffffff8029fe0d>] sys_close+0xad/0x110 [<ffffffff8020c41e>] system_call+0x7e/0x83 Fix the bug by removing the cancel_dirty_page() call. Tests show that it causes no bad behaviors on various write sizes. === for the patient === Here are more detailed demonstrations of the problem. 1) the page has both PG_dirty(D)/PAGECACHE_TAG_DIRTY(d) after being written to; and then only PAGECACHE_TAG_DIRTY(d) remains after the file is closed. ------------------------------ screen 0 ------------------------------ [T0] root /home/wfg# cat > /test/tiny [T1] hi [T2] root /home/wfg# ------------------------------ screen 1 ------------------------------ [T1] root /home/wfg# echo /test/tiny > /proc/filecache [T1] root /home/wfg# cat /proc/filecache # file /test/tiny # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback # idx len state refcnt 0 1 ___UD__Bd_ 2 [T2] root /home/wfg# cat /proc/filecache # file /test/tiny # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback # idx len state refcnt 0 1 ___U___Bd_ 2 2) note the non-zero 'cancelled_write_bytes' after /tmp/hi is copied. ------------------------------ screen 0 ------------------------------ [T0] root /home/wfg# echo hi > /tmp/hi [T1] root /home/wfg# cp /tmp/hi /dev/stdin /test [T2] hi [T3] root /home/wfg# ------------------------------ screen 1 ------------------------------ [T1] root /proc/4397# cd /proc/`pidof cp` [T1] root /proc/4713# cat io rchar: 8396 wchar: 3 syscr: 20 syscw: 1 read_bytes: 0 write_bytes: 20480 cancelled_write_bytes: 4096 [T2] root /proc/4713# cat io rchar: 8399 wchar: 6 syscr: 21 syscw: 2 read_bytes: 0 write_bytes: 24576 cancelled_write_bytes: 4096 //Question: the 'write_bytes' is a bit more than expected ;-) Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn> Reviewed-by: Chris Mason <chris.mason@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26x86: disable preemption in delay_tsc()Andrew Morton
patch 35d5d08a085c56f153458c3f5d8ce24123617faf in mainline. Marin Mitov points out that delay_tsc() can misbehave if it is preempted and rescheduled on a different CPU which has a skewed TSC. Fix it by disabling preemption. (I assume that the worst-case behaviour here is a stall of 2^32 cycles) Cc: Andi Kleen <ak@suse.de> Cc: Marin Mitov <mitov@issp.bas.bg> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26dmaengine: fix broken device refcountingHaavard Skinnemoen
patch 348badf1e825323c419dd118f65783db0f7d2ec8 in mainline. When a DMA device is unregistered, its reference count is decremented twice for each channel: Once dma_class_dev_release() and once in dma_chan_cleanup(). This may result in the DMA device driver's remove() function completing before all channels have been cleaned up, causing lots of use-after-free fun. Fix it by incrementing the device's reference count twice for each channel during registration. [dan.j.williams@intel.com: kill unnecessary client refcounting] Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26nfsd4: recheck for secure ports in fh_verifyJ. Bruce Fields
patch 6fa02839bf9412e18e773d04e96182b4cd0b5d57 in mainline. As with 7fc90ec93a5eb71f4b08... "call nfsd_setuser() on fh_compose()..." this is a case where we need to redo a security check in fh_verify() even though the filehandle already has an associated dentry--if the filehandle was created by fh_compose() in an earlier operation of the nfsv4 compound, then we may not have done these checks yet. Without this fix it is possible, for example, to traverse from an export without the secure ports requirement to one with it in a single compound, and bypass the secure port check on the new export. While we're here, fix up some minor style problems and change a printk() to a dprintk(), to make it harder for random unprivileged users to spam the logs. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Reviewed-By: NeilBrown <neilb@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26knfsd: fix spurious EINVAL errors on first access of new filesystemJ. Bruce Fields
patch ac8587dcb58e40dd336d99d60f852041e06cc3dd in mainline. The v2/v3 acl code in nfsd is translating any return from fh_verify() to nfserr_inval. This is particularly unfortunate in the case of an nfserr_dropit return, which is an internal error meant to indicate to callers that this request has been deferred and should just be dropped pending the results of an upcall to mountd. Thanks to Roland <devzero@web.de> for bug report and data collection. Cc: Roland <devzero@web.de> Acked-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Reviewed-By: NeilBrown <neilb@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26raid5: fix unending write sequenceDan Williams
patch 6c55be8b962f1bdc592d579e81fc27b11ea53dfc in mainline. <debug output from Joel's system> handling stripe 7629696, state=0x14 cnt=1, pd_idx=2 ops=0:0:0 check 5: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800ffcffcc0 written 0000000000000000 check 4: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800fdd4e360 written 0000000000000000 check 3: state 0x1 toread 0000000000000000 read 0000000000000000 write 0000000000000000 written 0000000000000000 check 2: state 0x1 toread 0000000000000000 read 0000000000000000 write 0000000000000000 written 0000000000000000 check 1: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800ff517e40 written 0000000000000000 check 0: state 0x6 toread 0000000000000000 read 0000000000000000 write fffff800fd4cae60 written 0000000000000000 locked=4 uptodate=2 to_read=0 to_write=4 failed=0 failed_num=0 for sector 7629696, rmw=0 rcw=0 </debug> These blocks were prepared to be written out, but were never handled in ops_run_biodrain(), so they remain locked forever. The operations flags are all clear which means handle_stripe() thinks nothing else needs to be done. This state suggests that the STRIPE_OP_PREXOR bit was sampled 'set' when it should not have been. This patch cleans up cases where the code looks at sh->ops.pending when it should be looking at the consistent stack-based snapshot of the operations flags. Report from Joel: Resync done. Patch fix this bug. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Tested-by: Joel Bertrand <joel.bertrand@systella.fr> Cc: <stable@kernel.org> Cc: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26oProfile: oops when profile_pc() returns ~0LUPhilippe Elie
patch df9d177aa28d50e64bae6fbd6b263833079e3571 in mainline. Instruction pointer returned by profile_pc() can be a random value. This break the assumption than we can safely set struct op_sample.eip field to a magic value to signal to the per-cpu buffer reader side special event like task switch ending up in a segfault in get_task_mm() when profile_pc() return ~0UL. Fixed by sanitizing the sampled eip and reject/log invalid eip. Problem reported by Sami Farin, patch tested by him. Signed-off-by: Philippe Elie <phil.el@wanadoo.fr> Tested-by: Sami Farin <safari-kernel@safari.iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26drivers/video/ps3fb: fix memset size errorLi Zefan
patch 3cc2c17700c98b0af778566b0af6292b23b01430 in mainline. The size passing to memset is wrong. Signed-off-by Li Zefan <lizf@cn.fujitsu.com> Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26i2c/eeprom: Hide Sony Vaio serial numbersJean Delvare
patch 0f2cbd38aa377e30df3b7602abed69464d1970aa in mainline. The sysfs interface to DMI data takes care to not make the system serial number and UUID world-readable, presumably due to privacy concerns. For consistency, we should not let the eeprom driver export these same strings to the world on Sony Vaio laptops. Instead, only make them readable by root, as we already do for BIOS passwords. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26i2c/eeprom: Recognize VGN as a valid Sony Vaio name prefixJean Delvare
patch 8b925a3dd8a4d7451092cb9aa11da727ba69e0f0 in mainline. Recent (i.e. 2005 and later) Sony Vaio laptops have names beginning with VGN rather than PCG. Update the eeprom driver so that it recognizes these. Why this matters: the eeprom driver hides private data from the EEPROMs it recognizes as Vaio EEPROMs (passwords, serial number...) so if the driver fails to recognize a Vaio EEPROM as such, the private data is exposed to the world. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26i2c-pasemi: Fix NACK detectionJean Delvare
patch be8a1f7cd4501c3b4b32543577a33aee6d2193ac in mainline. Turns out we don't actually check the status to see if there was a device out there to talk to, just if we had a timeout when doing so. Add the proper check, so we don't falsly think there are devices on the bus that are not there, etc. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-16Linux 2.6.23.8v2.6.23.8Greg Kroah-Hartman