mmap returns incorrect data

From: marcus hall (marcus_at_tuells.org)
Date: 04/30/04

  • Next message: Andrew Morton: "Re: ~500 megs cached yet 2.6.5 goes into swap hell" 
    Date:	Thu, 29 Apr 2004 17:12:43 -0600
To: linux-kernel@vger.kernel.org

    I have a system based on 2.5.59 kernel for arm. This system was previously
    running OK with all filesystems on a stratoflash chip, but I have recently
    moved the filesystems to a compact flash chip. Some filesystems are
    cramfs, and some have changed from jffs2 to ext3 along with the move.

    I am having trouble with ldconfig not recognizing some files as being valid.
    The files that cause the problem are files that are on an ext3 filesystem
    on the CF. Other files on a cramfs filesystem seem to work reliably.
    It seems that ldconfig mmap()s the file into its address space, and what
    it sees doesn't match what is in the file. If I pre-read the file before
    running ldconfig, so that the contents get into the cache, then ldconfig
    proceeds normally.

    Working through various layers, I see that the generic_file_mmap() gets
    called and sets things up OK, then when ldconfig references the file, the
    page fault correctly invokes filemap_nopage(), which calls
    page_cache_readaround(). By the time page_cache_readaround() returns,
    the page has been added to mapping->page_tree, and the page is added to
    ldconfig's address space.

    I can see where page_cache_readaround() gets to ext3_readpages() and then
    to ext3_get_block() to put the requests (page_cache_readahead() asks for
    16 pages) onto the queue, then __do_page_cache_readahead() calls
    blk_run_queues() to unplug the queues, but it isn't clear (yet!) where
    we wait until the blocks are read in before returning from
    page_cache_readaround().

    The CF interface has a real delay between starting a request and getting
    an interrupt when the card is ready, which the mtd driver I was using before
    doesn't do, so I am guessing that this may be the source of my problems.
    But it isn't clear why the cramfs files don't suffer from this problem (since
    they are also on the CF).

    Is there any known issue in this area? Where should I be focusing my
    attention?

    Thanks for any suggestions!

    Marcus Hall
    marcus@tuells.org

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Andrew Morton: "Re: ~500 megs cached yet 2.6.5 goes into swap hell"

    Relevant Pages