17 May, 2007

1 commit

  • SLAB_CTOR_CONSTRUCTOR is always specified. No point in checking it.

    Signed-off-by: Christoph Lameter
    Cc: David Howells
    Cc: Jens Axboe
    Cc: Steven French
    Cc: Michael Halcrow
    Cc: OGAWA Hirofumi
    Cc: Miklos Szeredi
    Cc: Steven Whitehouse
    Cc: Roman Zippel
    Cc: David Woodhouse
    Cc: Dave Kleikamp
    Cc: Trond Myklebust
    Cc: "J. Bruce Fields"
    Cc: Anton Altaparmakov
    Cc: Mark Fasheh
    Cc: Paul Mackerras
    Cc: Christoph Hellwig
    Cc: Jan Kara
    Cc: David Chinner
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

10 May, 2007

1 commit


09 May, 2007

4 commits

  • A patch that stores inode flags such as S_IMMUTABLE, S_APPEND, etc. from
    i_flags to EXT3_I(inode)->i_flags when inode is written to disk. The same
    thing is done on GETFLAGS ioctl.

    Quota code changes these flags on quota files (to make it harder for
    sysadmin to screw himself) and these changes were not correctly propagated
    into the filesystem (especially, lsattr did not show them and users were
    wondering...).

    Propagate flags such as S_APPEND, S_IMMUTABLE, etc. from i_flags into
    ext3-specific i_flags. Hence, when someone sets these flags via a
    different interface than ioctl, they are stored correctly.

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

    Jan Kara
     
  • Remove includes of where it is not used/needed.
    Suggested by Al Viro.

    Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
    sparc64, and arm (all 59 defconfigs).

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • - ext3_dx_find_entry() exit with out setting proper error pointer

    - do_split() exit with out setting proper error pointer
    it is realy painful because many callers contain folowing code:

    de = do_split(handle,dir, &bh, frame, &hinfo, &retval);
    if (!(de))
    return retval;
    <<< WOW retval wasn't changed by do_split(), so caller failed
    <<< but return SUCCESS :)

    - Rearrange do_split() error path. Current error path is realy ugly, all
    this up and down jump stuff doesn't make code easy to understand.

    [dmonakhov@sw.ru: fix annoying fake error messages]
    Signed-off-by: Monakhov Dmitriy
    Cc: Andreas Dilger
    Cc: Theodore Ts'o
    Signed-off-by: Monakhov Dmitriy
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dmitriy Monakhov
     
  • Taken from http://bugzilla.kernel.org/show_bug.cgi?id=5079

    signed long ranges from -2.147.483.648 to 2.147.483.647 on x86 32bit

    10000011110110100100111110111101 .. -2,082,844,739
    10000011110110100100111110111101 .. 2,212,122,557
    Cc:

    Andreas says:

    This patch is now treating timestamps with the high bit set as negative
    times (before Jan 1, 1970). This means we lose 1/2 of the possible range
    of timestamps (lopping off 68 years before unix timestamp overflow -
    now only 30 years away :-) to handle the extremely rare case of setting
    timestamps into the distant past.

    If we are only interested in fixing the underflow case, we could just
    limit the values to 0 instead of storing negative values. At worst this
    will skew the timestamp by a few hours for timezones in the far east
    (files would still show Jan 1, 1970 in "ls -l" output).

    That said, it seems 32-bit systems (mine at least) allow files to be set
    into the past (01/01/1907 works fine) so it seems this patch is bringing
    the x86_64 behaviour into sync with other kernels.

    On the plus side, we have a patch that is ready to add nanosecond timestamps
    to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
    this extends the maximum date to 2242.

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

    Markus Rechberger
     

08 May, 2007

2 commits

  • I have never seen a use of SLAB_DEBUG_INITIAL. It is only supported by
    SLAB.

    I think its purpose was to have a callback after an object has been freed
    to verify that the state is the constructor state again? The callback is
    performed before each freeing of an object.

    I would think that it is much easier to check the object state manually
    before the free. That also places the check near the code object
    manipulation of the object.

    Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was
    compiled with SLAB debugging on. If there would be code in a constructor
    handling SLAB_DEBUG_INITIAL then it would have to be conditional on
    SLAB_DEBUG otherwise it would just be dead code. But there is no such code
    in the kernel. I think SLUB_DEBUG_INITIAL is too problematic to make real
    use of, difficult to understand and there are easier ways to accomplish the
    same effect (i.e. add debug code before kfree).

    There is a related flag SLAB_CTOR_VERIFY that is frequently checked to be
    clear in fs inode caches. Remove the pointless checks (they would even be
    pointless without removeal of SLAB_DEBUG_INITIAL) from the fs constructors.

    This is the last slab flag that SLUB did not support. Remove the check for
    unimplemented flags from SLUB.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • Remove the destroy_dirty_buffers argument from invalidate_bdev(), it hasn't
    been used in 6 years (so akpm says).

    find * -name \*.[ch] | xargs grep -l invalidate_bdev |
    while read file; do
    quilt add $file;
    sed -ie 's/invalidate_bdev(\([^,]*\),[^)]*)/invalidate_bdev(\1)/g' $file;
    done

    Signed-off-by: Peter Zijlstra
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Zijlstra
     

03 Apr, 2007

1 commit

  • Revert e92a4d595b464c4aae64be39ca61a9ffe9c8b278.

    Dmitry points out

    "When we block_prepare_write() failed while ext3_prepare_write() we jump to
    "failure" label and call ext3_prepare_failure() witch search last mapped bh
    and invoke commit_write untill it. This is wrong!! because some bh from
    begining to the last mapped bh may be not uptodate. As a result we commit to
    disk not uptodate page content witch contains garbage from previous usage."

    and

    "Unexpected file size increasing."

    Call trace the same as it was in first issue but result is different.
    For example we have file with i_size is zero. we want write two blocks ,
    but fs has only one free block.

    ->ext3_prepare_write(...from == 0, to == 2048)
    retry:
    ->block_prepare_write() == -ENOSPC# we failed but allocated one block here.
    ->ext3_prepare_failure()
    ->commit_write( from == 0, to == 1024) # after this i_size becomes 1024 :)
    if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries))
    goto retry;

    Finally when all retries will be spended ext3_prepare_failure return
    -ENOSPC, but i_size was increased and later block trimm procedures can't
    help here.

    We don't appear to have the horsepower to fix these issues, so let's put
    things back the way they were for now.

    Cc: Kirill Korotaev
    Cc: Ingo Molnar
    Cc: Ken Chen
    Cc: Andrey Savochkin
    Cc:
    Cc: Dmitriy Monakhov
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

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
     

21 Feb, 2007

1 commit


15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

13 Feb, 2007

2 commits

  • This patch is inspired by Arjan's "Patch series to mark struct
    file_operations and struct inode_operations const".

    Compile tested with gcc & sparse.

    Signed-off-by: Josef 'Jeff' Sipek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef 'Jeff' Sipek
     
  • Many struct inode_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

12 Feb, 2007

5 commits

  • jbd function called instead of fs specific one.

    Signed-off-by: Dmitriy Monakhov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dmitriy Monakhov
     
  • - Naming is confusing, ext3_inc_count manipulates i_nlink not i_count
    - handle argument passed in is not used
    - ext3 and ext4 already call inc_nlink and dec_nlink directly in other places

    Signed-off-by: Eric Sandeen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sandeen
     
  • Return -ENOENT from ext[34]_link if we've raced with unlink and i_nlink is
    0. Doing otherwise has the potential to corrupt the orphan inode list,
    because we'd wind up with an inode with a non-zero link count on the list,
    and it will never get properly cleaned up & removed from the orphan list
    before it is freed.

    [akpm@osdl.org: build fix]
    Signed-off-by: Eric Sandeen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sandeen
     
  • Fix insecure default behaviour reported by Tigran Aivazian: if an ext2 or
    ext3 or ext4 filesystem is tuned to mount with "acl", but mounted by a
    kernel built without ACL support, then umask was ignored when creating
    inodes - though root or user has umask 022, touch creates files as 0666,
    and mkdir creates directories as 0777.

    This appears to have worked right until 2.6.11, when a fix to the default
    mode on symlinks (always 0777) assumed VFS applies umask: which it does,
    unless the mount is marked for ACLs; but ext[234] set MS_POSIXACL in
    s_flags according to s_mount_opt set according to def_mount_opts.

    We could revert to the 2.6.10 ext[234]_init_acl (adding an S_ISLNK test);
    but other filesystems only set MS_POSIXACL when ACLs are configured. We
    could fix this at another level; but it seems most robust to avoid setting
    the s_mount_opt flag in the first place (at the expense of more ifdefs).

    Likewise don't set the XATTR_USER flag when built without XATTR support.

    Signed-off-by: Hugh Dickins
    Cc: Tigran Aivazian
    Cc:
    Cc: Andreas Gruenbacher
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • In the rare case where we have skipped orphan inode processing due to a
    readonly block device, and the block device subsequently changes back to
    read-write, disallow a remount,rw transition of the filesystem when we have an
    unprocessed orphan inodes as this would corrupt the list.

    Ideally we should process the orphan inode list during the remount, but that's
    trickier, and this plugs the hole for now.

    Signed-off-by: Eric Sandeen
    Cc: "Stephen C. Tweedie"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sandeen
     

09 Dec, 2006

2 commits

  • This facility provides three entry points:

    ilog2() Log base 2 of unsigned long
    ilog2_u32() Log base 2 of u32
    ilog2_u64() Log base 2 of u64

    These facilities can either be used inside functions on dynamic data:

    int do_something(long q)
    {
    ...;
    y = ilog2(x)
    ...;
    }

    Or can be used to statically initialise global variables with constant values:

    unsigned n = ilog2(27);

    When performing static initialisation, the compiler will report "error:
    initializer element is not constant" if asked to take a log of zero or of
    something not reducible to a constant. They treat negative numbers as
    unsigned.

    When not dealing with a constant, they fall back to using fls() which permits
    them to use arch-specific log calculation instructions - such as BSR on
    x86/x86_64 or SCAN on FRV - if available.

    [akpm@osdl.org: MMC fix]
    Signed-off-by: David Howells
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Herbert Xu
    Cc: David Howells
    Cc: Wojtek Kaniewski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • Change all the uses of f_{dentry,vfsmnt} to f_path.{dentry,mnt} in the ext3
    filesystem.

    Signed-off-by: Josef "Jeff" Sipek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef "Jeff" Sipek
     

08 Dec, 2006

15 commits

  • Port fix to the off-by-one in find_next_usable_block's memscan from ext2 to
    ext3; but it didn't cause a serious problem for ext3 because the additional
    ext3_test_allocatable check rescued it from the error.

    Signed-off-by: Mingming Cao
    Signed-off-by: Hugh Dickins
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • ext3_new_blocks has a nice io_error label for setting -EIO, so goto that in
    the one place that doesn't already use it.

    Signed-off-by: Mingming Cao
    Signed-off-by: Hugh Dickins
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • The reservations tree is an rb_tree not a list, so it's less confusing to use
    rb_entry() than list_entry() - though they're both just container_of().

    Signed-off-by: Mingming Cao
    Signed-off-by: Hugh Dickins
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • rsv_end is the last block within the reservation, so alloc_new_reservation
    should accept start_block == rsv_end as success.

    Signed-off-by: Mingming Cao
    Signed-off-by: Hugh Dickins
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • grp_goal 0 is a genuine goal (unlike -1), so ext3_try_to_allocate_with_rsv
    should treat it as such.

    Signed-off-by: Mingming Cao
    Signed-off-by: Hugh Dickins
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • ext3_new_blocks should reset the reservation window size to 0 when squeezing
    the last blocks out of an almost full filesystem, so the retry doesn't skip
    any groups with less than half that free, reporting ENOSPC too soon.

    Signed-off-by: Mingming Cao
    Signed-off-by: Hugh Dickins
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • If you do something like:

    # touch foo
    # tail -f foo &
    # rm foo
    #
    #

    you'll panic, because ext3/4 tries to do orphan list processing on the
    readonly snapshot device, and:

    kernel: journal commit I/O error
    kernel: Assertion failure in journal_flush_Rsmp_e2f189ce() at journal.c:1356: "!journal->j_checkpoint_transactions"
    kernel: Kernel panic: Fatal exception

    for a truly readonly underlying device, it's reasonable and necessary
    to just skip orphan list processing.

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

    Eric Sandeen
     
  • Hugh Dickins wrote:
    > Not found anything relevant, but I keep noticing these lines
    > in ext2_try_to_allocate_with_rsv(), ext3 and ext4 similar:
    >
    > } else if (grp_goal > 0 &&
    > (my_rsv->rsv_end - grp_goal + 1) < *count)
    > try_to_extend_reservation(my_rsv, sb,
    > *count-my_rsv->rsv_end + grp_goal - 1);
    >
    > They're wrong, a no-op in most groups, aren't they? rsv_end is an
    > absolute block number, whereas grp_goal is group-relative, so the
    > calculation ought to bring in group_first_block? Or I'm confused.
    >

    Signed-off-by: Mingming Cao
    Cc: "linux-ext4@vger.kernel.org"
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mingming Cao
     
  • In journal=ordered or journal=data mode retry in ext3_prepare_write()
    breaks the requirements of journaling of data with respect to metadata.
    The fix is to call commit_write to commit allocated zero blocks before
    retry.

    Signed-off-by: Kirill Korotaev
    Cc: Ingo Molnar
    Cc: Ken Chen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrey Savochkin
     
  • Saves nearly 4kbytes on x86.

    Cc: Arnaldo Carvalho de Melo
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
    http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz

    Basically it makes a filesystem, splats some random bits over it, then
    tries to mount it and do some simple filesystem actions.

    At best, the filesystem catches the corruption gracefully. At worst,
    things spin out of control.

    As you might guess, we found a couple places in ext3 where things spin out
    of control :)

    First, we had a corrupted directory that was never checked for
    consistency... it was corrupt, and pointed to another bad "entry" of
    length 0. The for() loop looped forever, since the length of
    ext3_next_entry(de) was 0, and we kept looking at the same pointer over and
    over and over and over... I modeled this check and subsequent action on
    what is done for other directory types in ext3_readdir...

    (adding this check adds some computational expense; I am testing a followup
    patch to reduce the number of times we check and re-check these directory
    entries, in all cases. Thanks for the idea, Andreas).

    Next we had a root directory inode which had a corrupted size, claimed to
    be > 200M on a 4M filesystem. There was only really 1 block in the
    directory, but because the size was so large, readdir kept coming back for
    more, spewing thousands of printk's along the way.

    Per Andreas' suggestion, if we're in this read error condition and we're
    trying to read an offset which is greater than i_blocks worth of bytes,
    stop trying, and break out of the loop.

    With these two changes fsfuzz test survives quite well on ext3.

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

    Eric Sandeen
     
  • lock_super() is unnecessary for setting super-block feature flags. Use the
    provided *_SET_COMPAT_FEATURE() macros as well.

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

    Andreas Gruenbacher
     
  • Update ext3_statfs to return an FSID that is a 64 bit XOR of the 128 bit
    filesystem UUID as suggested by Andreas Dilger. See the following Bugzilla
    entry for details:

    http://bugzilla.kernel.org/show_bug.cgi?id=136

    Cc: Andreas Dilger
    Cc: Stephen Tweedie
    Signed-off-by: Pekka Enberg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pekka Enberg
     
  • Replace all uses of kmem_cache_t with struct kmem_cache.

    The patch was generated using the following script:

    #!/bin/sh
    #
    # Replace one string by another in all the kernel sources.
    #

    set -e

    for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
    quilt add $file
    sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
    mv /tmp/$$ $file
    quilt refresh
    done

    The script was run like this

    sh replace kmem_cache_t "struct kmem_cache"

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • SLAB_NOFS is an alias of GFP_NOFS.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

12 Oct, 2006

1 commit

  • Current error behaviour for ext2 and ext3 filesystems does not fully
    correspond to the documentation and should be fixed.

    According to man 8 mount, ext2 and ext3 file systems allow to set one of 3
    different on-errors behaviours:

    ---- start of quote man 8 mount ----

    errors=continue / errors=remount-ro / errors=panic

    Define the behaviour when an error is encountered. (Either ignore
    errors and just mark the file system erroneous and continue, or remount
    the file system read-only, or panic and halt the system.) The default is
    set in the filesystem superblock, and can be changed using tune2fs(8).

    ---- end of quote ----

    However EXT3_ERRORS_CONTINUE is not read from the superblock, and thus
    ERRORS_CONT is not saved on the sbi->s_mount_opt. It leads to the incorrect
    handle of errors on ext3.

    Then we've checked corresponding code in ext2 and discovered that it is buggy
    as well:

    - EXT2_ERRORS_CONTINUE is not read from the superblock (the same);

    - parse_option() does not clean the alternative values and thus something
    like (ERRORS_CONT|ERRORS_RO) can be set;

    - if options are omitted, parse_option() does not set any of these options.

    Therefore it is possible to set any combination of these options on the ext2:

    - none of them may be set: EXT2_ERRORS_CONTINUE on superblock / empty mount
    options;

    - any of them may be set using mount options;

    - 2 any options may be set: by using EXT2_ERRORS_RO/EXT2_ERRORS_PANIC on the
    superblock and other value in mount options;

    - and finally all three options may be set by adding third option in remount.

    Currently ext2 uses these values only in ext2_error() and it is not leading to
    any noticeable troubles. However somebody may be discouraged when he will try
    to workaround EXT2_ERRORS_PANIC on the superblock by using errors=continue in
    mount options.

    This patch:

    EXT3_ERRORS_CONTINUE should be taken from the superblock as default value for
    error behaviour.

    Signed-off-by: Dmitry Mishin
    Acked-by: Vasily Averin
    Acked-by: Kirill Korotaev
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dmitry Mishin
     

01 Oct, 2006

2 commits