Eric Lee / smarc-fsl-linux-kernel

07 Jun, 2005

1 commit

22 May, 2005

1 commit

  • b5c44c214   [PATCH] fix for __generic_file_aio_read() to return 0 on EOF ... Browse Code »

    I came across the following problem while running ltp-aiodio testcases from
    ltp-full-20050405 on linux-2.6.12-rc3-mm3. I tried running the tests with
    EXT3 as well as JFS filesystems.

    One or two fsx-linux testcases were hung after some time. These testcases
    were hanging at wait_for_all_aios().

    Debugging shows that there were some iocbs which were not getting completed
    eventhough the last retry for those returned -EIOCBQUEUED. Also all such
    pending iocbs represented READ operation.

    Further debugging revealed that all such iocbs hit EOF in the DIO layer.
    To be more precise, the "pos" from which they were trying to read was
    greater than the "size" of the file. So the generic_file_direct_IO
    returned 0.

    This happens rarely as there is already a check in
    __generic_file_aio_read(), for whether "pos" < "size" before calling direct
    IO routine.

    >size = i_size_read(inode);
    >if (pos < size) {
    > retval = generic_file_direct_IO(READ, iocb,
    > iov, pos, nr_segs);

    But for READ, we are taking the inode->i_sem only in the DIO layer. So it
    is possible that some other process can change the size of the file before
    we take the i_sem. In such a case ( when "pos" > "size"), the
    __generic_file_aio_read() would return -EIOCBQUEUED even though there were
    no I/O requests submitted by the DIO layer. This would cause the AIO layer
    to expect aio_complete() for THE iocb, which doesnot happen. And thus the
    test hangs forever, waiting for an I/O completion, where there are no
    requests submitted at all.

    The following patch makes __generic_file_aio_read() return 0 (instead of
    returning -EIOCBQUEUED), on getting 0 from generic_file_direct_IO(), so
    that the AIO layer does the aio_complete().

    Testing:

    I have tested the patch on a SMP machine(with 2 Pentium 4 (HT)) running
    linux-2.6.12-rc3-mm3. I ran the ltp-aiodio testcases and none of the
    fsx-linux tests hung. Also the aio-stress tests ran without any problem.

    Signed-off-by: Suzuki K P
    Signed-off-by: Suparna Bhattacharya
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Suparna Bhattacharya
     

06 May, 2005

1 commit

01 May, 2005

4 commits

  • 67be2dd1b   [PATCH] DocBook: fix some descriptions ... Browse Code »

    Some KernelDoc descriptions are updated to match the current code.
    No code changes.

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

    Martin Waitz
     
  • cd7619d6b   [PATCH] Exterminate PAGE_BUG ... Browse Code »

    Remove PAGE_BUG - repalce it with BUG and BUG_ON.

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

    Matt Mackall
     
  • dd1d5afca   [PATCH] sync_page() smp_mb() comment ... Browse Code »

    The smp_mb() is becaus sync_page() doesn't have PG_locked while it accesses
    page_mapping(page). The comments in the patch (the entire patch is the
    addition of this comment) try to explain further how and why smp_mb() is
    used.

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

    William Lee Irwin III
     
  • f021e9210   [PATCH] generic_file_buffered_write fixes ... Browse Code »

    Anton Altaparmakov points out:

    - It calls fault_in_pages_readable() which is completely bogus if @nr_segs >
    1. It needs to be replaced by a to be written
    "fault_in_pages_readable_iovec()".

    - It increments @buf even in the iovec case thus @buf can point to random
    memory really quickly (in the iovec case) and then it calls
    fault_in_pages_readable() on this random memory.

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

    akpm@osdl.org
     

17 Apr, 2005

2 commits

  • d34573426   [PATCH] filemap_getpage can block when MAP_NONBLOCK specified ... Browse Code »

    We will return NULL from filemap_getpage when a page does not exist in the
    page cache and MAP_NONBLOCK is specified, here:

    page = find_get_page(mapping, pgoff);
    if (!page) {
    if (nonblock)
    return NULL;
    goto no_cached_page;
    }

    But we forget to do so when the page in the cache is not uptodate. The
    following could result in a blocking call:

    /*
    * Ok, found a page in the page cache, now we need to check
    * that it's up-to-date.
    */
    if (!PageUptodate(page))
    goto page_not_uptodate;

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

    Jeff Moyer
     
  • 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