Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jun 12, 2009
  1. @gregkh

    Linux 2.6.27.25

    gregkh authored
  2. @tytso @gregkh

    ext4: Fix race in ext4_inode_info.i_cached_extent

    tytso authored gregkh committed
    (cherry picked from commit 2ec0ae3)
    
    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" <tytso@mit.edu>
    Reviewed-by: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @kvaneesh @gregkh

    ext4: Clear the unwritten buffer_head flag after the extent is initia…

    kvaneesh authored gregkh committed
    …lized
    
    (cherry picked from commit 2a8964d)
    
    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 <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @kvaneesh @gregkh

    ext4: Use a fake block number for delayed new buffer_head

    kvaneesh authored gregkh committed
    (cherry picked from commit 33b9817)
    
    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 <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @kvaneesh @gregkh

    ext4: Fix sub-block zeroing for writes into preallocated extents

    kvaneesh authored gregkh committed
    (cherry picked from commit 9c1ee18)
    
    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 <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @tytso @gregkh

    ext4: Ignore i_file_acl_high unless EXT4_FEATURE_INCOMPAT_64BIT is pr…

    tytso authored gregkh committed
    …esent
    
    (cherry picked from commit a9e8174)
    
    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" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @tytso @gregkh

    ext4: Fix softlockup caused by illegal i_file_acl value in on-disk inode

    tytso authored gregkh committed
    (cherry picked from commit 485c26e)
    
    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" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    ext4: really print the find_group_flex fallback warning only once

    Chuck Ebbert authored gregkh committed
    (cherry picked from commit 6b82f3c)
    
    Missing braces caused the warning to print more than once.
    
    Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @tytso @gregkh

    ext4: fix locking typo in mballoc which could cause soft lockup hangs

    tytso authored gregkh committed
    upstream commit: e7c9e3e
    
    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 <error27@gmail.com>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @error27 @gregkh

    ext4: fix typo which causes a memory leak on error path

    error27 authored gregkh committed
    upstream commit: a7b1944
    
    This was found by smatch (http://repo.or.cz/w/smatch.git/)
    
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @jankara @gregkh

    jbd2: Update locking coments

    jankara authored gregkh committed
    (cherry picked from commit 86db97c)
    
    Update information about locking in JBD2 revoke code. Inconsistency in
    comments found by Lin Tan <tammy000@gmail.com>
    
    CC: Lin Tan <tammy000@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @tytso @gregkh

    ext4: Check for an valid i_mode when reading the inode from disk

    tytso authored gregkh committed
    (cherry picked from commit 563bdd6)
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @kvaneesh @gregkh

    ext4: Fix discard of inode prealloc space with delayed allocation.

    kvaneesh authored gregkh committed
    (cherry picked from commit d601430)
    
    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 <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @tytso @gregkh

    ext4: Automatically allocate delay allocated blocks on rename

    tytso authored gregkh committed
    (cherry picked from commit 8750c6d)
    
    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" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @tytso @gregkh

    ext4: Automatically allocate delay allocated blocks on close

    tytso authored gregkh committed
    (cherry picked from commit 7d8f9f7)
    
    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" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @tytso @gregkh

    ext4: add EXT4_IOC_ALLOC_DA_BLKS ioctl

    tytso authored gregkh committed
    (cherry picked from commit ccd2506)
    
    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" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @tytso @gregkh

    ext4: Add fine print for the 32000 subdirectory limit

    tytso authored gregkh committed
    (cherry picked from commit 722bde6)
    
    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" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @bdonlan @gregkh

    ext4: return -EIO not -ESTALE on directory traversal through deleted …

    bdonlan authored gregkh committed
    …inode
    
    (cherry picked from commit e6f009b)
    
    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 <bdonlan@gmail.com>
    Cc: <linux-ext4@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @duaneg @gregkh

    ext4: tighten restrictions on inode flags

    duaneg authored gregkh committed
    (cherry picked from commit 2dc6b0d)
    
    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 <duaneg@dghda.com>
    Acked-by: Andreas Dilger <adilger@sun.com>
    Cc: <linux-ext4@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @duaneg @gregkh

    ext4: don't inherit inappropriate inode flags from parent

    duaneg authored gregkh committed
    (cherry picked from commit 8fa43a8)
    
    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 <duaneg@dghda.com>
    Acked-by: Andreas Dilger <adilger@sun.com>
    Cc: <linux-ext4@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    ext4: fix bb_prealloc_list corruption due to wrong group locking

    Eric Sandeen authored gregkh committed
    (cherry-picked from commit d33a197)
    
    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 <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    ext4: fix bogus BUG_ONs in in mballoc code

    Eric Sandeen authored gregkh committed
    (cherry picked from commit 8d03c7a)
    
    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 <thiemo.nagel@ph.tum.de>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @tytso @gregkh

    ext4: Print the find_group_flex() warning only once

    tytso authored gregkh committed
    (cherry picked from commit 2842c3b)
    
    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" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    ext4: fix header check in ext4_ext_search_right() for deep extent trees.

    Eric Sandeen authored gregkh committed
    (cherry picked from commit 395a87b)
    
    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 <ddi@dubex.dk>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    ext4: fix ext4_free_inode() vs. ext4_claim_inode() race

    Eric Sandeen authored gregkh committed
    (cherry picked from commit 7ce9d5d)
    
    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
    3934186 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 <sandeen@redhat.com>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @jirislaby @gregkh

    mac80211: pid, fix memory corruption

    jirislaby authored gregkh committed
    commit a865959 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 <jirislaby@gmail.com>
    Cc: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    x86: fix DMI on EFI

    Brian Maly authored gregkh committed
    commit ff0c087 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 <bmaly@redhat>
    Acked-by: Yinghai Lu <yinghai@kernel.org>
    Cc: ying.huang@intel.com
    LKML-Reference: <49ADEDA3.1030406@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @gregkh

    V4L/DVB (10943): cx88: Prevent general protection fault on rmmod

    Jean Delvare authored gregkh committed
    commit 569b7ec 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 <khali@linux-fr.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @gregkh

    x86/pci: fix mmconfig detection with 32bit near 4g

    Yinghai Lu authored gregkh committed
    commit 75e613c 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 <pterjan@mandriva.com>
    Bisected-by: Pascal Terjan <pterjan@mandriva.com>
    Tested-by: Pascal Terjan <pterjan@mandriva.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gormanm @gregkh

    x86: ignore VM_LOCKED when determining if hugetlb-backed page tables …

    gormanm authored gregkh committed
    …can be shared or not
    
    commit 32b154c 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 <mel@csn.ul.ie>
    Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: <starlight@binnacle.cx>
    Cc: Eric B Munson <ebmunson@us.ibm.com>
    Cc: Adam Litke <agl@us.ibm.com>
    Cc: Andy Whitcroft <apw@canonical.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>
  31. @gregkh

    USB: isp1760: urb_dequeue doesn't always find the urbs

    Warren Free authored gregkh committed
    commit 0afb20e 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 <wfree@ipmn.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @cladisch @gregkh

    sound: usb-audio: make the MotU Fastlane work again

    cladisch authored gregkh committed
    commit 55de5ef 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 <clemens@ladisch.de>
    Reported-and-tested-by: David Fries <david@fries.net>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @eparis @gregkh

    SELinux: BUG in SELinux compat_net code

    eparis authored gregkh committed
    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 effad8d
    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 <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @torvalds @gregkh

    Avoid ICE in get_random_int() with gcc-3.4.5

    torvalds authored gregkh committed
    commit 26a9a41 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 <spamtrap@knobisoft.de>
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @torvalds @gregkh

    random: make get_random_int() more random

    torvalds authored gregkh committed
    commit 8a0a9bd 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 <mingo@elte.hu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jake Edge <jake@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.