Eric Lee / smarc-fsl-linux-kernel

08 May, 2007

1 commit

  • d3cf20947   [XFS] propogate return codes from flush routines ... Browse Code »

    This patch handles error return values in fs_flush_pages and
    fs_flushinval_pages. It changes the prototype of fs_flushinval_pages so we
    can propogate the errors and handle them at higher layers. I also modified
    xfs_itruncate_start so that it could propogate the error further.

    SGI-PV: 961990
    SGI-Modid: xfs-linux-melb:xfs-kern:28231a

    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Stewart Smith
    Signed-off-by: Tim Shimmin

    Lachlan McIlroy
     

09 Jun, 2006

2 commits

17 Mar, 2006

1 commit

09 Jan, 2006

1 commit

  • 28fd12982   [PATCH] Fix and add EXPORT_SYMBOL(filemap_write_and_wait) ... Browse Code »

    This patch add EXPORT_SYMBOL(filemap_write_and_wait) and use it.

    See mm/filemap.c:

    And changes the filemap_write_and_wait() and filemap_write_and_wait_range().

    Current filemap_write_and_wait() doesn't wait if filemap_fdatawrite()
    returns error. However, even if filemap_fdatawrite() returned an
    error, it may have submitted the partially data pages to the device.
    (e.g. in the case of -ENOSPC)

    Andrew Morton writes,

    If filemap_fdatawrite() returns an error, this might be due to some
    I/O problem: dead disk, unplugged cable, etc. Given the generally
    crappy quality of the kernel's handling of such exceptions, there's a
    good chance that the filemap_fdatawait() will get stuck in D state
    forever.

    So, this patch doesn't wait if filemap_fdatawrite() returns the -EIO.

    Trond, could you please review the nfs part? Especially I'm not sure,
    nfs must use the "filemap_fdatawrite(inode->i_mapping) == 0", or not.

    Acked-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

02 Nov, 2005

2 commits

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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