Eric Lee / smarc-fsl-linux-kernel

01 Oct, 2006

1 commit

23 Jun, 2006

1 commit

  • 111ebb6e6   [PATCH] writeback: fix range handling ... Browse Code »

    When a writeback_control's `start' and `end' fields are used to
    indicate a one-byte-range starting at file offset zero, the required
    values of .start=0,.end=0 mean that the ->writepages() implementation
    has no way of telling that it is being asked to perform a range
    request. Because we're currently overloading (start == 0 && end == 0)
    to mean "this is not a write-a-range request".

    To make all this sane, the patch changes range of writeback_control.

    So caller does: If it is calling ->writepages() to write pages, it
    sets range (range_start/end or range_cyclic) always.

    And if range_cyclic is true, ->writepages() thinks the range is
    cyclic, otherwise it just uses range_start and range_end.

    This patch does,

    - Add LLONG_MAX, LLONG_MIN, ULLONG_MAX to include/linux/kernel.h
    -1 is usually ok for range_end (type is long long). But, if someone did,

    range_end += val; range_end is "val - 1"
    u64val = range_end >> bits; u64val is "~(0ULL)"

    or something, they are wrong. So, this adds LLONG_MAX to avoid nasty
    things, and uses LLONG_MAX for range_end.

    - All callers of ->writepages() sets range_start/end or range_cyclic.

    - Fix updates of ->writeback_index. It seems already bit strange.
    If it starts at 0 and ended by check of nr_to_write, this last
    index may reduce chance to scan end of file. So, this updates
    ->writeback_index only if range_cyclic is true or whole-file is
    scanned.

    Signed-off-by: OGAWA Hirofumi
    Cc: Nathan Scott
    Cc: Anton Altaparmakov
    Cc: Steven French
    Cc: "Vladimir V. Saveliev"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

27 Mar, 2006

2 commits

  • fa30bd058   [PATCH] map multiple blocks for mpage_readpages() ... Browse Code »

    This patch changes mpage_readpages() and get_block() to get the disk mapping
    information for multiple blocks at the same time.

    b_size represents the amount of disk mapping that needs to mapped. On the
    successful get_block() b_size indicates the amount of disk mapping thats
    actually mapped. Only the filesystems who care to use this information and
    provide multiple disk blocks at a time can choose to do so.

    No changes are needed for the filesystems who wants to ignore this.

    [akpm@osdl.org: cleanups]
    Signed-off-by: Badari Pulavarty
    Cc: Mingming Cao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Badari Pulavarty
     
  • b0cf2321c   [PATCH] pass b_size to ->get_block() ... Browse Code »

    Pass amount of disk needs to be mapped to get_block(). This way one can
    modify the fs ->get_block() functions to map multiple blocks at the same time.

    [akpm@osdl.org: performance tweak]
    [akpm@osdl.org: remove unneeded assignments]
    Signed-off-by: Badari Pulavarty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Badari Pulavarty
     

09 Jan, 2006

1 commit

  • 54b21a799   [PATCH] fix possible PAGE_CACHE_SHIFT overflows ... Browse Code »

    We've had two instances recently of overflows when doing

    64_bit_value = (32_bit_value << PAGE_CACHE_SHIFT)

    I did a tree-wide grep of `<page_base)

    Cc: Oleg Drokin
    Cc: David Howells
    Cc: David Woodhouse
    Cc:
    Cc: Christoph Hellwig
    Cc: Anton Altaparmakov
    Cc: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Cc: Roman Zippel
    Cc:
    Cc: Miklos Szeredi
    Cc: Russell King
    Cc: Trond Myklebust
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

04 Jan, 2006

1 commit

  • 994fc28c7   [PATCH] add AOP_TRUNCATED_PAGE, prepend AOP_ to WRITEPAGE_ACTIVATE ... Browse Code »

    readpage(), prepare_write(), and commit_write() callers are updated to
    understand the special return code AOP_TRUNCATED_PAGE in the style of
    writepage() and WRITEPAGE_ACTIVATE. AOP_TRUNCATED_PAGE tells the caller that
    the callee has unlocked the page and that the operation should be tried again
    with a new page. OCFS2 uses this to detect and work around a lock inversion in
    its aop methods. There should be no change in behaviour for methods that don't
    return AOP_TRUNCATED_PAGE.

    WRITEPAGE_ACTIVATE is also prepended with AOP_ for consistency and they are
    made enums so that kerneldoc can be used to document their semantics.

    Signed-off-by: Zach Brown

    Zach Brown
     

09 Oct, 2005

1 commit

  • dd0fc66fb   [PATCH] gfp flags annotations - part 1 ... Browse Code »

    - added typedef unsigned int __nocast gfp_t;

    - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
    the same warnings as far as sparse is concerned, doesn't change
    generated code (from gcc point of view we replaced unsigned int with
    typedef) and documents what's going on far better.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

05 Jun, 2005

1 commit

  • 854715be7   [PATCH] mpage_end_io_write() I/O error handling fix ... Browse Code »

    When fsync() runs wait_on_page_writeback_range() it only inspects pages which
    are actually under I/O (PAGECACHE_TAG_WRITEBACK). If a page completed I/O
    prior to wait_on_page_writeback_range() looking at it, it is supposed to have
    recorded its I/O error state in the address_space.

    But mpage_mpage_end_io_write() forgot to set the address_space error flag in
    this case.

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

    Qu Fuping
     

06 May, 2005

2 commits

01 May, 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