commit 3ad3367cdc36ff6ce4efd2159c39923a2b334f94 Author: Greg Kroah-Hartman Date: Tue Jun 24 14:09:06 2008 -0700 Linux 2.6.25.9 commit a3abcfa827d9bf769829d3ca0036a12a7a058a02 Author: Linus Torvalds Date: Mon Jun 23 11:21:37 2008 -0700 Fix ZERO_PAGE breakage with vmware commit 672ca28e300c17bf8d792a2a7a8631193e580c74 upstream Commit 89f5b7da2a6bad2e84670422ab8192382a5aeb9f ("Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP") broke vmware, as reported by Jeff Chua: "This broke vmware 6.0.4. Jun 22 14:53:03.845: vmx| NOT_IMPLEMENTED /build/mts/release/bora-93057/bora/vmx/main/vmmonPosix.c:774" and the reason seems to be that there's an old bug in how we handle do FOLL_ANON on VM_SHARED areas in get_user_pages(), but since it only triggered if the whole page table was missing, nobody had apparently hit it before. The recent changes to 'follow_page()' made the FOLL_ANON logic trigger not just for whole missing page tables, but for individual pages as well, and exposed this problem. This fixes it by making the test for when FOLL_ANON is used more careful, and also makes the code easier to read and understand by moving the logic to a separate inline function. Reported-and-tested-by: Jeff Chua Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 31a26cd34a33c8137ebbf254e4e35536c45ae9b5 Author: Jean Delvare Date: Mon Jun 23 10:22:10 2008 +0200 hwmon: (adt7473) Initialize max_duty_at_overheat before use commit ed4ec814e45ae8b1596aea0a29b92f6c3614acaa upstream data->max_duty_at_overheat is not updated in adt7473_update_device, so it might be used before it is initialized (if the user reads from sysfs file max_duty_at_crit before writing to it.) Signed-off-by: Jean Delvare Acked-by: Darrick J. Wong Signed-off-by: Mark M. Hoffman Signed-off-by: Greg Kroah-Hartman commit 73377b7ebafbb69016a6cf4342b65c560a85342e Author: Jean Delvare Date: Mon Jun 23 10:14:26 2008 +0200 hwmon: (lm85) Fix function RANGE_TO_REG() Function RANGE_TO_REG() is broken. For a requested range of 2000 (2 degrees C), it will return an index value of 15, i.e. 80.0 degrees C, instead of the expected index value of 0. All other values are handled properly, just 2000 isn't. The bug was introduced back in November 2004 by this patch: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=1c28d80f1992240373099d863e4996cdd5d646d0 In Linus' kernel I decided to rewrite the whole function in a way which was more obviously correct. But for -stable let's just do the minimal fix. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit e5e3a8f78823da1e66b75f7bcc28626589fb650c Author: Linus Torvalds Date: Fri Jun 20 12:19:28 2008 -0700 watchdog: hpwdt: fix use of inline assembly commit 1f6ef2342972dc7fd623f360f84006e2304eb935 upstream The inline assembly in drivers/watchdog/hpwdt.c was incredibly broken, and included all the function prologue and epilogue stuff, even though it was itself then inside a C function where the compiler would add its own prologue and epilogue on top of it all. This then just _happened_ to work if you had exactly the right compiler version and exactly the right compiler flags, so that gcc just happened to not create any prologue at all (the gcc-generated epilogue wouldn't matter, since it would never be reached). But the more proper way to fix it is to simply not do this. Move the inline asm to the top level, with no surrounding function at all (the better alternative would be to remove the prologue and make it actually use proper description of the arguments to the inline asm, but that's a bigger change than the one I'm willing to make right now). Tested-by: S.Çağlar Onur Acked-by: Thomas Mingarelli Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 14e2b0d02fb9ebd54166c1d76c3eeb15c00524c2 Author: Jeremy Fitzhardinge Date: Fri Jun 20 21:32:12 2008 +0000 x86: set PAE PHYSICAL_MASK_SHIFT to 44 bits. commit ad524d46f36bbc32033bb72ba42958f12bf49b06 upstream When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can potentially have the same number of physical address bits as the 64-bit host ("Enhanced Legacy PAE Paging"). This means, in theory, we could have up to 52 bits of physical address in a pte. The 32-bit kernel uses a 32-bit unsigned long to represent a pfn. This means that it can only represent physical addresses up to 32+12=44 bits wide. Rather than widening pfns everywhere, just set 2^44 as the Linux x86_32-PAE architectural limit for physical address size. This is a bugfix for two cases: 1. running a 32-bit PAE kernel on a machine with more than 64GB RAM. 2. running a 32-bit PAE Xen guest on a host machine with more than 64GB RAM In both cases, a pte could need to have more than 36 bits of physical, and masking it to 36-bits will cause fairly severe havoc. Signed-off-by: Jeremy Fitzhardinge Cc: Jan Beulich Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6433ff677312c44e46336d208b44a1f99aac11f4 Author: Bernhard Walle Date: Fri Jun 20 21:31:06 2008 +0000 x86: use BOOTMEM_EXCLUSIVE on 32-bit commit d3942cff620bea073fc4e3c8ed878eb1e84615ce upstream This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for i386 and prints a error message on failure. The patch is still for 2.6.26 since it is only bug fixing. The unification of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27. Signed-off-by: Bernhard Walle Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8c3a10753bfb7ba66b024398cc9bad9eea82a99f Author: Bernhard Walle Date: Sat Jun 21 19:01:02 2008 +0200 Add return value to reserve_bootmem_node() commit 71c2742f5e6348d76ee62085cf0a13e5eff0f00e upstream This patch changes the function reserve_bootmem_node() from void to int, returning -ENOMEM if the allocation fails. This fixes a build problem on x86 with CONFIG_KEXEC=y and CONFIG_NEED_MULTIPLE_NODES=y Signed-off-by: Bernhard Walle Reported-by: Adrian Bunk Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bd3aae04b2b17300b33e2e1b89482715c2cf7de3 Author: David S. Miller Date: Fri Jun 20 22:04:34 2008 -0700 sctp: Make sure N * sizeof(union sctp_addr) does not overflow. commit 735ce972fbc8a65fb17788debd7bbe7b4383cc62 upstream As noticed by Gabriel Campana, the kmalloc() length arg passed in by sctp_getsockopt_local_addrs_old() can overflow if ->addr_num is large enough. Therefore, enforce an appropriate limit. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 489cf6b0ade32067774b89e8e822a012d3f3bb96 Author: Linus Torvalds Date: Fri Jun 20 11:18:25 2008 -0700 Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP commit 89f5b7da2a6bad2e84670422ab8192382a5aeb9f upstream KAMEZAWA Hiroyuki and Oleg Nesterov point out that since the commit 557ed1fa2620dc119adb86b34c614e152a629a80 ("remove ZERO_PAGE") removed the ZERO_PAGE from the VM mappings, any users of get_user_pages() will generally now populate the VM with real empty pages needlessly. We used to get the ZERO_PAGE when we did the "handle_mm_fault()", but since fault handling no longer uses ZERO_PAGE for new anonymous pages, we now need to handle that special case in follow_page() instead. In particular, the removal of ZERO_PAGE effectively removed the core file writing optimization where we would skip writing pages that had not been populated at all, and increased memory pressure a lot by allocating all those useless newly zeroed pages. This reinstates the optimization by making the unmapped PTE case the same as for a non-existent page table, which already did this correctly. While at it, this also fixes the XIP case for follow_page(), where the caller could not differentiate between the case of a page that simply could not be used (because it had no "struct page" associated with it) and a page that just wasn't mapped. We do that by simply returning an error pointer for pages that could not be turned into a "struct page *". The error is arbitrarily picked to be EFAULT, since that was what get_user_pages() already used for the equivalent IO-mapped page case. [ Also removed an impossible test for pte_offset_map_lock() failing: that's not how that function works ] Acked-by: Oleg Nesterov Acked-by: Nick Piggin Cc: KAMEZAWA Hiroyuki Cc: Hugh Dickins Cc: Andrew Morton Cc: Ingo Molnar Cc: Roland McGrath Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2e77edd8f4b9ab4ef6ee4ba3fdc6cf50a972cce1 Author: Radu Cristescu Date: Thu Jun 19 20:27:55 2008 -0500 atl1: relax eeprom mac address error check upstream commit: 58c7821c4264a7ddd6f0c31c5caaf393b3897f10 The atl1 driver tries to determine the MAC address thusly: - If an EEPROM exists, read the MAC address from EEPROM and validate it. - If an EEPROM doesn't exist, try to read a MAC address from SPI flash. - If that fails, try to read a MAC address directly from the MAC Station Address register. - If that fails, assign a random MAC address provided by the kernel. We now have a report of a system fitted with an EEPROM containing all zeros where we expect the MAC address to be, and we currently handle this as an error condition. Turns out, on this system the BIOS writes a valid MAC address to the NIC's MAC Station Address register, but we never try to read it because we return an error when we find the all- zeros address in EEPROM. This patch relaxes the error check and continues looking for a MAC address even if it finds an illegal one in EEPROM. http://ubuntuforums.org/showthread.php?t=562617 [jacliburn@bellsouth.net: backport to 2.6.25.7] Signed-off-by: Radu Cristescu Signed-off-by: Jay Cliburn Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman