From: Matthew Wilcox (Oracle)
[ Upstream commit 50b7d85680086126d7bd91dae81d57d4cb1ab6b7 ]
ramfs needs to check that pages are both physically contiguous and
contiguous in the file. If the page cache happens to have, eg, page A for
index 0 of the file, no page for index 1, and page A+1 for
From: Matthew Wilcox (Oracle)
[ Upstream commit 50b7d85680086126d7bd91dae81d57d4cb1ab6b7 ]
ramfs needs to check that pages are both physically contiguous and
contiguous in the file. If the page cache happens to have, eg, page A for
index 0 of the file, no page for index 1, and page A+1 for
From: Matthew Wilcox (Oracle)
[ Upstream commit 50b7d85680086126d7bd91dae81d57d4cb1ab6b7 ]
ramfs needs to check that pages are both physically contiguous and
contiguous in the file. If the page cache happens to have, eg, page A for
index 0 of the file, no page for index 1, and page A+1 for
From: Matthew Wilcox (Oracle)
[ Upstream commit 50b7d85680086126d7bd91dae81d57d4cb1ab6b7 ]
ramfs needs to check that pages are both physically contiguous and
contiguous in the file. If the page cache happens to have, eg, page A for
index 0 of the file, no page for index 1, and page A+1 for
From: Matthew Wilcox (Oracle)
[ Upstream commit 50b7d85680086126d7bd91dae81d57d4cb1ab6b7 ]
ramfs needs to check that pages are both physically contiguous and
contiguous in the file. If the page cache happens to have, eg, page A for
index 0 of the file, no page for index 1, and page A+1 for
On Wed, Aug 19, 2020 at 5:20 PM Pranay Srivastava
wrote:
>
> Hello,
>
> I'm running a system where rootfs is ramfs. For kernel version 5.2.11
>
> # cat /proc/self/mountinfo
> 0 0 0:1 / / rw - rootfs rootfs rw
> %<---snip>%
>
> while for kernel 5.4.58
>
Hello,
I'm running a system where rootfs is ramfs. For kernel version 5.2.11
# cat /proc/self/mountinfo
0 0 0:1 / / rw - rootfs rootfs rw
%<---snip>%
while for kernel 5.4.58
# cat /proc/self/mountinfo
0 0 0:1 / / rw - rootfs none rw
%<---snip>%
The reason for the above diff
Refer to tmpfs use inode number and generation number to construct the
filehandle for nfs-export
Without this patch, when run exportfs for nfs-kernel-server to export
ramfs, it will report "not support NFS export"
Signed-off-by: Haodong Wong
---
fs/ramfs/in
the subject is unsuitable? i mean the prefix should be fs/ramfs rather
than knfsd?
2019-05-22 3:25 GMT+12:00, Haodong Wong :
> Refer to tmpfs, use inode number and generation number
> to construct the filehandle for nfs-export
would you like to describe what is happening without this patch
Refer to tmpfs, use inode number and generation number
to construct the filehandle for nfs-export
Signed-off-by: Haodong Wong
---
fs/ramfs/inode.c | 72
1 file changed, 72 insertions(+)
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index
Convert the ramfs, shmem, tmpfs, devtmpfs and rootfs filesystems 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.
See Documentation/filesystems
tmpfs changes, then devtmpfs and rootfs, which are wrappers around
tmpfs or ramfs, must change too - and thus so must ramfs, so convert these
also.
Signed-off-by: David Howells
cc: Hugh Dickins
cc: linux...@kvack.org
---
drivers/base/devtmpfs.c | 16 +-
fs/ramfs/inode.c |
tmpfs is under CONFIG_TMPFS which can be disabled.
ramfs is always enabled.
Signed-off-by: Alexey Dobriyan
---
fold into proc-test-proc-maps-smaps-smaps_rollup-statm.patch
tools/testing/selftests/proc/proc-pid-vm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a
Signed-off-by: Alexey Dobriyan
---
fs/ramfs/inode.c | 12
1 file changed, 12 insertions(+)
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -145,6 +145,17 @@ static int ramfs_symlink(struct inode * dir, struct dentry
*dentry, const char *
return error;
}
+static int
Signed-off-by: Mark Fasheh
---
fs/ramfs/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 11201b2d06b9..57b78ae51ed1 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -101,7 +101,7 @@ struct inode *ramfs_get_inode
Implement the show_options superblock op for ramfs as part of a bid to get
rid of s_options and generic_show_options() to make it easier to implement
a context-based mount where the mount options can be passed individually
over a file descriptor.
Signed-off-by: David Howells
---
fs/ramfs
From: Rob Landley
Clarify help text that compression applies to ramfs as well as legacy ramdisk.
Signed-off-by: Rob Landley
---
usr/Kconfig | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/usr/Kconfig b/usr/Kconfig
index 572dcf7..d6f4633 100644
--- a/usr
> On 09/20/16 18:07, H. Peter Anvin wrote:
> >
> >> - vvar is highly magical. IMO letting it get mapped with VM_MAYWRITE
> >> is asking for trouble, as anything that writes it will COW it, leading
> >> to strange malfunctions.
> >>
>
> The vvar page obviously needs to be mapped MAP_SHARED, and th
On 09/20/16 18:07, H. Peter Anvin wrote:
>
>> - vvar is highly magical. IMO letting it get mapped with VM_MAYWRITE
>> is asking for trouble, as anything that writes it will COW it, leading
>> to strange malfunctions.
>>
The vvar page obviously needs to be mapped MAP_SHARED, and the
underlying f
On 09/20/16 17:54, Andy Lutomirski wrote:
> - If vvar is in the same inode, then that inode won't be a valid ELF
> image, because the ELF header won't be in the right place.
So the vvar ought to move into an actual ELF segment, which is probably
The Right Thing anyway.
> - vvar is highly magica
On Tue, Sep 20, 2016 at 5:32 PM, H. Peter Anvin wrote:
> On 09/20/16 17:22, H. Peter Anvin wrote:
>> The more I'm thinking about this, why don't we simply have these (the
>> various possible vdsos as well as vvar) as actual files in sysfs instead
>> of introducing a new filesystem? I don't believ
On 09/20/16 17:22, H. Peter Anvin wrote:
> The more I'm thinking about this, why don't we simply have these (the
> various possible vdsos as well as vvar) as actual files in sysfs instead
> of introducing a new filesystem? I don't believe sysfs actually has to
> be mounted in order for sysfs files
The more I'm thinking about this, why don't we simply have these (the
various possible vdsos as well as vvar) as actual files in sysfs instead
of introducing a new filesystem? I don't believe sysfs actually has to
be mounted in order for sysfs files to have an inode.
It could also be in procfs, I
2016-08-26 17:42 GMT+03:00 Dmitry Safonov <0x7f454...@gmail.com>:
> 2016-08-26 17:32 GMT+03:00 Andy Lutomirski :
>> On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>>> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x
2016-08-26 17:32 GMT+03:00 Andy Lutomirski :
> On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
>>> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
>>> wrote:
2016-08-25 23:49 GMT+03:00 H. Peter
On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
>> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
>> wrote:
>>>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
On August 25, 2016 8:21:07 AM PDT, Dm
2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
> wrote:
>>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
>>> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
>> wrote:
This patches set is cleanly RFC and is not supposed to be
This patches set is cleanly RFC and is not supposed to be applied.
Also for RFC time it builds only on x86_64.
So, in a mail thread Oleg told that it would be worth to introduce vm_file
for vdso mappings as currently uprobes can not be placed on vDSO VMAs [1].
In this patches set I introduce in-ke
On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
>> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
> wrote:
>>>This patches set is cleanly RFC and is not supposed to be applied.
>>>Also for RFC time it builds only on x86
2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
> wrote:
>>This patches set is cleanly RFC and is not supposed to be applied.
>>Also for RFC time it builds only on x86_64.
>>
>>So, in a mail thread Oleg told that it would be worth to introduce
>>vm_
On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
wrote:
>This patches set is cleanly RFC and is not supposed to be applied.
>Also for RFC time it builds only on x86_64.
>
>So, in a mail thread Oleg told that it would be worth to introduce
>vm_file
>for vdso mappings as currently uprobes can not
();
Signed-off-by: Kirill A. Shutemov
---
fs/ramfs/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 38981b037524..1ab6e6c2e60e 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -223,8 +223,8 @@ int ramfs_fill_super(
CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_fs_time() instead.
Signed-off-by: Deepa Dinamani
Cc: Andrew Morton
Cc: David Howells
Cc: Michal Hocko
---
fs/ramfs/inode.c | 13 -
1 file ch
There's no reason to keep this around after init.
Signed-off-by: Rasmus Villemoes
---
fs/ramfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 889d558b4e05..74afa43cced5 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/in
> We summarized our finding:
> (* means what we believe is correct beahvoir)
>
>
> ramfs affsfsplus
> vfs xfs fat gfs2jffs2 hfsh
> operation | * | | | | | | | | |
&g
21553
(ext3) 0b23076988b44b2c165e060248345de6f2337387
| ext3/4: fix update of mtime and ctime on rename
-
We summarized our finding:
(* means what we believe is correct beahvoir)
ramfs
Compile out splice support from ramfs when the splice-family of syscalls is not
supported by the system (i.e. CONFIG_SYSCALL_SPLICE is undefined).
Signed-off-by: Pieter Smith
---
fs/ramfs/file-mmu.c | 4 ++--
fs/ramfs/file-nommu.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions
Cc: Axel Lin
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/ramfs/file-nommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index dda012a..bbafbde 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
devtmpfs will use ramfs if tmpfs is not available, and it needs
to store some data of its own. Add a sub_fs_data pointer to
struct ram_fs_info and move the struct definition to the shared
header, and export the relevant structs to give devtmpfs access
to this pointer.
Signed-off-by: Seth Forshee
The ramfs is always built in. It will never be modular, so
using module_init as an alias for __initcall is rather
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously n
3.8.13.14 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mimi Zohar
commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.
This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.
Everything in the initramfs should be measured and ap
3.5.7.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mimi Zohar
commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.
This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.
Everything in the initramfs should be measured and app
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Mimi Zohar
commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.
This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.
Everything in the initramfs should be measured and appraised,
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Mimi Zohar
commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.
This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.
Everything in the initramfs should be measured and appraised
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Mimi Zohar
commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.
This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.
Everything in the initramfs should be measured and appraised
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Mimi Zohar
commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.
This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.
Everything in the initramfs should be measured and appraised
Since commit 853ac43ab194f "shmem: unify regular and tiny shmem",
ramfs_nommu_get_unmapped_area() and ramfs_nommu_mmap() are not directly
referenced outside of file-nommu.c. Thus make them static.
Signed-off-by: Axel Lin
---
fs/ramfs/file-nommu.c | 10 --
include/linux/ra
On Thu, Nov 14, 2013 at 02:59:19PM +0800, Axel Lin wrote:
> The memory leak was introduced by commit 318ceed0884
> "tidy up after d_make_root() conversion".
No memory leaks there. Note that ->kill_sb() is called in *all*
cases, so that kfree() will be done by it just fine.
It's *not* ->put_super
On Thu, Nov 14, 2013 at 02:59:19PM +0800, Axel Lin wrote:
> The memory leak was introduced by commit 318ceed0884
> "tidy up after d_make_root() conversion".
>
> Signed-off-by: Axel Lin
> ---
> fs/ramfs/inode.c | 12 +---
> 1 file changed, 9 insertions(+),
The memory leak was introduced by commit 318ceed0884
"tidy up after d_make_root() conversion".
Signed-off-by: Axel Lin
---
fs/ramfs/inode.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 39d1465..868a41e 10064
ramfs is the most simple fs from page cache point of view. Let's start
transparent huge page cache enabling here.
ramfs pages are not movable[1] and switching to transhuge pages doesn't
affect that. We need to fix this eventually.
[1] http://lkml.org/lkml/2013/4/2/720
Signed-off-by
From: "Kirill A. Shutemov"
ramfs is the most simple fs from page cache point of view. Let's start
transparent huge page cache enabling here.
ramfs pages are not movable[1] and switching to transhuge pages doesn't
affect that. We need to fix this eventually.
[1] http://lk
On 07/17/2013 04:06 PM, Andrew Morton wrote:
> On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley wrote:
>
>> Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
>> Specify rootfstype=ramfs to get the old initramfs behavior.
>>
>> The previous init
e:
>
> > Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
> > Specify rootfstype=ramfs to get the old initramfs behavior.
> >
> > The previous initramfs code provided a fairly crappy root
filesystem:
> > didn't let you --bind mount directori
On Wed, 17 Jul 2013, Andrew Morton wrote:
> On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley wrote:
>
> > Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
> > Specify rootfstype=ramfs to get the old initramfs behavior.
> >
> > The previo
On Tue, 16 Jul 2013 08:31:13 -0700 (PDT) Rob Landley wrote:
> Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
> Specify rootfstype=ramfs to get the old initramfs behavior.
>
> The previous initramfs code provided a fairly crappy root filesystem:
> didn&#x
Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
Specify rootfstype=ramfs to get the old initramfs behavior.
The previous initramfs code provided a fairly crappy root filesystem:
didn't let you --bind mount directories out of it, reported zero
size/usage so it didn't
From: Rob Landley
When the rootfs code was a wrapper around ramfs, having them in the same
file made sense. Now that it can wrap another filesystem type, move it
in with the init code instead.
This also allows a subsequent patch to access rootfstype= command line arg.
Signed-off-by: Rob
Use tmpfs for rootfs when CONFIG_TMPFS=y and there's no root=.
Specify rootfstype=ramfs to get the old initramfs behavior.
The previous initramfs code provided a fairly crappy root filesystem:
didn't let you --bind mount directories out of it, reported zero
size/usage so it didn't
From: Rob Landley
When the rootfs code was a wrapper around ramfs, having them in the same
file made sense. Now that it can wrap another filesystem type, move it
in with the init code instead.
This also allows a subsequent patch to access rootfstype= command line arg.
Signed-off-by: Rob
On 05/22/2013 07:22 AM, Kirill A. Shutemov wrote:
> Dave Hansen wrote:
>>> + /*
>>> + * TODO: make ramfs pages movable
>>> +*/
>>> + mapping_set_gfp_mask(inode->i_mapping,
>>> +
Dave Hansen wrote:
> On 05/11/2013 06:23 PM, Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov"
> >
> > ramfs is the most simple fs from page cache point of view. Let's start
> > transparent huge page cache enabling here.
> >
> > For n
On 05/11/2013 06:23 PM, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> ramfs is the most simple fs from page cache point of view. Let's start
> transparent huge page cache enabling here.
>
> For now we allocate only non-movable huge page.
From: "Kirill A. Shutemov"
ramfs is the most simple fs from page cache point of view. Let's start
transparent huge page cache enabling here.
For now we allocate only non-movable huge page. ramfs pages cannot be
moved yet.
Signed-off-by: Kirill A. Shutemov
---
fs/ramfs
On Fri, 5 Apr 2013, Minchan Kim wrote:
> > >> How about add a knob?
> > >
> > >Maybe, volunteering?
> >
> > Hi Minchan,
> >
> > I can be the volunteer, what I care is if add a knob make sense?
>
> Frankly sepaking, I'd like to avoid new knob but there might be
> some workloads suffered from mlocke
From: "Kirill A. Shutemov"
ramfs is the most simple fs from page cache point of view. Let's start
transparent huge page cache enabling here.
For now we allocate only non-movable huge page. ramfs pages cannot be
moved yet.
Signed-off-by: Kirill A. Shutemov
---
fs/ramfs
>> >On Tue, Apr 02, 2013 at 03:15:23PM -0700, Hugh Dickins wrote:
> >> >>On Tue, 2 Apr 2013, Kirill A. Shutemov wrote:
> >> >>>Kirill A. Shutemov wrote:
> >> >>>>From: "Kirill A. Shutemov"
> >> >>>>
> &
:
> >>>>From: "Kirill A. Shutemov"
> >>>>
> >>>>ramfs is the most simple fs from page cache point of view. Let's start
> >>>>transparent huge page cache enabling here.
> >>>>
> >>>>For
Hi Minchan,
On 04/03/2013 09:11 AM, Minchan Kim wrote:
On Tue, Apr 02, 2013 at 03:15:23PM -0700, Hugh Dickins wrote:
On Tue, 2 Apr 2013, Kirill A. Shutemov wrote:
Kirill A. Shutemov wrote:
From: "Kirill A. Shutemov"
ramfs is the most simple fs from page cache point of view. L
similar but different isolate_lru_page().
Well the naming could be cleaned up. The fundamental issue with migrating
pages is that all references have to be tracked and updates in a way that
no references can be followed to invalid or stale page contents. If ramfs
does not maintain separate pointers but
On Tue, Apr 02, 2013 at 03:15:23PM -0700, Hugh Dickins wrote:
> On Tue, 2 Apr 2013, Kirill A. Shutemov wrote:
> > Kirill A. Shutemov wrote:
> > > From: "Kirill A. Shutemov"
> > >
> > > ramfs is the most simple fs from page cache point of view.
On Tue, 2 Apr 2013, Kirill A. Shutemov wrote:
> Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov"
> >
> > ramfs is the most simple fs from page cache point of view. Let's start
> > transparent huge page cache enabling here.
> >
> > Fo
Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> ramfs is the most simple fs from page cache point of view. Let's start
> transparent huge page cache enabling here.
>
> For now we allocate only non-movable huge page. It's not yet clear if
> m
From: "Kirill A. Shutemov"
ramfs is the most simple fs from page cache point of view. Let's start
transparent huge page cache enabling here.
For now we allocate only non-movable huge page. It's not yet clear if
movable page is safe here and what need to be done to make it
From: "Kirill A. Shutemov"
ramfs is the most simple fs from page cache point of view. Let's start
transparent huge page cache enabling here.
For now we allocate only non-movable huge page. It's not yet clear if
movable page is safe here and what need to be done to make it
Quoting Eric W. Biederman (ebied...@xmission.com):
> "Serge E. Hallyn" writes:
>
> > Quoting Eric W. Biederman (ebied...@xmission.com):
> >>
> >> There is no backing store to ramfs and file creation
> >> rules are the same as for any other fi
Quoting Eric W. Biederman (ebied...@xmission.com):
>
> There is no backing store to ramfs and file creation
> rules are the same as for any other filesystem so
> it is semantically safe to allow unprivileged users
> to mount it.
>
> The memory control group successfully lim
"Serge E. Hallyn" writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>>
>> There is no backing store to ramfs and file creation
>> rules are the same as for any other filesystem so
>> it is semantically safe to allow unprivileged users
>> t
Quoting Eric W. Biederman (ebied...@xmission.com):
>
> There is no backing store to ramfs and file creation
> rules are the same as for any other filesystem so
> it is semantically safe to allow unprivileged users
> to mount it.
>
> The memory control group successfully lim
There is no backing store to ramfs and file creation
rules are the same as for any other filesystem so
it is semantically safe to allow unprivileged users
to mount it.
The memory control group successfully limits how much
memory ramfs can consume on any system that cares about
a user namespace
ff-by: Bob Liu
Cc: Hugh Dickins
Cc: David Howells
Cc: Geert Uytterhoeven
Cc: Greg Ungerer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
fs/ramfs/file-nommu.c |1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ramfs/file-nommu.c b/fs/ramf
age().
Signed-off-by: Bob Liu
Cc: Hugh Dickins
Cc: David Howells
Cc: Geert Uytterhoeven
Cc: Greg Ungerer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/ramfs/file-nommu.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/ramfs/file-no
age().
Signed-off-by: Bob Liu
Cc: Hugh Dickins
Cc: David Howells
Cc: Geert Uytterhoeven
Cc: Greg Ungerer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/ramfs/file-nommu.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/ramfs/file-no
Adrian Bunk <[EMAIL PROTECTED]>
---
fs/ramfs/file-mmu.c |3 +++
fs/ramfs/internal.h |1 -
2 files changed, 3 insertions(+), 1 deletion(-)
157e8cf4ac47a1f31fb68273f09425fcbf7dbb0d diff --git a/fs/ramfs/file-mmu.c
b/fs/ramfs/file-mmu.c
index b41a514..9590b90 100644
--- a/fs/ramfs/file
V3 -> V4:
+ drivers/block/rd.c was replaced by brd.c in 24-rc4-mm1.
Update patch to add brd_open() to mark mapping as nonreclaimable
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series [no changes]
V1 -> V2:
+ add ramfs pages to this class of non-reclaimable pages by
V3 -> V4:
+ drivers/block/rd.c was replaced by brd.c in 24-rc4-mm1.
Update patch to add brd_open() to mark mapping as nonreclaimable
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series [no changes]
V1 -> V2:
+ add ramfs pages to this class of non-reclaimable pages by
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series [no changes]
V1 -> V2:
+ add ramfs pages to this class of non-reclaimable pages by
marking ramfs address_space [mapping] as non-reclaimble.
Christoph Lameter pointed out that ram disk pages also clutter the
LRU lists.
Latchesar Ionkov wrote:
Sample ramfs file server that uses the in-kernel 9P file server support.
This code is for reference only.
Reference code generally goes in Documentation/
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Sample ramfs file server that uses the in-kernel 9P file server support.
This code is for reference only.
Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>
---
net/9p/Kconfig |8 +-
net/9p/Makefile |1 +
net/9p/ramfs/ramfs.c
Prepare RAMFS for cred passing.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
fs/ramfs/inode.c | 16 ++--
include/linux/ramfs.h |3 ++-
mm/tiny-shmem.c |3 ++-
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/fs/ramfs/inode.c b/fs
Sample ramfs file server that uses the 9P in-kernel server implementation.
This code is for reference only, it is not supposed to be merged into the
kernel.
Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>
---
net/9p/srv/Kconfig |6 +
net/9p/srv/Makefile |4 +
net/9p/srv/r
The simplest file system to use for large blocksize support is ramfs.
Note that ramfs does not use the lower layers (buffer I/O etc) so this
case is useful for initial testing of changes to large buffer size
support if one just wants to exercise the higher layers.
The patch adds the ability to
The simplest file system to use for large blocksize support is ramfs.
Note that ramfs does not use the lower layers (buffer I/O etc) so this
case is useful for initial testing of changes to large buffer size
support if one just wants to exercise the higher layers.
The patch adds the ability to
Since CONFIG_RAMFS is currently hard-selected to "y", and since
Documentation/filesystems/ramfs-rootfs-initramfs.txt reads as follows:
"The amount of code required to implement ramfs is tiny, because all
the work is done by the existing Linux caching infrastructure.
Basically,
On Sat, Aug 25, 2007 at 05:40:00PM -0400, Robert P. J. Day wrote:
> On Sat, 25 Aug 2007, Al Viro wrote:
>
> > On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
> > >
> > > Allow RAMFS to be user-selectable, and to be built as a module.
> > >
On Sat, 25 Aug 2007, Al Viro wrote:
> On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
> >
> > Allow RAMFS to be user-selectable, and to be built as a module.
> >
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> >
> > ---
&
On Sat, 25 Aug 2007, Al Viro wrote:
> On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
> >
> > Allow RAMFS to be user-selectable, and to be built as a module.
> >
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> >
> > ---
&
On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
>
> Allow RAMFS to be user-selectable, and to be built as a module.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> given that the help content for that option suggests it
Allow RAMFS to be user-selectable, and to be built as a module.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
given that the help content for that option suggests it can be built
as a module, it just makes sense to make it selectable and tristate,
unless someone has a comp
to make it as simple as possible. The patch is primarily useful as
a debugging aid since it eliminates the lower layers from the game. I
think ramfs should be left as is sine it is intended as a minimal
implementation that should stay simpl.
If we really want such an option for good then it may be
1 - 100 of 303 matches
Mail list logo
