Fix the following whitescan warning:
Calling "zlib_inflateEnd(&stream)" is only useful for its return value,
which is ignored.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
fs/cramfs/uncompress.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/cramfs/uncompress
On Thu, 26 Nov 2020, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in the Kconfig help text. Fix it.
>
> Signed-off-by: Colin Ian King
Acked-by: Nicolas Pitre
> ---
> fs/cramfs/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion
From: Colin Ian King
There is a spelling mistake in the Kconfig help text. Fix it.
Signed-off-by: Colin Ian King
---
fs/cramfs/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig
index d98cef0dbb6b..a8af8c6ac15d 100644
--- a/fs
On Mon, 23 Nov 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> Remove open coded kmap/memcpy/kunmap and use mempcy_from_page() instead.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
> ---
> fs/cramfs/inode.c | 3 +--
> 1 file
From: Ira Weiny
Remove open coded kmap/memcpy/kunmap and use mempcy_from_page() instead.
Cc: Nicolas Pitre
Signed-off-by: Ira Weiny
---
fs/cramfs/inode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 4b90cfd1ec36
On Tue, Oct 13, 2020 at 09:01:49PM +0100, Al Viro wrote:
> On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
>
> > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> > int size)
> > {
> > char *vto = kmap_atomic(to);
> >
> > memcpy(vto, vfrom, size
lized to a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
You mea
o a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1 file chan
ew kmap_thread() call.
> >
> > Cc: Nicolas Pitre
> > Signed-off-by: Ira Weiny
> > ---
> > fs/cramfs/inode.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > index 91
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> --
ked-by: Nicolas Pitre
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +24
From: Ira Weiny
The kmap() calls in this FS are localized to a single thread. To avoid
the over head of global PKRS updates use the new kmap_thread() call.
Cc: Nicolas Pitre
Signed-off-by: Ira Weiny
---
fs/cramfs/inode.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
The cramfs readpage implementation was already synchronous, so use
AOP_UPDATED_PAGE to avoid cycling the page lock.
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/cramfs/inode.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index
The cramfs readpage implementation was already synchronous, so use
AOP_UPDATED_PAGE to avoid cycling the page lock.
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/cramfs/inode.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index
On Wed, 27 Mar 2019, David Howells wrote:
> Convert the cramfs filesystem to the new internal mount API as the old
> one will be obsoleted and removed. This allows greater flexibility in
> communication of mount parameters between userspace, the VFS and the
> filesystem.
>
>
Signed-off-by: David Howells
cc: Nicolas Pitre
cc: linux-...@lists.infradead.org
cc: linux-bl...@vger.kernel.org
---
fs/cramfs/inode.c | 69 ++---
1 file changed, 39 insertions(+), 30 deletions(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs
Here's a set of patches that convert romfs, cramfs, jffs2 and squashfs to
use the new fs_context struct and replace mount_mtd(). They have
prerequisite commits (such as replacing mount_bdev()) that can be found in
the branch detailed below.
(1) Provide a replacement for mount_mtd() that
Signed-off-by: David Howells
cc: Nicolas Pitre
cc: linux-...@lists.infradead.org
cc: linux-bl...@vger.kernel.org
---
fs/cramfs/inode.c | 69 ++---
1 file changed, 39 insertions(+), 30 deletions(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs
, and wrongly pass
the buffer size test.
Reported-by: Anatoly Trosinenko
Signed-off-by: Nicolas Pitre
Signed-off-by: Ben Hutchings
---
fs/cramfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -183,7 +183,8 @@ static void
, and wrongly pass
the buffer size test.
Reported-by: Anatoly Trosinenko
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/cramfs/inode.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
, and wrongly pass
the buffer size test.
Reported-by: Anatoly Trosinenko
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/cramfs/inode.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
, and wrongly pass
the buffer size test.
Reported-by: Anatoly Trosinenko
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/cramfs/inode.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
, and wrongly pass
the buffer size test.
Reported-by: Anatoly Trosinenko
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/cramfs/inode.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
, and wrongly pass
the buffer size test.
Reported-by: Anatoly Trosinenko
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/cramfs/inode.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
, and wrongly pass
the buffer size test.
Reported-by: Anatoly Trosinenko
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/cramfs/inode.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
Tested in fresh torvalds/master branch. Thank you!
Best regards
Anatoly
пн, 29 окт. 2018 г. в 19:03, Nicolas Pitre :
>
> On Mon, 29 Oct 2018, Anatoly Trosinenko wrote:
>
> > > How do I populate /vtmp? Mine is empty at this point. I imagine I
> > > should put the cramfs
On Tue, 30 Oct 2018, Linus Torvalds wrote:
> On Tue, Oct 30, 2018 at 12:09 PM Nicolas Pitre
> wrote:
> >
> > Make the Cramfs code more robust against filesystem corruptions,
> > plus trivial indentation fixes.
>
> Shortlog?
Sorry, I will next time.
> Anyway, pulled.
Thanks.
Nicolas
On Tue, Oct 30, 2018 at 12:09 PM Nicolas Pitre wrote:
>
> Make the Cramfs code more robust against filesystem corruptions,
> plus trivial indentation fixes.
Shortlog?
Anyway, pulled.
Linus
Linus,
Please pull from:
git://git.linaro.org/people/nicolas.pitre/linux tags/cramfs_fixes
Make the Cramfs code more robust against filesystem corruptions,
plus trivial indentation fixes.
Tag: 37b13f91069f87579018f4870da082bd172be005
Branch: 56ce68bceeefa38e5b3509bf3d39259138e2d76a
fs
On Mon, 29 Oct 2018, Anatoly Trosinenko wrote:
> > How do I populate /vtmp? Mine is empty at this point. I imagine I
> > should put the cramfs image somewhere on the host, but I'm not that
> > familiar withkvm.
>
> Oops, forgot to say, it is the /tmp/kvm-xfstests-$
> How do I populate /vtmp? Mine is empty at this point. I imagine I should
put the cramfs image somewhere on the host, but I'm not that familiar
withkvm.
Oops, forgot to say, it is the /tmp/kvm-xfstests-$USER directory on
the host (it will be created when you first launch kvm-xfstests a
On Sun, 28 Oct 2018, Anatoly Trosinenko wrote:
> Hello,
>
> When reading a file from a fuzzed cramfs image, unhandled kernel
> paging request occurs.
Hmmm... It doesn't show up on my test system.
> How to reproduce with kvm-xfstests:
> 1) Checkout the v4.19 tag, cop
On Tue, 28 Aug 2018, Matthew Wilcox wrote:
> On Tue, Aug 28, 2018 at 01:49:25PM -0400, Nicolas Pitre wrote:
> > On Tue, 28 Aug 2018, Matthew Wilcox wrote:
> > > - ret = vm_insert_mixed(vma, vma->vm_start + off, pfn);
> > > + vmf = vmf_insert_mixed(vma, vma->vm_start
On Tue, Aug 28, 2018 at 01:49:25PM -0400, Nicolas Pitre wrote:
> On Tue, 28 Aug 2018, Matthew Wilcox wrote:
> > - ret = vm_insert_mixed(vma, vma->vm_start + off, pfn);
> > + vmf = vmf_insert_mixed(vma, vma->vm_start + off, pfn);
> > + if (vmf &
On Tue, 28 Aug 2018, Matthew Wilcox wrote:
> cramfs is the only remaining user of vm_insert_mixed; convert it.
>
> Signed-off-by: Matthew Wilcox
> ---
> fs/cramfs/inode.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cramfs/ino
cramfs is the only remaining user of vm_insert_mixed; convert it.
Signed-off-by: Matthew Wilcox
---
fs/cramfs/inode.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index f408994fc632..b72449c19cd1 100644
--- a/fs/cramfs
On Sun, May 13, 2018 at 06:21:18PM -0400, Nicolas Pitre wrote:
> On Sun, 13 May 2018, Joe Perches wrote:
>
> > There's an extra C here...
> >
> > Fixes: 99c18ce580c6 ("cramfs: direct memory access support")
> > Signed-off-by: Joe Perches
>
On Sun, 13 May 2018, Joe Perches wrote:
> There's an extra C here...
>
> Fixes: 99c18ce580c6 ("cramfs: direct memory access support")
> Signed-off-by: Joe Perches
Indeed.
Acked-by: Nicolas Pitre
@Al: could you pick up this one too?
> ---
> fs/cramfs/in
There's an extra C here...
Fixes: 99c18ce580c6 ("cramfs: direct memory access support")
Signed-off-by: Joe Perches
---
fs/cramfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 017b0ab19bc4..124b093d14e5
Signed-off-by: Mark Fasheh
---
fs/cramfs/inode.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 017b0ab19bc4..eb633de7ccbe 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -294,7 +294,7 @@ static void
On Thu, 8 Feb 2018, Linus Torvalds wrote:
> On Wed, Feb 7, 2018 at 7:08 PM, Nicolas Pitre
> wrote:
> >
> > Viro once told me that my cramfs pull requests could go either to him or
> > to you. I have only this one patch at the moment, and since it depends
> > on a
On 02/08/2018 11:38 AM, Linus Torvalds wrote:
> On Wed, Feb 7, 2018 at 7:08 PM, Nicolas Pitre
> wrote:
>>
>> Viro once told me that my cramfs pull requests could go either to him or
>> to you. I have only this one patch at the moment, and since it depends
>> on a co
On Wed, Feb 7, 2018 at 7:08 PM, Nicolas Pitre wrote:
>
> Viro once told me that my cramfs pull requests could go either to him or
> to you. I have only this one patch at the moment, and since it depends
> on a commit that recently appeared in your tree I'm therefore sending it
Commit b9f5fb1800d8 ("cramfs: fix MTD dependency") did what it says.
Since commit 9059a3493efe ("kconfig: fix relational operators for bool
and tristate symbols") it is possible to do it slightly better though.
Signed-off-by: Nicolas Pitre
---
Linus,
Viro once told me
Hi Nicolas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051
commit: 99c18ce580c6cc6763e694b4ce320d7b226ab59b cramfs: direct memory access
support
date: 9 weeks ago
config
On Fri, 10 Nov 2017, Arnd Bergmann wrote:
> With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
>
> fs/cramfs/inode.o: In function `cramfs_mount':
> inode.c:(.text+0x220): undefined reference to `mount_mtd'
> fs/cramfs/inode.o: In function `cramfs_mtd_fill
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e1d1ea549b57790a3d8cf6300e6ef86118d692a3
commit: 99c18ce580c6cc6763e694b4ce320d7b226ab59b cramfs: direct memory access
support
date: 5 weeks ago
config: i386-randconfig-i1-201747 (attached as .config
Nicolas Pitre cramfs work.
The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f:
Linux 4.14-rc4 (2017-10-08 20:53:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.cramfs
for you to fetch
icolas Pitre
> > >> wrote:
> > >> > On Fri, 10 Nov 2017, Arnd Bergmann wrote:
> > >> >
> > >> >> With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
> > >> >>
> > >> >> fs/cramfs/i
d Bergmann wrote:
> >> >
> >> >> With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
> >> >>
> >> >> fs/cramfs/inode.o: In function `cramfs_mount':
> >> >> inode.c:(.text+0x220): undefined reference to `mou
m and CONFIG_CRAMFS=y, we now get a link failure:
>> >>
>> >> fs/cramfs/inode.o: In function `cramfs_mount':
>> >> inode.c:(.text+0x220): undefined reference to `mount_mtd'
>> >> fs/cramfs/inode.o: In function `cramfs_mtd_fill_super':
>
On Fri, 10 Nov 2017, Arnd Bergmann wrote:
> On Fri, Nov 10, 2017 at 5:35 PM, Nicolas Pitre
> wrote:
> > On Fri, 10 Nov 2017, Arnd Bergmann wrote:
> >
> >> With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
> >>
> >> fs/cramfs/inod
On Fri, Nov 10, 2017 at 5:35 PM, Nicolas Pitre wrote:
> On Fri, 10 Nov 2017, Arnd Bergmann wrote:
>
>> With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
>>
>> fs/cramfs/inode.o: In function `cramfs_mount':
>> inode.c:(.text+0x220): undefined re
On Fri, 10 Nov 2017, Arnd Bergmann wrote:
> With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
>
> fs/cramfs/inode.o: In function `cramfs_mount':
> inode.c:(.text+0x220): undefined reference to `mount_mtd'
> fs/cramfs/inode.o: In function `cramfs_mtd_fill
With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
fs/cramfs/inode.o: In function `cramfs_mount':
inode.c:(.text+0x220): undefined reference to `mount_mtd'
fs/cramfs/inode.o: In function `cramfs_mtd_fill_super':
inode.c:(.text+0x6d8): undefined reference to `mtd
es, that's what I thought you meant, which corresponds to the second
> part of my comment above. And as I said I'm not convinced this hiding of
> kernel config effects is better for understanding what is actually going
> on locally, and my own preference is how things are righ
On Sat, 14 Oct 2017, Al Viro wrote:
> On Fri, Oct 13, 2017 at 04:09:23PM -0400, Nicolas Pitre wrote:
> > On Fri, 13 Oct 2017, Al Viro wrote:
> >
> > > OK... I wonder if it should simply define stubs for kill_mtd_super(),
> > > mtd_unpoint() and kill_block_super() in !CONFIG_MTD and !CONFIG_BLOCK
On Fri, Oct 13, 2017 at 04:09:23PM -0400, Nicolas Pitre wrote:
> On Fri, 13 Oct 2017, Al Viro wrote:
>
> > OK... I wonder if it should simply define stubs for kill_mtd_super(),
> > mtd_unpoint() and kill_block_super() in !CONFIG_MTD and !CONFIG_BLOCK
> > cases. mount_mtd() and mount_bdev() as we
e this is worth it in the end given this is not a common
occurrence in the kernel either.
Still, I've rearanged it slightly and fixed the null deref you spotted
earlier. Latest patch below:
- >8
Subject: [PATCH] cramfs: direct memory access support
Small embedded systems typically ex
On Fri, 13 Oct 2017, Al Viro wrote:
> On Fri, Oct 13, 2017 at 01:39:13PM -0400, Nicolas Pitre wrote:
> > On Fri, 13 Oct 2017, Al Viro wrote:
> >
> > > On Thu, Oct 12, 2017 at 02:16:10AM -0400, Nicolas Pitre wrote:
> > >
> > > > static void cramfs_kill_sb(struct super_block *sb)
> > > > {
> > >
On Fri, Oct 13, 2017 at 01:39:13PM -0400, Nicolas Pitre wrote:
> On Fri, 13 Oct 2017, Al Viro wrote:
>
> > On Thu, Oct 12, 2017 at 02:16:10AM -0400, Nicolas Pitre wrote:
> >
> > > static void cramfs_kill_sb(struct super_block *sb)
> > > {
> > > struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
> >
On Fri, 13 Oct 2017, Al Viro wrote:
> On Thu, Oct 12, 2017 at 02:16:10AM -0400, Nicolas Pitre wrote:
>
> > static void cramfs_kill_sb(struct super_block *sb)
> > {
> > struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
> >
> > - kill_block_super(sb);
> > + if (IS_ENABLED(CCONFIG_CRAMFS_MTD))
On Thu, Oct 12, 2017 at 02:16:10AM -0400, Nicolas Pitre wrote:
> static void cramfs_kill_sb(struct super_block *sb)
> {
> struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
>
> - kill_block_super(sb);
> + if (IS_ENABLED(CCONFIG_CRAMFS_MTD)) {
> + if (sbi->mtd_point_size)
> +
As said before I'm no big fan of all the debug chatter, but the rest
looks fine, so:
Reviewed-by: Christoph Hellwig
This looks much better, thanks. I'm not a big fan of the games with
IS_ENABLED and letting the compiler optimize code away, but you're
the maintainer..
Reviewed-by: Christoph Hellwig
em data directly from flash to the cramfs filesystem
> > as well. Cramfs is particularly well suited to this feature as it is
> > very simple and its RAM usage is already very low, and with this feature
> > it is possible to use it with no block device support and even lower RAM
&
On Thursday, October 12, 2017, Nicolas Pitre wrote:
> Small embedded systems typically execute the kernel code in place (XIP)
> directly from flash to save on precious RAM usage. This adds the ability
> to consume filesystem data directly from flash to the cramfs filesystem
> as wel
This series brings a nice refresh to the cramfs filesystem, adding the
following capabilities:
- Direct memory access, bypassing the block and/or MTD layers entirely.
- Ability to store individual data blocks uncompressed.
- Ability to locate individual data blocks anywhere in the filesystem
compatible with legacy cramfs images.
Signed-off-by: Nicolas Pitre
Tested-by: Chris Brandt
---
fs/cramfs/README | 31 ++-
fs/cramfs/inode.c | 90 +-
include/uapi/linux/cramfs_fs.h | 26 +++-
3 files changed, 126
Small embedded systems typically execute the kernel code in place (XIP)
directly from flash to save on precious RAM usage. This adds the ability
to consume filesystem data directly from flash to the cramfs filesystem
as well. Cramfs is particularly well suited to this feature as it is
very simple
When cramfs in physical memory is used then we have the opportunity
to map files directly from ROM, directly into user space, saving on
RAM usage. This gives us Execute-In-Place (XIP) support.
For a file to be mmap()-able, the map area has to correspond to a range
of uncompressed and contiguous
s.txt | 42
MAINTAINERS | 4 ++--
fs/cramfs/Kconfig| 9 +---
3 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/cramfs.txt
b/Documentation/filesystems/cramfs.txt
index 4006298f67..8e19a53d64 100644
--- a/Doc
; just wouldn't be called, but that might be more confusing then helpful.
Well... For one thing generic_file_vm_ops is not exported to modules so
now I simply call generic_file_readonly_mmap() at the beginning and let
it validate the vma flags. That allowed for some simplifications at the
ly. This creates unneeded
overhead, both in terms of code execution and TLB trashing. With a
single map, the ARM code at least is smart enough to fit large MMU
descriptors when possible with a single TLB for a large region. And if
you're interested in XIP cramfs then you do have huge vmal
On Friday, October 06, 2017, Christoph Hellwig wrote:
> This is still missing a proper API for accessing the file system,
> as said before specifying a physical address in the mount command
> line is a an absolute non-no.
>
> Either work with the mtd folks to get the mtd core down to an absolute
>
> + /* Don't map the last page if it contains some other data */
> + if (unlikely(pgoff + pages == max_pages)) {
> + unsigned int partial = offset_in_page(inode->i_size);
> + if (partial) {
> + char *data = sbi->linear_virt_addr + offset;
> +
This is still missing a proper API for accessing the file system,
as said before specifying a physical address in the mount command
line is a an absolute non-no.
Either work with the mtd folks to get the mtd core down to an absolute
minimum suitable for you, or figure out a way to specify fs nodes
efore this area is discarded.
In the non-MMU case it is the get_unmapped_area method that is responsible
for providing the address where the actual data can be found. No mapping
is necessary of course.
Signed-off-by: Nicolas Pitre
Tested-by: Chris Brandt
---
fs/cramf
compatible with legacy cramfs images.
Signed-off-by: Nicolas Pitre
Tested-by: Chris Brandt
---
fs/cramfs/README | 31 ++-
fs/cramfs/inode.c | 90 +-
include/uapi/linux/cramfs_fs.h | 26 +++-
3 files changed, 126
prepare_namespace(void)
ssleep(root_delay);
}
+ if (IS_ENABLED(CONFIG_CRAMFS_PHYSMEM) && root_fs_names &&
+ !strcmp(root_fs_names, "cramfs_physmem")) {
+ int err = do_mount_root
This series brings a nice refresh to the cramfs filesystem, adding the
following capabilities:
- Direct memory access, bypassing the block and/or MTD layers entirely.
- Ability to store individual data blocks uncompressed.
- Ability to locate individual data blocks anywhere in the filesystem
Small embedded systems typically execute the kernel code in place (XIP)
directly from flash to save on precious RAM usage. This adds the ability
to consume filesystem data directly from flash to the cramfs filesystem
as well. Cramfs is particularly well suited to this feature as it is
very simple
s.txt | 42
MAINTAINERS | 4 ++--
fs/cramfs/Kconfig| 9 +---
3 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/cramfs.txt
b/Documentation/filesystems/cramfs.txt
index 4006298f67..8875d306bc 100644
--- a/Doc
On Thursday, October 05, 2017, Nicolas Pitre wrote:
> Do you have the same amount of free memory once booted in both cases?
Yes, almost exactly the same, so obvious it must be working the same for
both cases. That's enough evidence for me.
Thanks.
Chris
On Thu, 5 Oct 2017, Chris Brandt wrote:
> On Wednesday, October 04, 2017, Nicolas Pitre wrote:
> > Anyway, here's a replacement for patch 4/5 below:
> >
> > ----- >8
> > Subject: cramfs: add mmap support
> >
> > When cramfs_physmem is used then we
e actual physical address in vma->vm_pgoff.
> With VM_MIXEDMAP things are no longer visible. Any opinion for the best
> way to overcome this?
>
> Anyway, here's a replacement for patch 4/5 below:
>
> - >8
> Subject: cramfs: add mmap support
>
> When cramfs
On Thu, 5 Oct 2017, Christoph Hellwig wrote:
> On Wed, Oct 04, 2017 at 04:47:52PM -0400, Nicolas Pitre wrote:
> > The only downside so far is the lack of visibility from user space to
> > confirm it actually works as intended. With the vma splitting approach
> > you clearly see what gets directl
ckptrs[0] & ~CRAMFS_BLK_FLAGS;
> + i = 0;
> + do {
> + u32 expect = blockaddr + i * (PAGE_SIZE >> 2);
There are a lot of magic numbers in here. It seems like that's standard
for cramfs, but if you really plan to bring it back to
the best
way to overcome this?
Anyway, here's a replacement for patch 4/5 below:
----- >8
Subject: cramfs: add mmap support
When cramfs_physmem is used then we have the opportunity to map files
directly from ROM, directly into user space, saving on RAM usage.
This gives us Execute-In-Pl
On Tue, Oct 03, 2017 at 11:40:28AM -0400, Nicolas Pitre wrote:
> I provided that explanation several times by now in my cover letter. And
> separately even to you directly at least once. What else should I do?
You should do the right things instead of stating irrelevant things
in your cover lett
On Tue, 3 Oct 2017, Christoph Hellwig wrote:
> On Tue, Oct 03, 2017 at 11:30:50AM -0400, Nicolas Pitre wrote:
> > Unless you have a better scheme altogether to suggest of course, given
> > the existing constraints.
>
> I still can't understand why this convoluted fault path that finds
> vma, at
On Tue, Oct 03, 2017 at 11:30:50AM -0400, Nicolas Pitre wrote:
> Unless you have a better scheme altogether to suggest of course, given
> the existing constraints.
I still can't understand why this convoluted fault path that finds
vma, attempts with all kinds of races and then tries to update th
On Tue, 3 Oct 2017, Christoph Hellwig wrote:
> On Mon, Oct 02, 2017 at 07:33:29PM -0400, Nicolas Pitre wrote:
> > On Tue, 3 Oct 2017, Richard Weinberger wrote:
> >
> > > On Mon, Oct 2, 2017 at 12:29 AM, Nicolas Pitre
> > > wrote:
> > > > On Sun, 1 Oct 2017, Christoph Hellwig wrote:
> > > >
> >
On Tue, 3 Oct 2017, Christoph Hellwig wrote:
> On Sun, Oct 01, 2017 at 06:27:11PM -0400, Nicolas Pitre wrote:
> > If you prefer, the physical address could be specified with a Kconfig
> > symbol just like the kernel link address. Personally I think it is best
> > to keep it along with the other
must be specified when using a memory accessible cramfs image, and
> >> the physaddr argument must provide the actual filesystem image's
> physical
> >> memory location.
> >
> > Sorry, but this still is a complete no-go. A physical address is not a
> > pr
On Sun, Oct 01, 2017 at 06:27:11PM -0400, Nicolas Pitre wrote:
> If you prefer, the physical address could be specified with a Kconfig
> symbol just like the kernel link address. Personally I think it is best
> to keep it along with the other root mount args. But going all the way
> with a dynam
On Mon, Oct 02, 2017 at 07:33:29PM -0400, Nicolas Pitre wrote:
> On Tue, 3 Oct 2017, Richard Weinberger wrote:
>
> > On Mon, Oct 2, 2017 at 12:29 AM, Nicolas Pitre
> > wrote:
> > > On Sun, 1 Oct 2017, Christoph Hellwig wrote:
> > >
> > >> up_read(&mm->mmap_sem) in the fault path is a still a com
On Sun, Oct 1, 2017 at 3:29 AM, Christoph Hellwig wrote:
> On Wed, Sep 27, 2017 at 07:32:20PM -0400, Nicolas Pitre wrote:
>> To distinguish between both access types, the cramfs_physmem filesystem
>> type must be specified when using a memory accessible cramfs image, and
>>
On Tue, 3 Oct 2017, Richard Weinberger wrote:
> On Mon, Oct 2, 2017 at 12:29 AM, Nicolas Pitre
> wrote:
> > On Sun, 1 Oct 2017, Christoph Hellwig wrote:
> >
> >> up_read(&mm->mmap_sem) in the fault path is a still a complete
> >> no-go,
> >>
> >> NAK
> >
> > Care to elaborate?
> >
> > What about
1 - 100 of 344 matches
Mail list logo
