25 Jun, 2011

1 commit

  • Block allocation is called from two places: ext3_get_blocks_handle() and
    ext3_xattr_block_set(). These two callers are not necessarily synchronized
    because xattr code holds only xattr_sem and i_mutex, and
    ext3_get_blocks_handle() may hold only truncate_mutex when called from
    writepage() path. Block reservation code does not expect two concurrent
    allocations to happen to the same inode and thus assertions can be triggered
    or reservation structure corruption can occur.

    Fix the problem by taking truncate_mutex in xattr code to serialize
    allocations.

    CC: Sage Weil
    CC: stable@kernel.org
    Reported-by: Fyodor Ustinov
    Signed-off-by: Jan Kara

    Jan Kara
     

11 Jan, 2011

1 commit


10 Aug, 2010

1 commit

  • The mbcache code was written to support a variable number of indexes,
    but all the existing users use exactly one index. Simplify to code to
    support only that case.

    There are also no users of the cache entry free operation, and none of
    the users keep extra data in cache entries. Remove those features as
    well.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

22 May, 2010

1 commit


05 Mar, 2010

2 commits

  • Get rid of the alloc_space, free_space, reserve_space, claim_space and
    release_rsv dquot operations - they are always called from the filesystem
    and if a filesystem really needs their own (which none currently does)
    it can just call into it's own routine directly.

    Move shared logic into the common __dquot_alloc_space,
    dquot_claim_space_nodirty and __dquot_free_space low-level methods,
    and rationalize the wrappers around it to move as much as possible
    code into the common block for CONFIG_QUOTA vs not. Also rename
    all these helpers to be named dquot_* instead of vfs_dq_*.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jan Kara

    Christoph Hellwig
     
  • At several places we modify EXT3_I(inode)->i_state without holding i_mutex
    (ext3_release_file, ext3_bmap, ext3_journalled_writepage, ext3_do_update_inode,
    ...). These modifications are racy and we can lose updates to i_state. So
    convert handling of i_state to use bitops which are atomic.

    Signed-off-by: Jan Kara

    Jan Kara
     

17 Dec, 2009

1 commit

  • Add a flags argument to struct xattr_handler and pass it to all xattr
    handler methods. This allows using the same methods for multiple
    handlers, e.g. for the ACL methods which perform exactly the same action
    for the access and default ACLs, just using a different underlying
    attribute. With a little more groundwork it'll also allow sharing the
    methods for the regular user/trusted/secure handlers in extN, ocfs2 and
    jffs2 like it's already done for xfs in this patch.

    Also change the inode argument to the handlers to a dentry to allow
    using the handlers mechnism for filesystems that require it later,
    e.g. cifs.

    [with GFS2 bits updated by Steven Whitehouse ]

    Signed-off-by: Christoph Hellwig
    Reviewed-by: James Morris
    Acked-by: Joel Becker
    Signed-off-by: Al Viro

    Christoph Hellwig
     

10 Dec, 2009

1 commit

  • ext3_xattr_set_handle() was zeroing out an inode outside
    of journaling constraints; this is one of the accesses that
    was causing the crc errors in journal replay as seen in
    kernel.org bugzilla #14354.

    Although ext3 doesn't have the crc issue, modifications
    out of journal control are a Bad Thing.

    Signed-off-by: Eric Sandeen
    Signed-off-by: Jan Kara

    Eric Sandeen
     

12 Jun, 2009

1 commit


26 Mar, 2009

1 commit


15 May, 2008

1 commit

  • This fix the uninitialized bs when we try to replace a xattr entry in
    ibody with the new value which require more than free space.

    This situation only happens we format ext3/4 with inode size more than 128 and
    we have put xattr entries both in ibody and block. The consequences about
    this bug is we will lost the xattr block which pointed by i_file_acl with all
    xattr entires in it. We will alloc a new xattr block and put that large value
    entry in it. The old xattr block will become orphan block.

    Signed-off-by: Tiger Yang
    Cc:
    Cc: Andreas Gruenbacher
    Acked-by: Andreas Dilger
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tiger Yang
     

28 Apr, 2008

3 commits


16 Apr, 2008

1 commit

  • mb_cache_entry_alloc() was allocating cache entries with GFP_KERNEL. But
    filesystems are calling this function while holding xattr_sem so possible
    recursion into the fs violates locking ordering of xattr_sem and transaction
    start / i_mutex for ext2-4. Change mb_cache_entry_alloc() so that filesystems
    can specify desired gfp mask and use GFP_NOFS from all of them.

    Signed-off-by: Jan Kara
    Reported-by: Dave Jones
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

20 Mar, 2008

1 commit

  • There are several places where we make allocations with GFP_KERNEL while under
    a transaction, which could lead to an assertion panic or lockup if under
    memory pressure. This patch switches these problem areas to use GFP_NOFS to
    keep these problems from happening.

    Signed-off-by: Josef Bacik
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef Bacik
     

09 Feb, 2008

1 commit

  • replace all:
    little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
    expression_in_cpu_byteorder);
    with:
    leX_add_cpu(&little_endian_variable, expression_in_cpu_byteorder);
    sparse didn't generate any new warning with this patch

    Signed-off-by: Marcin Slusarz
    Cc: Mark Fasheh
    Cc: David Chinner
    Cc: Timothy Shimmin
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marcin Slusarz
     

20 Oct, 2007

1 commit


24 Mar, 2007

1 commit


02 Mar, 2007

1 commit

  • There are race issues around ext[34] xattr block release code.

    ext[34]_xattr_release_block() checks the reference count of xattr block
    (h_refcount) and frees that xattr block if it is the last one reference it.
    Unlike ext2, the check of this counter is unprotected by any lock.
    ext[34]_xattr_release_block() will free the mb_cache entry before freeing
    that xattr block. There is a small window between the check for the re
    h_refcount ==1 and the call to mb_cache_entry_free(). During this small
    window another inode might find this xattr block from the mbcache and reuse
    it, racing a refcount updates. The xattr block will later be freed by the
    first inode without notice other inode is still use it. Later if that
    block is reallocated as a datablock for other file, then more serious
    problem might happen.

    We need put a lock around places checking the refount as well to avoid
    racing issue. Another place need this kind of protection is in
    ext3_xattr_block_set(), where it will modify the xattr block content in-
    the-fly if the refcount is 1 (means it's the only inode reference it).

    This will also fix another issue: the xattr block may not get freed at all
    if no lock is to protect the refcount check at the release time. It is
    possible that the last two inodes could release the shared xattr block at
    the same time. But both of them think they are not the last one so only
    decreased the h_refcount without freeing xattr block at all.

    We need to call lock_buffer() after ext3_journal_get_write_access() to
    avoid deadlock (because the later will call lock_buffer()/unlock_buffer
    () as well).

    Signed-off-by: Mingming Cao
    Cc: Andreas Gruenbacher
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mingming Cao
     

08 Dec, 2006

1 commit


27 Sep, 2006

1 commit

  • This is primarily format string fixes, with changes to ialloc.c where large
    inode counts could overflow, and also pass around journal_inum as an
    unsigned long, just to be pedantic about it....

    Signed-off-by: Eric Sandeen
    Cc: Mingming Cao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sandeen
     

26 Jun, 2006

2 commits

  • Convert the ext3 in-kernel filesystem blocks to ext3_fsblk_t. Convert the
    rest of all unsigned long type in-kernel filesystem blocks to ext3_fsblk_t,
    and replace the printk format string respondingly.

    Signed-off-by: Mingming Cao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mingming Cao
     
  • Some of the in-kernel ext3 block variable type are treated as signed 4 bytes
    int type, thus limited ext3 filesystem to 8TB (4kblock size based). While
    trying to fix them, it seems quite confusing in the ext3 code where some
    blocks are filesystem-wide blocks, some are group relative offsets that need
    to be signed value (as -1 has special meaning). So it seem saner to define
    two types of physical blocks: one is filesystem wide blocks, another is
    group-relative blocks. The following patches clarify these two types of
    blocks in the ext3 code, and fix the type bugs which limit current 32 bit ext3
    filesystem limit to 8TB.

    With this series of patches and the percpu counter data type changes in the mm
    tree, we are able to extend exts filesystem limit to 16TB.

    This work is also a pre-request for the recent >32 bit ext3 work, and makes
    the kernel to able to address 48 bit ext3 block a lot easier: Simply redefine
    ext3_fsblk_t from unsigned long to sector_t and redefine the format string for
    ext3 filesystem block corresponding.

    Two RFC with a series patches have been posted to ext2-devel list and have
    been reviewed and discussed:
    http://marc.theaimsgroup.com/?l=ext2-devel&m=114722190816690&w=2

    http://marc.theaimsgroup.com/?l=ext2-devel&m=114784919525942&w=2

    Patches are tested on both 32 bit machine and 64 bit machine, 8TB ext3 filesystem(with the latest to be released e2fsprogs-1.39). Tests
    includes overnight fsx, tiobench, dbench and fsstress.

    This patch:

    Defines ext3_fsblk_t and ext3_grpblk_t, and the printk format string for
    filesystem wide blocks.

    This patch classifies all block group relative blocks, and ext3_fsblk_t blocks
    occurs in the same function where used to be confusing before. Also include
    kernel bug fixes for filesystem wide in-kernel block variables. There are
    some fileystem wide blocks are treated as int/unsigned int type in the kernel
    currently, especially in ext3 block allocation and reservation code. This
    patch fixed those bugs by converting those variables to ext3_fsblk_t(unsigned
    long) type.

    Signed-off-by: Mingming Cao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mingming Cao
     

11 Jan, 2006

1 commit


10 Jan, 2006

1 commit


31 Oct, 2005

1 commit

  • Fix warnings from sparse due to un-declared functions that should either
    have a header file or have been declared static

    fs/ext2/bitmap.c:14:15: warning: symbol 'ext2_count_free' was not declared. Should it be static?
    fs/ext2/namei.c:92:15: warning: symbol 'ext2_get_parent' was not declared. Should it be static?
    fs/ext3/bitmap.c:15:15: warning: symbol 'ext3_count_free' was not declared. Should it be static?
    fs/ext3/namei.c:1013:15: warning: symbol 'ext3_get_parent' was not declared. Should it be static?
    fs/ext3/xattr.c:214:1: warning: symbol 'ext3_xattr_block_get' was not declared. Should it be static?
    fs/ext3/xattr.c:358:1: warning: symbol 'ext3_xattr_block_list' was not declared. Should it be static?
    fs/ext3/xattr.c:630:1: warning: symbol 'ext3_xattr_block_find' was not declared. Should it be static?
    fs/ext3/xattr.c:863:1: warning: symbol 'ext3_xattr_ibody_find' was not declared. Should it be static?

    Signed-off-by: Ben Dooks
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ben Dooks
     

28 Jul, 2005

1 commit


24 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds