commit e5843c6a22dfeca4757bffb07b746c66976d11c3 Author: Greg Kroah-Hartman Date: Thu Jun 11 20:04:50 2009 -0700 Linux 2.6.27.25 commit 02c13375d3dff04bc17724d3983e47a2a36be14c Author: Theodore Ts'o Date: Tue Jun 2 08:09:36 2009 -0400 ext4: Fix race in ext4_inode_info.i_cached_extent (cherry picked from commit 2ec0ae3acec47f628179ee95fe2c4da01b5e9fc4) If two CPU's simultaneously call ext4_ext_get_blocks() at the same time, there is nothing protecting the i_cached_extent structure from being used and updated at the same time. This could potentially cause the wrong location on disk to be read or written to, including potentially causing the corruption of the block group descriptors and/or inode table. This bug has been in the ext4 code since almost the very beginning of ext4's development. Fortunately once the data is stored in the page cache cache, ext4_get_blocks() doesn't need to be called, so trying to replicate this problem to the point where we could identify its root cause was *extremely* difficult. Many thanks to Kevin Shanahan for working over several months to be able to reproduce this easily so we could finally nail down the cause of the corruption. Signed-off-by: "Theodore Ts'o" Reviewed-by: "Aneesh Kumar K.V" Signed-off-by: Greg Kroah-Hartman commit ef3740934e85572dce2e20cecea3341fd43647e0 Author: Aneesh Kumar K.V Date: Tue Jun 2 08:09:35 2009 -0400 ext4: Clear the unwritten buffer_head flag after the extent is initialized (cherry picked from commit 2a8964d63d50dd2d65d71d342bc7fb6ef4117614) The BH_Unwritten flag indicates that the buffer is allocated on disk but has not been written; that is, the disk was part of a persistent preallocation area. That flag should only be set when a get_blocks() function is looking up a inode's logical to physical block mapping. When ext4_get_blocks_wrap() is called with create=1, the uninitialized extent is converted into an initialized one, so the BH_Unwritten flag is no longer appropriate. Hence, we need to make sure the BH_Unwritten is not left set, since the combination of BH_Mapped and BH_Unwritten is not allowed; among other things, it will result ext4's get_block() to be called over and over again during the write_begin phase of write(2). Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit f0e70fb39944b1345203ab72d4c6117da6bf072a Author: Aneesh Kumar K.V Date: Tue Jun 2 08:09:34 2009 -0400 ext4: Use a fake block number for delayed new buffer_head (cherry picked from commit 33b9817e2ae097c7b8d256e3510ac6c54fc6d9d0) Use a very large unsigned number (~0xffff) as as the fake block number for the delayed new buffer. The VFS should never try to write out this number, but if it does, this will make it obvious. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 9c7354d9e36b9581930a89a0c60226da5a2e7dbf Author: Aneesh Kumar K.V Date: Tue Jun 2 08:09:33 2009 -0400 ext4: Fix sub-block zeroing for writes into preallocated extents (cherry picked from commit 9c1ee184a30394e54165fa4c15923cabd952c106) We need to mark the buffer_head mapping preallocated space as new during write_begin. Otherwise we don't zero out the page cache content properly for a partial write. This will cause file corruption with preallocation. Now that we mark the buffer_head new we also need to have a valid buffer_head blocknr so that unmap_underlying_metadata() unmaps the correct block. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 28d64a64f5bb17b8dab69366d9fb6930dc93322a Author: Theodore Ts'o Date: Tue Jun 2 08:09:32 2009 -0400 ext4: Ignore i_file_acl_high unless EXT4_FEATURE_INCOMPAT_64BIT is present (cherry picked from commit a9e817425dc0baede8ebe5fbc9984a640257432b) Don't try to look at i_file_acl_high unless the INCOMPAT_64BIT feature bit is set. The field is normally zero, but older versions of e2fsck didn't automatically check to make sure of this, so in the spirit of "be liberal in what you accept", don't look at i_file_acl_high unless we are using a 64-bit filesystem. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit a7477120f9da23c4ee1ba66af7eb5e931d5061ad Author: Theodore Ts'o Date: Tue Jun 2 08:09:31 2009 -0400 ext4: Fix softlockup caused by illegal i_file_acl value in on-disk inode (cherry picked from commit 485c26ec70f823f2a9cf45982b724893e53a859e) If the block containing external extended attributes (which is stored in i_file_acl and i_file_acl_high) is larger than the on-disk filesystem, the process which tried to access the extended attributes will endlessly issue kernel printks complaining that "__find_get_block_slow() failed", locking up that CPU until the system is forcibly rebooted. So when we read in the inode, make sure the i_file_acl value is legal, and if not, flag the filesystem as being corrupted. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit d797fe6ff1a3db2f6d69835c090e820424fcbddb Author: Chuck Ebbert Date: Tue Jun 2 08:09:30 2009 -0400 ext4: really print the find_group_flex fallback warning only once (cherry picked from commit 6b82f3cb2d480b7714eb0ff61aee99c22160389e) Missing braces caused the warning to print more than once. Signed-Off-By: Chuck Ebbert Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit e025f408e6c036ce2447096c2bf8a2046c106ed3 Author: Theodore Ts'o Date: Tue Jun 2 08:09:29 2009 -0400 ext4: fix locking typo in mballoc which could cause soft lockup hangs upstream commit: e7c9e3e99adf6c49c5d593a51375916acc039d1e Smatch (http://repo.or.cz/w/smatch.git/) complains about the locking in ext4_mb_add_n_trim() from fs/ext4/mballoc.c 4438 list_for_each_entry_rcu(tmp_pa, &lg->lg_prealloc_list[order], 4439 pa_inode_list) { 4440 spin_lock(&tmp_pa->pa_lock); 4441 if (tmp_pa->pa_deleted) { 4442 spin_unlock(&pa->pa_lock); 4443 continue; 4444 } Brown paper bag time... Reported-by: Dan Carpenter Reviewed-by: Eric Sandeen Reviewed-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Cc: stable@kernel.org Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 1a7112dad612fff39a34507f1b3032fa4690c31a Author: Dan Carpenter Date: Tue Jun 2 08:09:28 2009 -0400 ext4: fix typo which causes a memory leak on error path upstream commit: a7b19448ddbdc34b2b8fedc048ba154ca798667b This was found by smatch (http://repo.or.cz/w/smatch.git/) Signed-off-by: Dan Carpenter Signed-off-by: "Theodore Ts'o" Cc: stable@kernel.org Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 22b2e568cf630a9c5c5d229fc56fa88ace5658e0 Author: Jan Kara Date: Tue Jun 2 08:09:27 2009 -0400 jbd2: Update locking coments (cherry picked from commit 86db97c87f744364d5889ca8a4134ca2048b8f83) Update information about locking in JBD2 revoke code. Inconsistency in comments found by Lin Tan CC: Lin Tan Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit ee098c1e0aafeae998f730a4864e5ef71970d132 Author: Theodore Ts'o Date: Tue Jun 2 08:09:26 2009 -0400 ext4: Check for an valid i_mode when reading the inode from disk (cherry picked from commit 563bdd61fe4dbd6b58cf7eb06f8d8f14479ae1dc) Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 5f1839fa7f1f9431fe85dc512ed765caf96bdc1f Author: Aneesh Kumar K.V Date: Tue Jun 2 08:09:25 2009 -0400 ext4: Fix discard of inode prealloc space with delayed allocation. (cherry picked from commit d6014301b5599fba395c42a1e96a7fe86f7d0b2d) With delayed allocation we should not/cannot discard inode prealloc space during file close. We would still have dirty pages for which we haven't allocated blocks yet. With this fix after each get_blocks request we check whether we have zero reserved blocks and if yes and we don't have any writers on the file we discard inode prealloc space. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 663d2c001cad1e268371dcda82de46815189e2f2 Author: Theodore Ts'o Date: Tue Jun 2 08:09:24 2009 -0400 ext4: Automatically allocate delay allocated blocks on rename (cherry picked from commit 8750c6d5fcbd3342b3d908d157f81d345c5325a7) When renaming a file such that a link to another inode is overwritten, force any delay allocated blocks that to be allocated so that if the filesystem is mounted with data=ordered, the data blocks will be pushed out to disk along with the journal commit. Many application programs expect this, so we do this to avoid zero length files if the system crashes unexpectedly. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 10d984daec00917893707a443add0a7a0f190da2 Author: Theodore Ts'o Date: Tue Jun 2 08:09:23 2009 -0400 ext4: Automatically allocate delay allocated blocks on close (cherry picked from commit 7d8f9f7d150dded7b68e61ca6403a1f166fb4edf) When closing a file that had been previously truncated, force any delay allocated blocks that to be allocated so that if the filesystem is mounted with data=ordered, the data blocks will be pushed out to disk along with the journal commit. Many application programs expect this, so we do this to avoid zero length files if the system crashes unexpectedly. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 5493749d2491380de2a06719a86125c122934c9d Author: Theodore Ts'o Date: Tue Jun 2 08:09:22 2009 -0400 ext4: add EXT4_IOC_ALLOC_DA_BLKS ioctl (cherry picked from commit ccd2506bd43113659aa904d5bea5d1300605e2a6) Add an ioctl which forces all of the delay allocated blocks to be allocated. This also provides a function ext4_alloc_da_blocks() which will be used by the following commits to force files to be fully allocated to preserve application-expected ext3 behaviour. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit ef38fe332870b7c1fb831c18ee5eb298a3e51b01 Author: Theodore Ts'o Date: Tue Jun 2 08:09:21 2009 -0400 ext4: Add fine print for the 32000 subdirectory limit (cherry picked from commit 722bde6875bfb49a0c84e5601eb82dd7ac02d27c) Some poeple are reading the ext4 feature list too literally and create dubious test cases involving very long filenames and 1k blocksize and then complain when they run into an htree-imposed limit. So add fine print to the "fix 32000 subdirectory limit" ext4 feature. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 3f15f8f5ce1b2f042d5381d6150597ae920ee396 Author: Bryan Donlan Date: Tue Jun 2 08:09:20 2009 -0400 ext4: return -EIO not -ESTALE on directory traversal through deleted inode (cherry picked from commit e6f009b0b45220c004672d41a58865e94946104d) ext4_iget() returns -ESTALE if invoked on a deleted inode, in order to report errors to NFS properly. However, in ext4_lookup(), this -ESTALE can be propagated to userspace if the filesystem is corrupted such that a directory entry references a deleted inode. This leads to a misleading error message - "Stale NFS file handle" - and confusion on the part of the admin. The bug can be easily reproduced by creating a new filesystem, making a link to an unused inode using debugfs, then mounting and attempting to ls -l said link. This patch thus changes ext4_lookup to return -EIO if it receives -ESTALE from ext4_iget(), as ext4 does for other filesystem metadata corruption; and also invokes the appropriate ext*_error functions when this case is detected. Signed-off-by: Bryan Donlan Cc: Signed-off-by: Andrew Morton Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 3af274c2681fad65f2fd5c0d4495f1b683100561 Author: Duane Griffin Date: Tue Jun 2 08:09:19 2009 -0400 ext4: tighten restrictions on inode flags (cherry picked from commit 2dc6b0d48ca0599837df21b14bb8393d0804af57) At the moment there are few restrictions on which flags may be set on which inodes. Specifically DIRSYNC may only be set on directories and IMMUTABLE and APPEND may not be set on links. Tighten that to disallow TOPDIR being set on non-directories and only NODUMP and NOATIME to be set on non-regular file, non-directories. Introduces a flags masking function which masks flags based on mode and use it during inode creation and when flags are set via the ioctl to facilitate future consistency. Signed-off-by: Duane Griffin Acked-by: Andreas Dilger Cc: Signed-off-by: Andrew Morton Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit aba1b58ea51c55c00afdcc6efc1cd2f4fdecf20b Author: Duane Griffin Date: Tue Jun 2 08:09:18 2009 -0400 ext4: don't inherit inappropriate inode flags from parent (cherry picked from commit 8fa43a81b97853fc69417bb6054182e78f95cbeb) At present INDEX and EXTENTS are the only flags that new ext4 inodes do NOT inherit from their parent. In addition prevent the flags DIRTY, ECOMPR, IMAGIC, TOPDIR, HUGE_FILE and EXT_MIGRATE from being inherited. List inheritable flags explicitly to prevent future flags from accidentally being inherited. This fixes the TOPDIR flag inheritance bug reported at http://bugzilla.kernel.org/show_bug.cgi?id=9866. Signed-off-by: Duane Griffin Acked-by: Andreas Dilger Cc: Signed-off-by: Andrew Morton Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit a529e6f6579e30c3e9a18dc30a87a62be169acde Author: Eric Sandeen Date: Tue Jun 2 08:09:17 2009 -0400 ext4: fix bb_prealloc_list corruption due to wrong group locking (cherry-picked from commit d33a1976fbee1ee321d6f014333d8f03a39d526c) This is for Red Hat bug 490026: EXT4 panic, list corruption in ext4_mb_new_inode_pa ext4_lock_group(sb, group) is supposed to protect this list for each group, and a common code flow to remove an album is like this: ext4_get_group_no_and_offset(sb, pa->pa_pstart, &grp, NULL); ext4_lock_group(sb, grp); list_del(&pa->pa_group_list); ext4_unlock_group(sb, grp); so it's critical that we get the right group number back for this prealloc context, to lock the right group (the one associated with this pa) and prevent concurrent list manipulation. however, ext4_mb_put_pa() passes in (pa->pa_pstart - 1) with a comment, "-1 is to protect from crossing allocation group". This makes sense for the group_pa, where pa_pstart is advanced by the length which has been used (in ext4_mb_release_context()), and when the entire length has been used, pa_pstart has been advanced to the first block of the next group. However, for inode_pa, pa_pstart is never advanced; it's just set once to the first block in the group and not moved after that. So in this case, if we subtract one in ext4_mb_put_pa(), we are actually locking the *previous* group, and opening the race with the other threads which do not subtract off the extra block. Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 45658de1b35a2711610037d6a06b50a2dd4485fa Author: Eric Sandeen Date: Tue Jun 2 08:09:16 2009 -0400 ext4: fix bogus BUG_ONs in in mballoc code (cherry picked from commit 8d03c7a0c550e7ab24cadcef5e66656bfadec8b9) Thiemo Nagel reported that: # dd if=/dev/zero of=image.ext4 bs=1M count=2 # mkfs.ext4 -v -F -b 1024 -m 0 -g 512 -G 4 -I 128 -N 1 \ -O large_file,dir_index,flex_bg,extent,sparse_super image.ext4 # mount -o loop image.ext4 mnt/ # dd if=/dev/zero of=mnt/file oopsed, with a BUG_ON in ext4_mb_normalize_request because size == EXT4_BLOCKS_PER_GROUP It appears to me (esp. after talking to Andreas) that the BUG_ON is bogus; a request of exactly EXT4_BLOCKS_PER_GROUP should be allowed, though larger sizes do indicate a problem. Fix that an another (apparently rare) codepath with a similar check. Reported-by: Thiemo Nagel Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 7a4cdb25839657d92ea9cacdfc12789735e4500b Author: Theodore Ts'o Date: Tue Jun 2 08:09:15 2009 -0400 ext4: Print the find_group_flex() warning only once (cherry picked from commit 2842c3b5449f31470b61db716f1926b594fb6156) This is a short-term warning, and even printk_ratelimit() can result in too much noise in system logs. So only print it once as a warning. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 2f99429dd64583792c5dffbb6af3ce9d67f71016 Author: Eric Sandeen Date: Tue Jun 2 08:09:14 2009 -0400 ext4: fix header check in ext4_ext_search_right() for deep extent trees. (cherry picked from commit 395a87bfefbc400011417e9eaae33169f9f036c0) The ext4_ext_search_right() function is confusing; it uses a "depth" variable which is 0 at the root and maximum at the leaves, but the on-disk metadata uses a "depth" (actually eh_depth) which is opposite: maximum at the root, and 0 at the leaves. The ext4_ext_check_header() function is given a depth and checks the header agaisnt that depth; it expects the on-disk semantics, but we are giving it the opposite in the while loop in this function. We should be giving it the on-disk notion of "depth" which we can get from (p_depth - depth) - and if you look, the last (more commonly hit) call to ext4_ext_check_header() does just this. Sending in the wrong depth results in (incorrect) messages about corruption: EXT4-fs error (device sdb1): ext4_ext_search_right: bad header in inode #2621457: unexpected eh_depth - magic f30a, entries 340, max 340(0), depth 1(2) http://bugzilla.kernel.org/show_bug.cgi?id=12821 Reported-by: David Dindorp Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit fccb0272b539368be564a8d09ae4b71134a237d3 Author: Eric Sandeen Date: Tue Jun 2 08:09:13 2009 -0400 ext4: fix ext4_free_inode() vs. ext4_claim_inode() race (cherry picked from commit 7ce9d5d1f3c8736511daa413c64985a05b2feee3) I was seeing fsck errors on inode bitmaps after a 4 thread dbench run on a 4 cpu machine: Inode bitmap differences: -50736 -(50752--50753) etc... I believe that this is because ext4_free_inode() uses atomic bitops, and although ext4_new_inode() *used* to also use atomic bitops for synchronization, commit 393418676a7602e1d7d3f6e560159c65c8cbd50e changed this to use the sb_bgl_lock, so that we could also synchronize against read_inode_bitmap and initialization of uninit inode tables. However, that change left ext4_free_inode using atomic bitops, which I think leaves no synchronization between setting & unsetting bits in the inode table. The below patch fixes it for me, although I wonder if we're getting at all heavy-handed with this spinlock... Signed-off-by: Eric Sandeen Reviewed-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 00d025abdfdcc686052ed1d9c25f10ead680e620 Author: Jiri Slaby Date: Wed May 13 09:55:26 2009 +0200 mac80211: pid, fix memory corruption commit a8659597bf744b0f8d2560e2a734b5c941569e0e upstream pid doesn't count with some band having more bitrates than the one associated the first time. Fix that by counting the maximal available bitrate count and allocate big enough space. Secondly, fix touching uninitialized memory which causes panics. Index sucked from this random memory points to the hell. The fix is to sort the rates on each band change. Also remove a comment which is wrong now. This version also contains half of mac80211: avoid NULL ptr deref when finding max_rates in PID and minstrel patch by John W. Linville, which is namely: - if (sband->n_bitrates > max_rates) + if (sband && sband->n_bitrates > max_rates) to fix oopses on one band devices. Signed-off-by: Jiri Slaby Cc: John W. Linville Signed-off-by: Greg Kroah-Hartman commit edafc7a273c17f4806fd785c2fb0574161e8dcf5 Author: Brian Maly Date: Tue Mar 3 21:55:31 2009 -0500 x86: fix DMI on EFI commit ff0c0874905fb312ca1491bbdac2653b0b48c20b upstream. Impact: reactivate DMI quirks on EFI hardware DMI tables are loaded by EFI, so the dmi calls must happen after efi_init() and not before. Currently Apple hardware uses DMI to determine the framebuffer mappings for efifb. Without DMI working you also have no video on MacBook Pro. This patch resolves the DMI issue for EFI hardware (DMI is now properly detected at boot), and additionally efifb now loads on Apple hardware (i.e. video works). Signed-off-by: Brian Maly Acked-by: Yinghai Lu Cc: ying.huang@intel.com LKML-Reference: <49ADEDA3.1030406@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2544b8905986f808751df99766ed6f04051ed098 Author: Jean Delvare Date: Tue Jun 2 14:33:47 2009 +0200 V4L/DVB (10943): cx88: Prevent general protection fault on rmmod commit 569b7ec73abf576f9a9e4070d213aadf2cce73cb upstream. V4L/DVB (10943): cx88: Prevent general protection fault on rmmod When unloading the cx8800 driver I sometimes get a general protection fault. Analysis revealed a race in cx88_ir_stop(). It can be solved by using a delayed work instead of a timer for infrared input polling. Signed-off-by: Jean Delvare Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c45dabcb311b0bba1c028d2ca5d6e94de65bee0a Author: Yinghai Lu Date: Wed Jun 3 00:13:13 2009 -0700 x86/pci: fix mmconfig detection with 32bit near 4g commit 75e613cdc7bb2ba3795b1bc3ddf19476c767ba68 upstream. Pascal reported and bisected a commit: | x86/PCI: don't call e820_all_mapped with -1 in the mmconfig case which broke one system system. ACPI: Using IOAPIC for interrupt routing PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255 PCI: MCFG area at f0000000 reserved in ACPI motherboard resources PCI: Using MMCONFIG for extended config space it didn't have PCI: updated MCFG configuration 0: base f0000000 segment 0 buses 0 - 63 anymore, and try to use 0xf000000 - 0xffffffff for mmconfig For 32bit, mcfg_res->end could be 32bit only (if 64 resources aren't used) So use end - 1 to pass the value in mcfg->end to avoid overflow. We don't need to worry about the e820 path, they are always 64 bit. Reported-by: Pascal Terjan Bisected-by: Pascal Terjan Tested-by: Pascal Terjan Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit a1f36c3727c032c6190d04098928d7c95962a82e Author: Mel Gorman Date: Thu May 28 14:34:37 2009 -0700 x86: ignore VM_LOCKED when determining if hugetlb-backed page tables can be shared or not commit 32b154c0b0bae2879bf4e549d861caf1759a3546 upstream. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13302 On x86 and x86-64, it is possible that page tables are shared beween shared mappings backed by hugetlbfs. As part of this, page_table_shareable() checks a pair of vma->vm_flags and they must match if they are to be shared. All VMA flags are taken into account, including VM_LOCKED. The problem is that VM_LOCKED is cleared on fork(). When a process with a shared memory segment forks() to exec() a helper, there will be shared VMAs with different flags. The impact is that the shared segment is sometimes considered shareable and other times not, depending on what process is checking. What happens is that the segment page tables are being shared but the count is inaccurate depending on the ordering of events. As the page tables are freed with put_page(), bad pmd's are found when some of the children exit. The hugepage counters also get corrupted and the Total and Free count will no longer match even when all the hugepage-backed regions are freed. This requires a reboot of the machine to "fix". This patch addresses the problem by comparing all flags except VM_LOCKED when deciding if pagetables should be shared or not for hugetlbfs-backed mapping. Signed-off-by: Mel Gorman Acked-by: Hugh Dickins Cc: Ingo Molnar Cc: Lee Schermerhorn Cc: KOSAKI Motohiro Cc: Cc: Eric B Munson Cc: Adam Litke Cc: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ee2e153573979e17a48c2df52ddbab308468a9e1 Author: Warren Free Date: Fri May 8 10:27:08 2009 +0200 USB: isp1760: urb_dequeue doesn't always find the urbs commit 0afb20e00b5053170c85298fed842b32d20b4ea9 upstream. The option driver (and presumably others) allocates several URBs when it opens and tries to free them when it closes. The isp1760_urb_dequeue function gets called, but the packet being dequeued is not necessarily at the front of one of the 32 queues. If not, the isp1760_urb_done function doesn't get called for the URB and the process trying to free it hangs forever on a wait_queue. This patch does two things. If the URB being dequeued has others queued behind it, it re-queues them. And it searches the queues looking for the URB being dequeued rather than just looking at the one at the front of the queue. [bigeasy@linutronix] whitespace fixes, reformating Signed-off-by: Warren Free Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3e29e7c674d1197a919b2d91134569caa7e79484 Author: Clemens Ladisch Date: Wed May 27 10:49:30 2009 +0200 sound: usb-audio: make the MotU Fastlane work again commit 55de5ef970c680d8d75f2a9aa7e4f172140dbd9c upstream. Kernel 2.6.18 broke the MotU Fastlane, which uses duplicate endpoint numbers in a manner that is not only illegal but also confuses the kernel's endpoint descriptor caching mechanism. To work around this, we have to add a separate usb_set_interface() call to guide the USB core to the correct descriptors. Signed-off-by: Clemens Ladisch Reported-and-tested-by: David Fries Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 894e24c2c5b6055ef9704b0ffdbacd9d4fdd130b Author: Eric Paris Date: Mon Jun 1 10:21:05 2009 -0400 SELinux: BUG in SELinux compat_net code This patch is not applicable to Linus's tree as the code in question has been removed for 2.6.30. I'm sending in case any of the stable maintainers would like to push to their branches (which I think anything pre 2.6.30 would like to do). Ubuntu users were experiencing a kernel panic when they enabled SELinux due to an old bug in our handling of the compatibility mode network controls, introduced Jan 1 2008 effad8df44261031a882e1a895415f7186a5098e Most distros have not used the compat_net code since the new code was introduced and so noone has hit this problem before. Ubuntu is the only distro I know that enabled that legacy cruft by default. But, I was ask to look at it and found that the above patch changed a call to avc_has_perm from if(send_perm) to if(!send_perm) in selinux_ip_postroute_iptables_compat(). The result is that users who turn on SELinux and have compat_net set can (and oftern will) BUG() in avc_has_perm_noaudit since they are requesting 0 permissions. This patch corrects that accidental bug introduction. Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 5e5f996a9f864d8db92eb9f5ca2e974794c6ae76 Author: Linus Torvalds Date: Tue May 19 11:25:35 2009 -0700 Avoid ICE in get_random_int() with gcc-3.4.5 commit 26a9a418237c0b06528941bca693c49c8d97edbe upstream. Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an internal compiler error (ICE): drivers/char/random.c: In function `get_random_int': drivers/char/random.c:1672: error: unrecognizable insn: (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91]) (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88]) (subreg:DI (reg:SI 6 bp) 0)) (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil) (nil)) drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083 and after some debugging it turns out that it's due to the code trying to figure out the rough value of the current stack pointer by taking an address of an uninitialized variable and casting that to an integer. This is clearly a compiler bug, but it's not worth fighting - while the current stack kernel pointer might be somewhat hard to predict in user space, it's also not generally going to change for a lot of the call chains for a particular process. So just drop it, and mumble some incoherent curses at the compiler. Tested-by: Martin Knoblauch Cc: Matt Mackall Cc: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 87a60c19acade65ac993baab03467776924a9e2d Author: Linus Torvalds Date: Tue May 5 08:17:43 2009 -0700 random: make get_random_int() more random commit 8a0a9bd4db63bc45e3017bedeafbd88d0eb84d02 upstream. It's a really simple patch that basically just open-codes the current "secure_ip_id()" call, but when open-coding it we now use a _static_ hashing area, so that it gets updated every time. And to make sure somebody can't just start from the same original seed of all-zeroes, and then do the "half_md4_transform()" over and over until they get the same sequence as the kernel has, each iteration also mixes in the same old "current->pid + jiffies" we used - so we should now have a regular strong pseudo-number generator, but we also have one that doesn't have a single seed. Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It has no real meaning. It could be anything. I just picked the previous seed, it's just that now we keep the state in between calls and that will feed into the next result, and that should make all the difference. I made that hash be a per-cpu data just to avoid cache-line ping-pong: having multiple CPU's write to the same data would be fine for randomness, and add yet another layer of chaos to it, but since get_random_int() is supposed to be a fast interface I did it that way instead. I considered using "__raw_get_cpu_var()" to avoid any preemption overhead while still getting the hash be _mostly_ ping-pong free, but in the end good taste won out. Signed-off-by: Ingo Molnar Signed-off-by: Linus Torvalds Cc: Jake Edge Signed-off-by: Greg Kroah-Hartman commit e36ccb57c0089ee645aca4c33c4bd8651e7a6f35 Author: Mel Gorman Date: Thu May 28 14:34:40 2009 -0700 mm: account for MAP_SHARED mappings using VM_MAYSHARE and not VM_SHARED in hugetlbfs commit f83a275dbc5ca1721143698e844243fcadfabf6a upstream. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13302 hugetlbfs reserves huge pages but does not fault them at mmap() time to ensure that future faults succeed. The reservation behaviour differs depending on whether the mapping was mapped MAP_SHARED or MAP_PRIVATE. For MAP_SHARED mappings, hugepages are reserved when mmap() is first called and are tracked based on information associated with the inode. Other processes mapping MAP_SHARED use the same reservation. MAP_PRIVATE track the reservations based on the VMA created as part of the mmap() operation. Each process mapping MAP_PRIVATE must make its own reservation. hugetlbfs currently checks if a VMA is MAP_SHARED with the VM_SHARED flag and not VM_MAYSHARE. For file-backed mappings, such as hugetlbfs, VM_SHARED is set only if the mapping is MAP_SHARED and the file was opened read-write. If a shared memory mapping was mapped shared-read-write for populating of data and mapped shared-read-only by other processes, then hugetlbfs would account for the mapping as if it was MAP_PRIVATE. This causes processes to fail to map the file MAP_SHARED even though it should succeed as the reservation is there. This patch alters mm/hugetlb.c and replaces VM_SHARED with VM_MAYSHARE when the intent of the code was to check whether the VMA was mapped MAP_SHARED or MAP_PRIVATE. Signed-off-by: Mel Gorman Cc: Hugh Dickins Cc: Ingo Molnar Cc: Lee Schermerhorn Cc: KOSAKI Motohiro Cc: Cc: Eric B Munson Cc: Adam Litke Cc: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cad9419bea24912008cc9f26fcbe486cd8d20185 Author: Jeff Kirsher Date: Tue Jun 2 16:38:52 2009 -0700 igb: fix LRO warning This fix is only needed for 2.6.29.y tree, since in 2.6.30 and later IGB has moved to using GRO instead of LRO. igb supports LRO, but was not setting any hooks to the ->set_flags ethtool_ops function. This would trigger warnings if the user tried to enable or disable LRO. Based on the patch provided by Stephen Hemminger Reported-by: Sergey Kononenko Signed-off-by: Jeff Kirsher CC: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman commit c8bcb39871c7418d9649de5ce64474a980814325 Author: Mike Frysinger Date: Tue Jun 2 14:22:49 2009 +0200 hwmon: (lm78) Add missing __devexit_p() commit 39d8bbedb9571a89d638f5b05358f26ab503d7a6 upstream. The remove function uses __devexit, so the .remove assignment needs __devexit_p() to fix a build error with hotplug disabled. Signed-off-by: Mike Frysinger Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 4e46c8238b8d125b28188d146433be3b52539cc5 Author: Neil Horman Date: Tue Jun 2 01:29:58 2009 -0700 e1000: add missing length check to e1000 receive routine commit ea30e11970a96cfe5e32c03a29332554573b4a10 upstream. Patch to fix bad length checking in e1000. E1000 by default does two things: 1) Spans rx descriptors for packets that don't fit into 1 skb on recieve 2) Strips the crc from a frame by subtracting 4 bytes from the length prior to doing an skb_put Since the e1000 driver isn't written to support receiving packets that span multiple rx buffers, it checks the End of Packet bit of every frame, and discards it if its not set. This places us in a situation where, if we have a spanning packet, the first part is discarded, but the second part is not (since it is the end of packet, and it passes the EOP bit test). If the second part of the frame is small (4 bytes or less), we subtract 4 from it to remove its crc, underflow the length, and wind up in skb_over_panic, when we try to skb_put a huge number of bytes into the skb. This amounts to a remote DOS attack through careful selection of frame size in relation to interface MTU. The fix for this is already in the e1000e driver, as well as the e1000 sourceforge driver, but no one ever pushed it to e1000. This is lifted straight from e1000e, and prevents small frames from causing the underflow described above Signed-off-by: Neil Horman Tested-by: Andy Gospodarek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b73fee7b6fe138d73ec8706d46691d476b48d9b8 Author: Roel Kluin Date: Thu May 28 14:34:29 2009 -0700 drivers/serial/mpc52xx_uart.c: fix array overindexing check commit b898f4f869da5b9d41f297fff87aca4cd42d80b3 upstream. The check for an overindexing of mpc52xx_uart_{ports,nodes} has an off-by-one. Signed-off-by: Roel Kluin Acked-by: Wolfram Sang Acked-by: Grant Likely Cc: Benjamin Herrenschmidt Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c9f0ff0caef2cc06e90edc7991f0360890febda1 Author: Shaohua Li Date: Tue Jun 2 10:51:58 2009 +0800 cpuidle: make AMC C1E work in processor_idle commit 87ad57bacb25c3f24c54f142ef445f68277705f0 upstream When AMD C1E is enabled, local APIC timer will stop even in C1. This patch uses broadcast ipi to replace local APIC timer in C1. http://bugzilla.kernel.org/show_bug.cgi?id=13233 [ impact: avoid boot hang in AMD CPU with C1E enabled ] Tested-by: Dmitry Lyzhyn Signed-off-by: Shaohua Li Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 4ec19648b3d8634cc4a08614a252c8739f76903c Author: Shaohua Li Date: Tue May 19 16:09:54 2009 +0800 cpuidle: fix AMD C1E suspend hang commit 7d60e8ab0d5507229dfbdf456501cc378610fa01 upstream. When AMD C1E is enabled, local APIC timer will stop even in C1. To avoid suspend/resume hang, this patch removes C1 and replace it with a cpu_relax() in suspend/resume path. This hasn't any impact in runtime path. http://bugzilla.kernel.org/show_bug.cgi?id=13233 [ impact: avoid suspend/resume hang in AMD CPU with C1E enabled ] Tested-by: Dmitry Lyzhyn Signed-off-by: Shaohua Li Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 44c94aa0806d36ee902350027c20c63283923112 Author: Michael Chan Date: Wed May 6 16:46:47 2009 -0700 bnx2: Fix panic in bnx2_poll_work(). commit 581daf7e00c5e766f26aff80a61a860a17b0d75a upstream. Add barrier() to bnx2_get_hw_{tx|rx}_cons() to fix this issue: http://bugzilla.kernel.org/show_bug.cgi?id=12698 This issue was reported by multiple i386 users. Without barrier(), the compiled code looks like the following where %eax contains the address of the tx_cons or rx_cons in the DMA status block. The status block contents can change between the cmpb and the movzwl instruction. The driver would crash if the value was not 0xff during the cmpb instruction, but changed to 0xff during the movzwl instruction. 6828: 80 38 ff cmpb $0xff,(%eax) 682b: 0f b7 10 movzwl (%eax),%edx With the added barrier(), the compiled code now looks correct: 683d: 0f b7 10 movzwl (%eax),%edx 6840: 0f b6 c2 movzbl %dl,%eax 6843: 3d ff 00 00 00 cmp $0xff,%eax Thanks to Pascal de Bruijn for reporting the problem and Holger Noefer for patiently testing test patches for us. [greg - took out version change] Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 73eb6ac73febd6dea38603b39f78d88ab3cda27a Author: adam radford Date: Mon May 11 14:55:55 2009 -0700 3w-xxxx: scsi_dma_unmap fix commit 7b14f58ad65f9d74e4273fb45360cfea824495aa upstream. This patch fixes the following regression that occurred during the scsi_dma_map()/unmap() changes when compiling with CONFIG_DMA_API_DEBUG=y : WARNING: at lib/dma-debug.c:496 check_unmap+0x142/0x542() Hardware name: 3w-xxxx 0000:02:02.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=36 bytes] Signed-off-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit dd7bee967d1c774f3ae32f9e8f6d3dfd2572e2c9 Author: Ingo Molnar Date: Fri May 22 16:30:39 2009 -0400 x86: work around Fedora-11 x86-32 kernel failures on Intel Atom CPUs commit 211b3d03c7400f48a781977a50104c9d12f4e229 upstream [Trivial backport to 2.6.27 by cebbert@redhat.com] x86: work around Fedora-11 x86-32 kernel failures on Intel Atom CPUs Impact: work around boot crash Work around Intel Atom erratum AAH41 (probabilistically) - it's triggering in the field. Reported-by: Linus Torvalds Tested-by: Kyle McMartin Signed-off-by: Ingo Molnar Cc: Signed-off-by: Greg Kroah-Hartman commit 0fc27bd6135b319fd21b70091b280a6f3b642a87 Author: Ilpo Järvinen Date: Tue May 26 15:51:35 2009 -0700 tcp: fix >2 iw selection [ Upstream commit 86bcebafc5e7f5163ccf828792fe694b112ed6fa ] A long-standing feature in tcp_init_metrics() is such that any of its goto reset prevents call to tcp_init_cwnd(). Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit be139f75e2bdd069a9f2429339a042021e53159d Author: Thomas Chenault Date: Mon May 18 21:43:27 2009 -0700 net: fix skb_seq_read returning wrong offset/length for page frag data [ Upstream commit 995b337952cdf7e05d288eede580257b632a8343 ] When called with a consumed value that is less than skb_headlen(skb) bytes into a page frag, skb_seq_read() incorrectly returns an offset/length relative to skb->data. Ensure that data which should come from a page frag does. Signed-off-by: Thomas Chenault Tested-by: Shyam Iyer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7c2f7a2635a13a4b8c1efb93f599b2a4121f8b6d Author: Florian Westphal Date: Thu May 21 15:07:12 2009 -0700 pktgen: do not access flows[] beyond its length [ Upstream commit 5b5f792a6a9a2f9ae812d151ed621f72e99b1725 ] typo -- pkt_dev->nflows is for stats only, the number of concurrent flows is stored in cflows. Reported-By: Vladimir Ivashchenko Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f3a39d0207da288d2ff37d7a2890f58a483324ec Author: Stanislaw Gruszka Date: Wed Apr 15 02:26:49 2009 -0700 myr10ge: again fix lro_gen_skb() alignment [ Upstream commit 636d2f68a0814d84de26c021b2c15e3b4ffa29de ] Add LRO alignment initially committed in 621544eb8c3beaa859c75850f816dd9b056a00a3 ("[LRO]: fix lro_gen_skb() alignment") and removed in 0dcffac1a329be69bab0ac604bf7283737108e68 ("myri10ge: add multislices support") during conversion to multi-slice. Signed-off-by: Stanislaw Gruszka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 708f2c81c4de7b2660ca4703ba00e541f750b7e4 Author: Patrick McHardy Date: Tue May 26 15:49:11 2009 -0700 vlan/macvlan: fix NULL pointer dereferences in ethtool handlers [ Upstream commit 7816a0a862d851d0b05710e7d94bfe390f3180e2 ] Check whether the underlying device provides a set of ethtool ops before checking for individual handlers to avoid NULL pointer dereferences. Reported-by: Art van Breemen Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54823830733c96b9eda9e82167dcc6f04b8a4ca0 Author: Jay Vosburgh Date: Tue May 26 15:29:00 2009 -0700 bonding: fix alb mode locking regression [ Upstream commit 815bcc2719c12b6f5b511706e2d19728e07f0b02 ] Fix locking issue in alb MAC address management; removed incorrect locking and replaced with correct locking. This bug was introduced in commit 059fe7a578fba5bbb0fdc0365bfcf6218fa25eb0 ("bonding: Convert locks to _bh, rework alb locking for new locking") Bug reported by Paul Smith , who also tested the fix. Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dd6e9d0e69839cba3122a036e77cac5d217100e9 Author: David S. Miller Date: Tue May 26 19:00:54 2009 -0700 sparc64: Reschedule KGDB capture to a software interrupt. [ Upstream commit 42cc77c861e8e850e86252bb5b1e12e006261973 ] Otherwise it might interrupt switch_to() midstream and use half-cooked register window state. Reported-by: Chris Torek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9c0ec2384c31df111f4029eabd7957692c115260 Author: David S. Miller Date: Wed Mar 4 14:43:47 2009 -0800 sparc64: Fix lost interrupts on sun4u. [ Upstream commit d0cac39e4ec8097e4c7099d291b1fdcc0fe56b58 ] Based upon a report by Meelis Roos. Sparc64 SBUS and PCI controllers use a combination of IMAP and ICLR registers to manage device interrupts. The IMAP register contains the "valid" enable bit as well as CPU targetting information. Whereas the ICLR register is written with zero at the end of handling an interrupt to reset the state machine for that interrupt to IDLE so it can be sent again. For PCI slot and SBUS slot devices we can have multiple interrupts sharing the same IMAP register. There are individual ICLR registers but only one IMAP register for managing those. We represent each shared case with individual virtual IRQs so the generic IRQ layer thinks there is only one user of the IRQ instance. In such shared IMAP cases this is wrong, so if there are multiple active users then a free_irq() call will prematurely turn off the interrupt by clearing the Valid bit in the IMAP register even though there are other active users. Fix this by simply doing nothing in sun4u_disable_irq() and checking IRQF_DISABLED during IRQ dispatch. This situation doesn't exist in the hypervisor sun4v cases, so I left those alone. Tested-by: Meelis Roos Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ccfc46013757a25fb2002ede397a2702f50a612e Author: Mikulas Patocka Date: Tue May 26 16:00:12 2009 -0700 sparc64: Fix crash with /proc/iomem [ Upstream commit 192d7a4667c6d11d1a174ec4cad9a3c5d5f9043c ] When you compile kernel on Sparc64 with heap memory checking and type "cat /proc/iomem", you get a crash, because pointers in struct resource are uninitialized. Most code fills struct resource with zeros, so I assume that it is responsibility of the caller of request_resource to initialized it, not the responsibility of request_resource functuion. After 2.6.29 is out, there could be a check for uninitialized fields added to request_resource to avoid crashes like this. Signed-off-by: Mikulas Patocka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ed787bfcb9675350fa78413773a62cb797faf113 Author: David S. Miller Date: Thu Mar 26 01:28:53 2009 -0700 sparc64: Flush TLB before releasing pages. [ Upstream commit 86ee79c3dbd48d7430fd81edc1da3516c9f6dabc ] tlb_flush_mmu() needs to flush pending TLB entries before processing the mmu_gather ->pages list. Noticed by Benjamin Herrenschmidt. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 029b58261163c3d52ebaea882dcfce9e41976c45 Author: David S. Miller Date: Fri Mar 27 01:09:17 2009 -0700 sparc64: Fix MM refcount check in smp_flush_tlb_pending(). [ Upstream commit f9384d41c02408dd404aa64d66d0ef38adcf6479 ] As explained by Benjamin Herrenschmidt: > CPU 0 is running the context, task->mm == task->active_mm == your > context. The CPU is in userspace happily churning things. > > CPU 1 used to run it, not anymore, it's now running fancyfsd which > is a kernel thread, but current->active_mm still points to that > same context. > > Because there's only one "real" user, mm_users is 1 (but mm_count is > elevated, it's just that the presence on CPU 1 as active_mm has no > effect on mm_count(). > > At this point, fancyfsd decides to invalidate a mapping currently mapped > by that context, for example because a networked file has changed > remotely or something like that, using unmap_mapping_ranges(). > > So CPU 1 goes into the zapping code, which eventually ends up calling > flush_tlb_pending(). Your test will succeed, as current->active_mm is > indeed the target mm for the flush, and mm_users is indeed 1. So you > will -not- send an IPI to the other CPU, and CPU 0 will continue happily > accessing the pages that should have been unmapped. To fix this problem, check ->mm instead of ->active_mm, and this means: > So if you test current->mm, you effectively account for mm_users == 1, > so the only way the mm can be active on another processor is as a lazy > mm for a kernel thread. So your test should work properly as long > as you don't have a HW that will do speculative TLB reloads into the > TLB on that other CPU (and even if you do, you flush-on-switch-in should > get rid of any crap here). And therefore we should be OK. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit af32a18ccf468e25545a2c723a8d3ca90531a8a1 Author: David S. Miller Date: Tue May 26 15:56:18 2009 -0700 sparc: Fix bus type probing for ESP and LE devices. If there is a dummy "espdma" or "ledma" parent device above ESP scsi or LE ethernet device nodes, we have to match the bus as SBUS. Otherwise the address and size cell counts are wrong and we don't calculate the final physical device resource values correctly at all. Commit 5280267c1dddb8d413595b87dc406624bb497946 ("sparc: Fix handling of LANCE and ESP parent nodes in of_device.c") was meant to fix this problem, but that only influences the inner loop of build_device_resources(). We need this logic to also kick in at the beginning of build_device_resources() as well, when we make the first attempt to determine the device's immediate parent bus type for 'reg' property element extraction. Based almost entirely upon a patch by Friedrich Oslage. Tested-by: Meelis Roos Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 60962a3513a90e260d975940535ecbcfe5f5b4a4 Author: David S. Miller Date: Wed Apr 8 21:06:35 2009 -0700 sparc64: Fix smp_callin() locking. [ Upstream commit 8e255baa449df3049a8827a7f1f4f12b6921d0d1 ] Interrupts must be disabled when taking the IPI lock. Caught by lockdep. Reported-by: Meelis Roos Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 01683de16233af7676146083f644c823ac5f246d Author: Eric Paris Date: Wed May 13 12:50:40 2009 -0400 TPM: get_event_name stack corruption commit fbaa58696cef848de818768783ef185bd3f05158 upstream. get_event_name uses sprintf to fill a buffer declared on the stack. It fills the buffer 2 bytes at a time. What the code doesn't take into account is that sprintf(buf, "%02x", data) actually writes 3 bytes. 2 bytes for the data and then it nul terminates the string. Since we declare buf to be 40 characters long and then we write 40 bytes of data into buf sprintf is going to write 41 characters. The fix is to leave room in buf for the nul terminator. Signed-off-by: Eric Paris Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 218cadbd4ce2a81d417b6f7b5eb5d5460f221fec Author: Frank Filz Date: Mon May 18 17:41:40 2009 -0400 nfs: Fix NFS v4 client handling of MAY_EXEC in nfs_permission. commit 7ee2cb7f32b299c2b06a31fde155457203e4b7dd upstream. The problem is that permission checking is skipped if atomic open is possible, but when exec opens a file, it just opens it O_READONLY which means EXEC permission will not be checked at that time. This problem is observed by the following sequence (executed as root): mount -t nfs4 server:/ /mnt4 echo "ls" >/mnt4/foo chmod 744 /mnt4/foo su guest -c "mnt4/foo" Signed-off-by: Frank Filz Signed-off-by: Trond Myklebust Tested-by: Eugene Teo Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7357e333ed90064893f5e09c6b2763c2faaf51dd Author: Breno Leitao Date: Fri May 22 21:30:39 2009 -0300 icom: fix rmmod crash commit 95caa0a9bdaf93607bd0cc8932f53112496f2f22 upstream. Actually the icom driver is crashing when is being removed because the driver is kfreeing the adapter structure before calling pci_release_regions(), which result in the following error: Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d33 Faulting instruction address: 0xc000000000246b80 Oops: Kernel access of bad area, sig: 11 [#1] .... [c000000012d436a0] [c0000000001002d0] .kfree+0x120/0x34c (unreliable) [c000000012d43730] [c000000000246d60] .pci_release_selected_regions+0x3c/0x68 [c000000012d437c0] [d000000002d54700] .icom_kref_release+0xf4/0x118 [icom] [c000000012d43850] [c000000000232e50] .kref_put+0x74/0x94 [c000000012d438d0] [d000000002d56c58] .icom_remove+0x40/0xa4 [icom] [c000000012d43960] [c000000000249e48] .pci_device_remove+0x50/0x90 [c000000012d439e0] [c0000000002d68d8] .__device_release_driver+0x94/0xd4 [c000000012d43a70] [c0000000002d7104] .driver_detach+0xf8/0x12c [c000000012d43b00] [c0000000002d549c] .bus_remove_driver+0xbc/0x11c [c000000012d43b90] [c0000000002d71dc] .driver_unregister+0x60/0x80 [c000000012d43c20] [c00000000024a07c] .pci_unregister_driver+0x44/0xe8 [c000000012d43cb0] [d000000002d56bf4] .icom_exit+0x1c/0x40 [icom] [c000000012d43d30] [c000000000095fa8] .SyS_delete_module+0x214/0x2a8 [c000000012d43e30] [c00000000000852c] syscall_exit+0x0/0x40 Signed-off-by: Breno Leitao Cc: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman