UML would need to free file-backed pages anonymously mapped from the host
memory. In all relevant cases, those pages are file-backed from tmpfs (or
ramfs, but that can also be excluded)
About this, I was thinking back to what Rik said in Ottawa at the OLS. He said
"just use madvise(DONTNEED) on
On Saturday 30 July 2005 18:02, Jeff Dike wrote:
> On Thu, Jul 28, 2005 at 08:56:53PM +0200, [EMAIL PROTECTED] wrote:
> > As obvious, a "core code nice cleanup" is not a "stability-friendly
> > patch" so usual care applies.
>
> These look reasonable, as they are what we discussed in Ottawa.
>
> I'l
On Tuesday 09 August 2005 15:47, Jeff Dike wrote:
> On Sun, Aug 07, 2005 at 03:57:48PM -0700, Anthony Brock wrote:
> > I've been encountering a "freeze" on shutdown with guest kernel
> > 2.6.12-rc5-mm1. Today, I was busy with other things so I left it frozen
> > for a while. When I returned, I saw
On Wed, Aug 10, 2005 at 09:36:43PM +0200, Blaisorblade wrote:
> About this, I was thinking back to what Rik said in Ottawa at the OLS. He
> said
> "just use madvise(DONTNEED) on it", but I remarked that the pages were
> file-backed.
> Actually, however, since backing store for tmpfs is just pag
I just ran through this article:
http://lwn.net/Articles/146973/
and it seems that it's dropping some of the early bits of s390 merge (I
guess). Note the mention to SUBARCH_PTRACE_SPECIAL - I guess that's there for
s390, right Bodo?
This patch is not going to be merged today, but it'll be soon
On Friday 12 August 2005 18:38, Jeff Dike wrote:
> On Wed, Aug 10, 2005 at 09:36:43PM +0200, Blaisorblade wrote:
> > About this, I was thinking back to what Rik said in Ottawa at the OLS. He
> > said "just use madvise(DONTNEED) on it", but I remarked that the pages
> > were file-backed.
> > Actual
>From our discussion yesterday, ...
On Fri, Jul 15, 2005 at 05:36:34PM +0200, Bodo Stroesser wrote:
> So I thought about avoiding the sigreturn at all. Working on
> this I found out some small points:
I kept this patch
> - there is a bug (typo) in wait_stub_done()
but dropped these two, plus my
On Wed, Aug 10, 2005 at 09:37:28PM +0200, Blaisorblade wrote:
> Just noticed: you can drop them (except the first, which is a nice cleanup).
>
> set_pte handles that, and include/asm-generic/pgtable.h uses coherently
> set_pte_at. I've checked UML by examining "grep pte", and either mk_pte or
>
On Fri, Aug 12, 2005 at 03:28:59PM +0200, Blaisorblade wrote:
> And the soft lockup you got during a kernel compile in Ottawa, in the room?
> Have you diagnosed that?
No. I still see it very occasionally. But it's nothing like it was before,
so I think there's something else which is happening
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
CC: Benjamin LaHaise <[EMAIL PROTECTED]>
Normally, activate_mm() is called from exec(), and thus it used to be a no-op
because we use a completely new "MM context" on the host (for instance, a new
process), and so we didn't need to flush an
On Fri, Aug 12, 2005 at 06:55:02PM +0200, Blaisorblade wrote:
> I just ran through this article:
>
> http://lwn.net/Articles/146973/
>
> and it seems that it's dropping some of the early bits of s390 merge (I
> guess). Note the mention to SUBARCH_PTRACE_SPECIAL - I guess that's there for
> s390
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
smp_entry_t -> swap_entry_t
Too short changelog entry?
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include/linux/swapops.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -pu
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Add the MAP_NOINHERIT flag to arch headers, for use with remap-file-pages.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include/asm-i386/mman.h |1 +
linux-2.6.git-paolo/include/asm-ia64
From: Ingo Molnar <[EMAIL PROTECTED]>
Since with remap_file_pages w/prot we may put PROT_NONE on a single PTE rather
than a VMA, we must handle that inside handle_mm_fault.
This value must be handled in the arch-specific fault handlers, and this
change must be ported to every arch on the world;
From: Ingo Molnar <[EMAIL PROTECTED]>
If we're not rearranging pages, support even PRIVATE vma.
This is needed to make MAP_POPULATE|MAP_PRIVATE to work, since it calls
remap_file_pages.
Notes from: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
We don't support private VMA because when the
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Add some more comments about page->mapping and swapper_space, explaining their
(historical and current) relationship. Such material can be extracted from the
old GIT history (which I used for reference), but having it in the source is
more
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Even now, we'll sometimes take the write lock. So, in that case, we could
downgrade it; after a tiny bit of thought, I've choosen doing that when we'll
either do any I/O or we'll alter a lot of PTEs. About how much "a lot" is,
I've copied
_PAGE_FILE does not indicate whether a file is in page / swap cache, it is set
just for non-linear PTE's. Correct the comment for i386, x86_64, UML. Also
clearify _PAGE_NONE.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include/asm-i386/pgtable.h |
From: Ingo Molnar <[EMAIL PROTECTED]>, Paolo 'Blaisorblade' Giarrusso <[EMAIL
PROTECTED]>
This is the "main" patch for the syscall code, containing the core of what was
sent by Ingo Molnar, variously reworked.
Differently from his patch, I've *not* added a new syscall, choosing to add a
new fla
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Assume that even after dropping and reacquiring the lock, (vma->vm_flags &
VM_SHARED) won't change, thus moving a check earlier.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/mm/fremap.c | 12
Update pte encoding macros for i386 and x86-64.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include/asm-i386/pgtable-2level.h | 15 ++-
linux-2.6.git-paolo/include/asm-i386/pgtable-3level.h | 11 ++-
linux-2.6.git-paolo/inclu
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Seems like on 2.4.9.4 this comment got out of sync ;-)
I'm not completely sure on which basis we don't need any more to do as the
comment suggests, but it seems that when faulting in a second time the same
swap page, can_share_swap_page()
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Either shmem_getpage returns a failure, or it found a page, or it was told it
couldn't do any I/O. So it's useless to check nonblock in the else branch. We
could add a BUG() there but I preferred to comment the offending function.
This was
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
The arch handler used to check itself protection, now we must possibly move
that to the generic VM if the VMA is non-uniform.
For now, do_file_page installs the PTE and doesn't check the fault type, if it
was wrong, then it'll do another f
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
If !vma->vm-ops we already BUG above, so retesting it is useless. The compiler
cannot optimize this because BUG is a macro and is not thus marked noreturn;
that should possibly be fixed.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAI
Update pte encoding macros for UML.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include/asm-um/pgtable-2level.h | 15 ++
linux-2.6.git-paolo/include/asm-um/pgtable-3level.h | 21 +++-
2 files changed, 27 insertions(+)
Recover one bit by additionally using _PAGE_NEWPROT. Since I wasn't sure this
would work, I've split this out. We rely on the fact that pte_newprot always
checks first if the PTE is marked present.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Add an optimization to install_file_pte: if the VMA is uniform, and the PTE
was null, it will be installed correctly if needed at fault time - we avoid
thus touching the page tables, but we must still do the walk...
I'd like to avoid doing
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Since proper support requires that the arch at the very least handles
VM_FAULT_SIGSEGV, as in next patch (otherwise the arch may BUG), and things
are even more complex (see next patches), and it's triggerable only with
VM_NONUNIFORM vma's,
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Avoid chomping low bits of address for functions doing it by themselves, fix
whitespace, add a correctness checking.
I did this for remap-file-pages protection support, it was useful on its own
too.
Signed-off-by: Paolo 'Blaisorblade' Gia
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Distinguish between "normal" VMA and VMA with non-uniform protection. This
will be also useful for fault handling (we must ignore VM_{READ,WRITE,EXEC} in
the arch fault handler).
As said before, with remap-file-pages-prot, we must punt on
Ok, I've been working for the past two weeks learning well the Linux VM,
understanding the Ingo's remap_file_pages protection support and its various
weakness (due to lack of time on his part), and splitting and finishing it.
Here follow a series of 39 _little_ patches against the git-commit-id
Please do not BOMB linux-kernel with 39 patches in one
go, that will kill the list server.
Try to consolidate your patch groups into smaller pieces,
like so about 10 or 15 at a time. And send any that remain
on some later date.
---
SF.Net ema
On Saturday 30 July 2005 18:02, Jeff Dike wrote:
> On Thu, Jul 28, 2005 at 08:56:53PM +0200, [EMAIL PROTECTED] wrote:
> > As obvious, a "core code nice cleanup" is not a "stability-friendly
> > patch" so usual care applies.
> These look reasonable, as they are what we discussed in Ottawa.
> I'll
On Sunday 17 July 2005 09:52, Alex LIU wrote:
> On 16 July 2005, Blaisorblade wrote:
> > Hmm, but where's the caller to return? In most cases it won't exist. I
> > don't understand what's your purpose, and the behaviour you'd want to
> > reproduce. Sorry, but *which* userspace should it go to? What
From: Ingo Molnar <[EMAIL PROTECTED]>
PPC32 bits of RFP - as in original patch.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include/asm-ppc/pgtable.h | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff -puN include/asm-p
From: Ingo Molnar <[EMAIL PROTECTED]>, Paolo 'Blaisorblade' Giarrusso <[EMAIL
PROTECTED]>
This "fast-path" was contained in the original
remap-file-pages-prot-2.6.4-rc1-mm1-A1.patch from Ingo Molnar; I think this
code is wrong, but I'm sending it for review anyway, because I'm unsure (and
in fac
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
For linear VMA's, there is no need to install pte_file PTEs to remember the
offset. We could probably go as far as checking directly the address and
protection like in include/linux/pagemap.h:set_nonlinear_pte(), instead of
vma->vm_flags. A
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Use -EOVERFLOW ("Value too large for defined data type") rather than -EINVAL
when we cannot store the file offset in the PTE.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/mm/fremap.c |2 +-
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
This optimization avoid looking up pages for PROT_NONE mappings. The idea was
taken from the "wrong "historical" code for review - 1" one (the next one)
from mingo, but I fixed it, by adding another "detail" parameter. I've also
fixed the o
From: Martin Schwidefsky <[EMAIL PROTECTED]>
s390 memory management changes for remap-file-pages-prot patch:
- Add pgoff_prot_to_pte/pte_to_pgprot, remove pgoff_to_pte (required for
'prot' parameteter in shared-writeable mappings).
- Handle VM_FAULT_SIGSEGV from handle_mm_fault in do_exceptio
From: Ingo Molnar <[EMAIL PROTECTED]>, Paolo 'Blaisorblade' Giarrusso <[EMAIL
PROTECTED]>
This "fast-path" was contained in the original
remap-file-pages-prot-2.6.4-rc1-mm1-A1.patch from Ingo Molnar*; I think this
code is wrong, but I'm sending it for review anyway, because I'm unsure (and
in fa
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
We got unflushed PTE's marked up-to-date, because they were protected to get
dirtying / accessing faults. So, don't test the PTE for being up-to-date, but
check directly the permission (since the PTE is not protected for that).
Signed-off-
From: Ingo Molnar <[EMAIL PROTECTED]>
I've attached a 'blind' port of the prot bits of fremap to ia64. I've
compiled it with a cross-compiler but otherwise it's untested. (and it's
very likely i got the pte bits wrong - but it's roughly OK.)
This should at least make ia64 compile.
Signed-off-
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Yet to test. Currently we install a PTE when one is missing
irrispective of the fault type, and if the access type is prohibited we'll
get another fault and kill the process only then. With this, we check the
access type on the 1st fault.
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
When installing pages on non-uniform VMA's, even for read faults we must
install them writable if the VMA is writable (we won't have a chance to fix
that). Normally, on write faults, we install the PTE as dirty (there's a
comment about 8038
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
This adapts the changes to the i386 handler to the UML one. It isn't enough to
make UML work, however, because UML has some peculiarities. Subsequent patches
fix this.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Actually, with the current model, we should get a failure with VMA's mapped
with only PROT_WRITE (even if I wasn't able to verify that in UML, which has
similar code).
To test!
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECT
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Simplify the generic arch permission checking: the previous one was clumsy, as
it didn't account arch-specific implications (read implies exec, write implies
read, and so on).
Still to undo fixes for the archs (i386 and UML) which were mod
From: Paul Mackerras <[EMAIL PROTECTED]>
When I tried -mm4 on a ppc32 box, it hit a BUG because I hadn't excluded
_PAGE_FILE from the bits used for swap entries. While looking at that I
realised that the pte_to_pgoff and pgoff_prot_to_pte macros were wrong for
4xx and 8xx (embedded) PPC chips, s
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Uml is particular in respect with other architectures (and possibly this is to
fix) in the fact that our arch fault handler handles indifferently both TLB
and page faults. In particular, we may get to call handle_mm_fault() when the
PTE is
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
When unmapping linear but non uniform VMA's in try_to_unmap_one, we must
encode the prots in the PTE.
However, we shouldn't use the generic set_nonlinear_pte() function as it
allows for nonlinear offsets, on which we should instead BUG() i
From: William Lee Irwin III <[EMAIL PROTECTED]>
Implement remap_file_pages-with-per-page-protections for sparc64.
See
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4/2.6.4-mm1/broken-out/remap-file-pages-prot-2.6.4-rc1-mm1-A1.patch
and
ftp://ftp.kernel.org/pub/linux/kernel
From: Paul Mackerras <[EMAIL PROTECTED]>
ppc64 bits for remap_file_pages w/prot (no syscall table).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.git-paolo/include/asm-ppc64/pgtable.h | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff
On Friday 12 August 2005 20:29, David S. Miller wrote:
> Please do not BOMB linux-kernel with 39 patches in one
> go, that will kill the list server.
> Try to consolidate your patch groups into smaller pieces,
> like so about 10 or 15 at a time. And send any that remain
> on some later date.
Whoo
From: Blaisorblade <[EMAIL PROTECTED]>
Date: Fri, 12 Aug 2005 20:56:11 +0200
> However, I sent the initial tarball containing all them, so I hope
> that will be useful.
So not only did you spam the list with 40 patch postings,
you sent a second copy of everything as a tarball attachment
as well.
% linux
Checking for the skas3 patch in the host...not found
Checking for /proc/mm...not found
tracing thread pid = 8456
Checking for /dev/anon on the host...Not available (open failed with errno 2)
Checking for /dev/anon on the host...Not available (open failed with errno 2)
Checking for /dev/anon
On Fri, Aug 12, 2005 at 08:21:23PM +0200, [EMAIL PROTECTED] wrote:
> From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
>
> Add the MAP_NOINHERIT flag to arch headers, for use with remap-file-pages.
Does this mean ARM will break when these patches are merged?
> Signed-off-by: Paolo 'Blaiso
On Fri, Aug 12, 2005 at 12:32:28AM +0200, Bodo Stroesser wrote:
> Hi,
>
> attached is a tarball containing a small series of patches, that apply
> on linux-2.6.13-rc5 + incremental patches from Jeff.
In my tree, thanks.
Do you have a list of my patches that are required for this to reach
mainlin
59 matches
Mail list logo
