commit 8996d0af900ec60b8b59435aa231e2d449bba6af Author: Greg Kroah-Hartman Date: Mon Nov 26 09:51:43 2007 -0800 Linux 2.6.23.9 commit 6bb559a3239d0e7ca53c54ba7a6e8105c855dff3 Author: Dan Williams Date: Tue Oct 9 13:55:24 2007 -0400 ipw2200: batch non-user-requested scan result notifications 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 Signed-off-by: John W. Linville Cc: Tobias Powalowski Signed-off-by: Greg Kroah-Hartman commit 590ca6cb7c01f733663d6b3ac47a2206ad9016ab Author: Ortwin Glück Date: Thu Oct 11 17:29:43 2007 +0200 USB: Nikon D40X unusual_devs entry 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 Cc: Tobias Powalowski Signed-off-by: Greg Kroah-Hartman commit 1ed8fc8e46c005673d0b731c89ddb514c9cf6543 Author: Phil Dibowitz Date: Sat Sep 22 20:58:12 2007 -0700 USB: unusual_devs modification for Nikon D200 patch 16eb345f4d9189b59bae576ae63cba7ca77817b2 in mainline. Upgrade the unusual_devs.h file to support the Nikon D200 Signed-off-by: Mike Pagano Signed-off-by: Phil Dibowitz Cc: Tobias Powalowski Signed-off-by: Greg Kroah-Hartman commit fd5ec14e724268168221b7210fb36a223bd09c11 Author: Ingo Molnar Date: Tue Oct 16 23:26:06 2007 -0700 softlockup: use cpu_clock() instead of sched_clock() patch a3b13c23f186ecb57204580cc1f2dbe9c284953a in mainline. sched_clock() is not a reliable time-source, use cpu_clock() instead. Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 00aceb500c508412f70b71c78471fcf80a9498c2 Author: Ingo Molnar Date: Sun Nov 18 01:55:38 2007 +0100 softlockup watchdog fixes and cleanups 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 Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds 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! [] show_trace_log_lvl+0x19/0x2e [] show_trace+0x12/0x14 [] dump_stack+0x14/0x16 [] softlockup_tick+0xbe/0xd0 [] run_local_timers+0x12/0x14 [] update_process_times+0x3e/0x63 [] tick_sched_timer+0x7c/0xc0 [] hrtimer_interrupt+0x135/0x1ba [] smp_apic_timer_interrupt+0x6e/0x80 [] apic_timer_interrupt+0x33/0x38 [] syscall_call+0x7/0xb ======================= The new format is: BUG: soft lockup detected on CPU#1! [prctl:2363] Pid: 2363, comm: prctl EIP: 0060:[] 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 [] show_trace_log_lvl+0x19/0x2e [] show_trace+0x12/0x14 [] show_regs+0x1ab/0x1b3 [] softlockup_tick+0xef/0x108 [] run_local_timers+0x12/0x14 [] update_process_times+0x3e/0x63 [] tick_sched_timer+0x7c/0xc0 [] hrtimer_interrupt+0x135/0x1ba [] smp_apic_timer_interrupt+0x6e/0x80 [] apic_timer_interrupt+0x33/0x38 [] 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 Signed-off-by: Satyam Sharma Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 653e60e2a9c16df6fccb3ae16f12d984cf83fb68 Author: David P. Reed Date: Wed Nov 14 17:47:35 2007 -0500 x86: fix freeze in x86_64 RTC update code in time_64.c 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 Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2d429c89279f78109db05d9b7db3348fc64b4ca5 Author: David P. Reed Date: Wed Nov 14 17:49:21 2007 -0500 ntp: fix typo that makes sync_cmos_clock erratic 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 Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 26b880d662d639f0ed0dc5a7b71c1e3557abe003 Author: Andrey Mirkin Date: Wed Oct 17 18:04:33 2007 +0200 x86: return correct error code from child_rip in x86_64 entry.S 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 Signed-off-by: Andi Kleen Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 5b7e28db04cb42b8f8b81c6ae61a7d77bddc373a Author: Huang, Ying Date: Wed Oct 17 18:04:35 2007 +0200 x86: NX bit handling in change_page_attr() 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 Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 420b463a199d10fc89f41f24fb8c60ed0181b4ad Author: Kirill Korotaev Date: Wed Oct 17 18:04:33 2007 +0200 x86: mark read_crX() asm code as volatile 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 Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2e6792e31175f12538e49d72c6dc2fd6e3eb2791 Author: Andrew Hastings Date: Wed Oct 17 18:04:33 2007 +0200 x86: fix off-by-one in find_next_zero_string 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 Signed-off-by: Andi Kleen Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit df84bfba736f56550a32e7a85ad518f3f8431b9c Author: Jan Beulich Date: Wed Oct 17 18:04:33 2007 +0200 i386: avoid temporarily inconsistent pte-s 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 Signed-off-by: Andi Kleen Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 332a20e37fed150e5d45aa6f8c8511568504d139 Author: Herbert Xu Date: Thu Nov 15 09:07:23 2007 +0800 libcrc32c: keep intermediate crc state in cpu order 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 Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ca1b1e5c86d9dd07e3b9ec76e5f771fb2aebcab9 Author: Sebastian Siewior Date: Sat Nov 10 19:37:49 2007 +0800 geode: Fix not inplace encryption 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 Acked-by: Jordan Crouse Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 23a5e6a55c8653d79783a0ebda8083999fb97054 Author: Chuck Ebbert Date: Wed Nov 14 18:33:16 2007 -0500 Fix divide-by-zero in the 2.6.23 scheduler code 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 Acked-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 77675886269b9af9f88d2fcea2fe1a3d02af0f6e Author: Alexey Starikovskiy Date: Thu Nov 15 08:04:29 2007 +0100 ACPI: VIDEO: Adjust current level to closest available one. patch 63f0edfc0b7f8058f9d3f9b572615ec97ae011ba in mainline. ACPI: VIDEO: Adjust current level to closest available one. Signed-off-by: Alexey Starikovskiy Signed-off-by: Len Brown Cc: Tobias Powalowski Signed-off-by: Greg Kroah-Hartman commit 2fcce6c9d17c1a917d67f63c24eedb4761f003c0 Author: Jeff Garzik Date: Thu Nov 15 07:59:44 2007 +0100 libata: sata_sis: use correct S/G table size 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 Cc: Tobias Powalowski Signed-off-by: Greg Kroah-Hartman commit 458c3a1a519ad2a0f228b3c27cb63e378355073d Author: Tejun Heo Date: Thu Nov 15 07:59:44 2007 +0100 sata_sis: fix SCR read breakage 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 Signed-off-by: Jeff Garzik Cc: Tobias Powalowski Signed-off-by: Greg Kroah-Hartman commit a47a72d31c4a119896907d263d6912653f6b3c68 Author: Fengguang Wu Date: Wed Nov 14 16:59:54 2007 -0800 reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty file 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: [] cancel_dirty_page+0xd0/0xf0 [] :reiserfs:reiserfs_cut_from_item+0x660/0x710 [] :reiserfs:reiserfs_do_truncate+0x271/0x530 [] :reiserfs:reiserfs_truncate_file+0xfd/0x3b0 [] :reiserfs:reiserfs_file_release+0x1e0/0x340 [] __fput+0xcc/0x1b0 [] fput+0x16/0x20 [] filp_close+0x56/0x90 [] sys_close+0xad/0x110 [] 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 Cc: Peter Zijlstra Cc: Jeff Mahoney Signed-off-by: Fengguang Wu Reviewed-by: Chris Mason Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 778b656e0e63efe0437fe337b9556bec73dc2f9d Author: Andrew Morton Date: Wed Nov 14 17:00:41 2007 -0800 x86: disable preemption in delay_tsc() 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 Cc: Marin Mitov Cc: Thomas Gleixner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e35595f90a819298c9d518a2a84007a4d5a797fe Author: Haavard Skinnemoen Date: Wed Nov 14 16:59:27 2007 -0800 dmaengine: fix broken device refcounting 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 Signed-off-by: Dan Williams Signed-off-by: Shannon Nelson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4d20a9ee2a451eede499f375e88f0e3cd59e3646 Author: J. Bruce Fields Date: Mon Nov 12 16:05:03 2007 -0500 nfsd4: recheck for secure ports in fh_verify 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 Reviewed-By: NeilBrown Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b770c6cb7beb6368657c5519821097aba18f69c8 Author: J. Bruce Fields Date: Mon Nov 12 16:05:02 2007 -0500 knfsd: fix spurious EINVAL errors on first access of new filesystem 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 for bug report and data collection. Cc: Roland Acked-by: Andreas Gruenbacher Signed-off-by: J. Bruce Fields Reviewed-By: NeilBrown Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 701628909451df9e52b02442893a9a6e6cb66cd7 Author: Dan Williams Date: Wed Nov 14 16:59:35 2007 -0800 raid5: fix unending write sequence patch 6c55be8b962f1bdc592d579e81fc27b11ea53dfc in mainline. 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 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 Tested-by: Joel Bertrand Cc: Cc: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ca6c1144759bdcf92839694a3f16880e2e43305a Author: Philippe Elie Date: Wed Nov 14 16:58:48 2007 -0800 oProfile: oops when profile_pc() returns ~0LU 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 Tested-by: Sami Farin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f4c2ff65ba0168f9e5283890e22add4ed6cb9ba9 Author: Li Zefan Date: Wed Nov 14 16:58:33 2007 -0800 drivers/video/ps3fb: fix memset size error patch 3cc2c17700c98b0af778566b0af6292b23b01430 in mainline. The size passing to memset is wrong. Signed-off-by Li Zefan Acked-by: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dbc8b0aca5b169a457c4057a2b7c9362d804fa24 Author: Jean Delvare Date: Fri Nov 16 10:34:17 2007 +0100 i2c/eeprom: Hide Sony Vaio serial numbers 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 Signed-off-by: Greg Kroah-Hartman commit b89f4bd84bd9945d26e16399a97c991eae0a7a0d Author: Jean Delvare Date: Fri Nov 16 10:37:55 2007 +0100 i2c/eeprom: Recognize VGN as a valid Sony Vaio name prefix 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 Signed-off-by: Greg Kroah-Hartman commit 4a050d6c579a97dbcac44857daf8489f4ba6783a Author: Jean Delvare Date: Fri Nov 16 10:24:36 2007 +0100 i2c-pasemi: Fix NACK detection 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 Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman