12 Apr, 2015

1 commit

  • All places outside of core VFS that checked ->read and ->write for being NULL or
    called the methods directly are gone now, so NULL {read,write} with non-NULL
    {read,write}_iter will do the right thing in all cases.

    Signed-off-by: Al Viro

    Al Viro
     

21 Jan, 2015

1 commit

  • Since "BDI: Provide backing device capability information [try #3]" the
    backing_dev_info structure also provides flags for the kind of mmap
    operation available in a nommu environment, which is entirely unrelated
    to it's original purpose.

    Introduce a new nommu-only file operation to provide this information to
    the nommu mmap code instead. Splitting this from the backing_dev_info
    structure allows to remove lots of backing_dev_info instance that aren't
    otherwise needed, and entirely gets rid of the concept of providing a
    backing_dev_info for a character device. It also removes the need for
    the mtd_inodefs filesystem.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Tejun Heo
    Acked-by: Brian Norris
    Signed-off-by: Jens Axboe

    Christoph Hellwig
     

07 May, 2014

1 commit


29 Apr, 2013

1 commit

  • Checks introduced in commit 4991e7251 ("romfs: do not use
    mtd->get_unmapped_area directly") re-introduce problems fixed in the earlier
    commit 2b4b2482e ("romfs: fix romfs_get_unmapped_area() argument check").

    If a flat binary app is located at the end of a romfs, its page aligned
    length may be outside of the romfs filesystem. The flat binary loader, via
    nommu do_mmap_pgoff(), page aligns the length it is mmaping. So simple
    offset+size checks will fail - returning EINVAL.

    We can truncate the length to keep it inside the romfs filesystem, and that
    also keeps the call to mtd_get_unmapped_area() happy.

    Are there any side effects to truncating the size here though?

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

10 Jan, 2012

2 commits


28 Jun, 2011

1 commit

  • romfs_get_unmapped_area() checks argument `len' without considering
    PAGE_ALIGN which will cause do_mmap_pgoff() return -EINVAL error after
    commit f67d9b1576c ("nommu: add page_align to mmap").

    Fix the check by changing it in same way ramfs_nommu_get_unmapped_area()
    was changed in ramfs/file-nommu.c.

    Signed-off-by: Bob Liu
    Cc: David Howells
    Cc: Paul Mundt
    Acked-by: Greg Ungerer
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bob Liu
     

24 Mar, 2009

1 commit

  • Change RomFS so that it can use MTD devices directly - without the intercession
    of the block layer - as well as using block devices.

    This permits RomFS:

    (1) to use the MTD direct mapping facility available under NOMMU conditions if
    the underlying device is directly accessible by the CPU (including XIP);

    (2) and thus to be used when the block layer is disabled.

    RomFS can be configured with support just for MTD devices, just for Block
    devices or for both. If RomFS is configured for both, then it will treat
    mtdblock device files as MTD backing stores, not block layer backing stores.

    I tested this using a CONFIG_MMU=n CONFIG_BLOCK=n kernel running on my FRV
    board with a RomFS image installed on the mtdram test device. I see my test
    program being run XIP:

    # cat /proc/maps
    ...
    c0c000b0-c0c01f8c r-xs 00000000 1f:00 144 /mnt/doshm
    ...

    GDB on the kernel can be used to show that these addresses are within the
    set-aside RAM space.

    Signed-off-by: David Howells
    Tested-by: Bernd Schmidt
    Signed-off-by: David Woodhouse

    David Howells