Added slightly more detail to the Documentation of merge_across_nodes,
a few comments in areas indicated by review, and renamed get_ksm_page()'s
argument from locked to lock_it. No functional change.
Signed-off-by: Hugh Dickins hu...@google.com
---
Documentation/vm/ksm.txt | 16
is generally better, I'd
rather be consistent with what's done in the stable tree: accept a page
from the wrong NUMA node for comparison, but not as a leaf for merging.
Signed-off-by: Hugh Dickins hu...@google.com
---
mm/ksm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions
): now we must remove tree_rmap_item
from its unstable tree there, before overwriting nid. No need to spatter
BUG()s around: we'd be seeing oopses if this were wrong.
Signed-off-by: Hugh Dickins hu...@google.com
---
mm/ksm.c | 26 ++
1 file changed, 14 insertions(+), 12
that every follow_page() caller is prepared to
sleep - ia64's xencomm_vtop()? Now, THP's wait_split_huge_page() can
already sleep there, since anon_vma locking was changed to mutex, but
maybe that's somehow excluded.
Signed-off-by: Hugh Dickins hu...@google.com
---
include/linux/mm.h |1 +
mm/ksm.c
it with
page != swapcache.
Signed-off-by: Hugh Dickins hu...@google.com
---
mm/swapfile.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- mmotm.orig/mm/swapfile.c2013-02-20 22:28:09.076001048 -0800
+++ mmotm/mm/swapfile.c 2013-02-20 23:20:50.872076192 -0800
@@ -874,11
I dislike the way in which swapcache gets used in do_swap_page():
there is always a page from swapcache there (even if maybe uncached
by the time we lock it), but tests are made according to swapcache.
Rework that with page != swapcache, as has been done in unuse_pte().
Signed-off-by: Hugh
statically allocated, then if merge_across_nodes is
ever tuned, allocate for nr_node_ids+nr_node_ids. Do not attempt to
free up the extra if it's tuned back, that would be a waste of effort.
Signed-off-by: Hugh Dickins hu...@google.com
---
mm/ksm.c | 72
On Thu, 21 Feb 2013, Johannes Weiner wrote:
On Thu, Feb 21, 2013 at 12:25:40AM -0800, Hugh Dickins wrote:
Before establishing that KSM page migration was the cause of my
WARN_ON_ONCE(page_mapped(page))s, I suspected that they came from the
lack of a ksm_might_need_to_copy() in swapoff's
On Fri, 22 Feb 2013, Ric Mason wrote:
On 02/21/2013 04:17 PM, Hugh Dickins wrote:
Here's a second KSM series, based on mmotm 2013-02-19-17-20: partly in
response to Mel's review feedback, partly fixes to issues that I found
myself in doing more review and testing. None of the issues fixed
On Fri, 22 Feb 2013, Ric Mason wrote:
What's the root reason merge_across_nodes setting just can be changed only
when there are no ksm shared pages in system?
Simplicity. Why add code (moving nodes from tree to tree, handling
the collisions) for a rare case that doesn't need to be fast?
On Fri, 22 Feb 2013, Ric Mason wrote:
On 02/21/2013 04:20 PM, Hugh Dickins wrote:
An inconsistency emerged in reviewing the NUMA node changes to KSM:
when meeting a page from the wrong NUMA node in a stable tree, we say
that it's okay for comparisons, but not as a leaf for merging; whereas
the code, and I think we've lost the
SIGBUS thing.
It would be easier to follow the route from -nopage observing offset
beyond EOF through to delivery of the SIGBUS if filemap_nopage were
to say NOPAGE_SIGBUS, rather than the NULL that's defined to be.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED
On Thu, 25 Aug 2005, Linus Torvalds wrote:
On Fri, 26 Aug 2005, Nick Piggin wrote:
Skipping MAP_SHARED in fork() sounds like a good idea to me...
Indeed. Linus, can you remember why we haven't done this before?
Hmm. Historical reasons. Also, if the child ends up needing it, it will
On Fri, 26 Aug 2005, Ross Biro wrote:
On 8/26/05, Hugh Dickins [EMAIL PROTECTED] wrote:
The refaulting will hurt the performance of something: let's
just hope that something doesn't turn out to be a show-stopper.
Why not just fault in all the pages on the first fault
On Fri, 26 Aug 2005, Linus Torvalds wrote:
On Fri, 26 Aug 2005, Hugh Dickins wrote:
I see some flaws in the various patches posted, including Rik's.
Here's another version - doing it inside copy_page_range, so this
kind of vma special-casing is over in mm/ rather than kernel/.
I like
On Fri, 26 Aug 2005, Ross Biro wrote:
On 8/26/05, Rik van Riel [EMAIL PROTECTED] wrote:
Filling in all the page table entries at the first fault to
a VMA doesn't make much sense, IMHO.
I suspect we would be better off without that extra complexity,
unless there is a demonstrated
On Fri, 26 Aug 2005, Blaisorblade wrote:
On Wednesday 24 August 2005 15:26, Hugh Dickins wrote:
If do_swap_page gets
a write fault, it either determines it can go ahead and use the swap
page, or if it can't, gets do_wp_page to Copy-On-Write for it (that's
a call I added in 2.6.7
On Fri, 26 Aug 2005, Blaisorblade wrote:
This is a followup to my post of last week (Aug 12) about remap_file_pages
protection support. I've improved and consolidated the patches and updated
them against 2.6.13-rc6/rc7 (the same patches apply against both versions).
I'm sending the full
On Sun, 28 Aug 2005, Nick Piggin wrote:
This is the condition I ended up with. Any good?
if (!(vma-vm_flags (VM_HUGETLB|VM_NONLINEAR|VM_RESERVED))) {
if (vma-vm_flags VM_MAYSHARE)
return 0;
if (vma-vm_file !vma-anon_vma)
return 0;
}
It's not bad, and practical timings are
On Tue, 30 Aug 2005, Dave McCracken wrote:
This patch implements page table sharing for all shared memory regions that
span an entire page table page. It supports sharing at multiple page
levels, depending on the architecture.
Performance testing has shown no degradation with this patch
On Wed, 31 Aug 2005, Arjan van de Ven wrote:
On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote:
I was going to say, doesn't randomize_va_space take away the rest of
the point? But no, it appears randomize_va_space, as it currently
appears in mainline anyway, is somewhat an exaggeration
On Wed, 31 Aug 2005, Martin J. Bligh wrote:
--Hugh Dickins [EMAIL PROTECTED] wrote (on Wednesday, August 31, 2005
14:42:38 +0100):
Which is indeed a further disincentive against shared page tables.
Or shared pagetables a disincentive to randomizing the mmap space ;-)
Fair point
On Fri, 2 Sep 2005, Jim Cromie wrote:
during boot, kernel get caught in a hi-speed loop, issuing these msgs.
from the logs, it appears that the 'repeated' catcher is getting overwhelmed,
perhaps by message trucation which breaks the pattern.
Ive edited large chunks of repeats that made it
On Fri, 26 Aug 2005, Blaisorblade wrote:
* The first 2 patches modify the PTE encoding macros and start preparing the
VM for the new situation (i.e. VMA which have variable protections, which are
called VM_NONUNIFORM. I dropped the early VM_MANYPROTS name).
What a pity: please revert.
On Fri, 2 Sep 2005, Jeff Dike wrote:
On Wed, Aug 10, 2005 at 09:37:28PM +0200, Blaisorblade wrote:
Also look, on the set_pte theme, at the attached patch.
+ WARN_ON(!pte_young(*pte) || pte_write(*pte) !pte_dirty(*pte));
This one has been firing on me, and I decided to figure out
On Wed, 10 Aug 2005, Daniel Phillips wrote:
On Tuesday 09 August 2005 10:15, Nick Piggin wrote:
Daniel Phillips wrote:
Why don't you pass the vma in zap_details?
Possibly. I initially did it that way, but it ended up fattening
paths that don't use details.
It should not, it only
On Wed, 10 Aug 2005, Daniel Phillips wrote:
--- 2.6.13-rc5-mm1.clean/include/linux/page-flags.h 2005-08-09
18:23:31.0 -0400
+++ 2.6.13-rc5-mm1/include/linux/page-flags.h 2005-08-09 18:59:57.0
-0400
@@ -61,7 +61,7 @@
#define PG_active 6
#define PG_slab
On Wed, 10 Aug 2005, Gleb Natapov wrote:
On Tue, Aug 09, 2005 at 07:13:33PM +0100, Hugh Dickins wrote:
Even more I'd prefer one of these two solutions below, which sidestep
that uncleanliness - but both of these would be in mmap only, no clean
way to change afterwards (except by munmap
On Wed, 10 Aug 2005, Gleb Natapov wrote:
On Wed, Aug 10, 2005 at 02:22:40PM +0100, Hugh Dickins wrote:
Your stack example is a good one: if we end up setting VM_DONTCOPY on
the user stack, then I don't think fork's child will get very far without
hitting a SIGSEGV.
I know, but I
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
at http://sosdg.org/~coywolf/lxr/source/include/linux/mm.h#L561
Should the comment be s/page_mapped/page-mapping/ ?
No.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Thu, 11 Aug 2005, Gleb Natapov wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages belonging to the vma on fork instead of mark
them as cow?
It's a pretty good idea, and thanks for reminding us of it.
It suffers from the general
On Thu, 11 Aug 2005, Gleb Natapov wrote:
On Thu, Aug 11, 2005 at 03:04:29PM +0100, Hugh Dickins wrote:
On Thu, 11 Aug 2005, Gleb Natapov wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages belonging to the vma on fork instead
On Fri, 12 Aug 2005, David Howells wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
I'm just requesting that you base your stuff on my patch that's already in
-mm. The names in there are already in use, though not currently in the -mm
patch (the patches that use it have been temporarily
On Thu, 11 Aug 2005, Steven Rostedt wrote:
Found the problem. It is a bug with mmap_kmem. The order of checks is
wrong, so here's the patch.
- if (!pfn_valid(vma-vm_pgoff))
- return -EIO;
val = (u64)vma-vm_pgoff PAGE_SHIFT;
vma-vm_pgoff = __pa(val)
On Tue, 23 Aug 2005, Ulrich Drepper wrote:
One possible solution would be to add a flag to mremap() which allows
mremap() to steal memory. In general that would be too dangerous but we
could limit it to private, anonymous mappings which have no access
permissions (i.e., PROT_NONE with
On Tue, 23 Aug 2005, Ulrich Drepper wrote:
Linus Torvalds wrote:
Actually, it should be pretty much as valid as using mremap - ie it works
on Linux.
Especially if you use MAP_SHARED, you don't even need to mprotect
anything: you'll get a nice SIGBUS if you ever try to access past
On Wed, 24 Jan 2007, Chris Rankin wrote:
Personally, I dumped 2.6.19.x like a hot coal as soon as I tripped over this
bug:
http://bugzilla.kernel.org/show_bug.cgi?id=7707
I didn't take much to trigger it, either. But the silence has been deafening.
Oh, the page_remove_rmap BUG,
On Wed, 24 Jan 2007, Chris Rankin wrote:
But MY kernel is clearly untainted.
So what other explanation is there apart from a kernel bug?
If it's me you're asking: I don't know (overheating, cosmic rays, ...)
Hugh
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Wed, 24 Jan 2007, Chris Rankin wrote:
I suppose what I'm *really* asking is what the basis is for assuming that
this *isn't* a kernel
bug and can therefore be safely ignored, seeing as the oops is real, the
hardware is fine and the
kernel is untainted? That seems to cover the bases
On Tue, 23 Jan 2007, yunfeng zhang wrote:
re-code my patch, tab = 8. Sorry!
Please stop resending this patch until you can attend to the advice
you've been given: Pavel made several very useful remarks on Monday:
No, this is not the way to submit major rewrite of swap subsystem.
You need to
On Thu, 25 Jan 2007, Adam Litke wrote:
When expanding the stack, we don't currently check if the VMA will cross into
an area of the address space that is reserved for hugetlb pages. Subsequent
faults on the expanded portion of such a VMA will confuse the low-level MMU
code, resulting in an
On Fri, 26 Jan 2007, Ken Chen wrote:
On 1/26/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Less trivial (and I wonder whether you've come to this from an ia64
or a powerpc direction): I notice that ia64 has more stringent REGION
checks in its ia64_do_page_fault, before calling expand_stack
) window in which old_page might be
truncated, freed, and reused in the same position.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/memory.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- 2.6.20-rc6/mm/memory.c 2007-01-25 08:25:27.0 +
+++ linux/mm/memory.c
On Sun, 28 Jan 2007, Ken Chen wrote:
For ia64, the hugetlb address region is reserved at the top of user
space address. Stacks are below that region. Throw in the mix, we
have two stacks, one memory stack that grows down and one register
stack backing store that grows up. These two stacks
On Mon, 29 Jan 2007, Ingo Molnar wrote:
For every 64-bit Fedora box there's more than seven 32-bit boxes. I
think 32-bit is going to live with us far longer than many thought, so
we might as well make it work better. Both HIGHMEM and HIGHPTE is the
default on many distro kernels, which
On Thu, 4 Jan 2007, Michael Tokarev wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
Because it would be (a very small amount of) work and bloat to
support O_DIRECT on tmpfs; because that work didn't seem
On Wed, 3 Jan 2007, Andrew Morton wrote:
On Wed, 03 Jan 2007 22:56:07 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
It'd odd that stories of pre-2.6.19 BerkeleyDB corruption are now coming
out of the woodwork. It's the first I've ever heard
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache used by
other applications. An application which writes a large quantity of data will
have less impact on other applications by using O_DIRECT, assuming that the
data will not be
pdflush hit the BUG_ON(!PageSlab(page)) in kmem_freepages called from
fallback_alloc: cache_grow already freed those pages when alloc_slabmgmt
failed. But it wouldn't have freed them if __GFP_NO_GROW, so make sure
fallback_alloc doesn't waste its time on that case.
Signed-off-by: Hugh Dickins
On Thu, 4 Jan 2007, Pekka Enberg wrote:
Hi Hugh,
[Sorry, no access to kernel tree right now, so can't send a patch.]
On 1/4/07, Hugh Dickins [EMAIL PROTECTED] wrote:
@@ -3310,7 +3310,7 @@ retry:
*/
goto
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded. Perhaps I'm
out of date: when O_DIRECT came in, just a few filesystems supported
it, and it was
On Thu, 4 Jan 2007, Greg KH wrote:
On Sat, Dec 30, 2006 at 02:47:20AM -0800, Miles Lane wrote:
Sorry Andrew, I am not sure which maintainer to contact about this. I
CCed gregkh for sysfs and Yi for ipw2200. Hopefully this is helpful.
BTW, I also found that none of my network drivers were
On Fri, 5 Jan 2007, Kay Sievers wrote:
But anyway, Kay, I thought that 10.2 would work with
CONFIG_SYSFS_DEPRECATED=y?
Yes, HAL, udev, NetworkManager, ... from 10.2 works fine here, without
that option set.
I'm using ifplugd rather than NetworkManager: would that affect it?
Hugh
-
To
moment, but that doesn't really matter).
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Will be needed in 2.6.19-stable too.
mm/oom_kill.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- 2.6.20-rc3/mm/oom_kill.c2007-01-01 10:30:46.0 +
+++ linux/mm
On Fri, 5 Jan 2007, Pekka J Enberg wrote:
Here's an alternative fix for the double-free bug you hit. I have only
compile-tested this on NUMA so can you please confirm it fixes the problem
for you? Thanks.
It looks nice, and I'm giving it a spin: though hardly worth waiting
a week or so to
There's a lot of gaps in my understanding, but I think 2.6.20-rc's
59287c0913cc9a6c75712a775f6c1c1ef418ef3b (randomize PIE binaries)
needs to be reverted for now.
Running any 2.6.20-rc kernel on i386 openSUSE 10.2, my kernel builds
occasionally fail with an ld.so error when building some .o or
On Sat, 6 Jan 2007, Sami Farin wrote:
Linux 2.6.19.1 SMP [2] on Pentium D...
I was running dt-15.14 [2] and I ran
cinfo datafile (it does mincore()).
Well it went OK but when I ran strace cinfo datafile...:
04:18:48.062466 mincore(0x37f1f000, 2147266560,
You rightly noted in a followup
On Sat, 6 Jan 2007, David Brownell wrote:
On Saturday 06 January 2007 3:26 pm, Philippe De Muyter wrote:
The way it is done currently
in drivers/rtc/hctosys.c is 0.5 sec off. We could obtain a much better
precision by looping there until the next change (next second for old
clocks,
On Sat, 6 Jan 2007, David Brownell wrote:
Hmm ... looping fights against quickly; as would wait for next
update IRQ (on RTCs that support that). But it would improve precision,
at least in the sense of having the system clock and that RTC spending
less time with the lowest seconds
On Mon, 8 Jan 2007, Richard Purdie wrote:
Improve the error handling when writes fail to a swap page.
Currently, the kernel will repeatedly retry the write which is unlikely
to ever succeed. Instead we allow the pages to be unused and then marked
as bad at which prevents reuse. It should
On Mon, 8 Jan 2007, Hua Zhong wrote:
A while ago there was a discussion about supporting direct-io on tmpfs.
Ah, I think I can just about remember that... ;)
Here is a simple patch that does it.
Looks more likely to work than Ken's - which I didn't try,
but I couldn't see what magic
Please revert the yenta free_irq on suspend patch (below)
which went into 2.6.13-rc4 after 2.6.13-rc3-git9.
Sorry Daniel, you may have a box on which resume doesn't work without
it, but on my laptop APM resume from RAM now fails to work because of
it - locks up solid. The patch sounded rather
On Fri, 29 Jul 2005, Frank van Maarseveen wrote:
2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
I think your problem is this: HT has depended on CONFIG_ACPI for
some while, and now in 2.6.13-rc CONFIG_ACPI depends on CONFIG_PM.
You don't have CONFIG_PM set in your .config (nor had
Fix scheduling while atomic messages below do_anonymous_page when
CONFIG_HIGHPTE=y: must unmap and remap the page_table around page
allocation. And let's shift the usual pte_unmap to the minor_fault exit.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Please don't interpret this fix as my
On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
Well, the patch is needed on other boxes too (eg. mine :-)) due to the recent
changes in ACPI.
Could you please send the /proc/interrupts from your box?
CPU0
0:2818513 XT-PIC timer
1: 56790
On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
On Saturday, 30 of July 2005 23:32, Hugh Dickins wrote:
On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
Could you please send the /proc/interrupts from your box?
11: 57443 XT-PIC yenta, yenta, eth0
Thanks. It looks like
On Mon, 1 Aug 2005, Linus Torvalds wrote:
that continue will continue without the spinlock held, and now do
Yes, I was at last about to reply on that point and others.
I'll make those comments in a separate mail to Nick and all.
Instead, I'd suggest changing the logic for lookup_write. Make
On Mon, 1 Aug 2005, Nick Piggin wrote:
Ingo Molnar wrote:
Hugh's posting said:
it's trying to avoid an endless loop of finding the pte not writable
when ptrace is modifying a page which the user is currently protected
against writing to (setting a breakpoint in readonly text,
On Mon, 1 Aug 2005, Nick Piggin wrote:
This was tested by Robin and appears to solve the problem. Roland
had a quick look and thought the basic idea was sound. I'd like to
get a couple more acks before going forward, and in particular
Robin was contemplating possible efficiency improvements
On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
On Sunday, 31 of July 2005 01:09, Rafael J. Wysocki wrote:
Linus has apparently dropped that patch for yenta, but in case it is
reintroduced in the future you will probably need a patch to make the
network
driver cooperate. I'll try to
On Mon, 1 Aug 2005, Andrew Morton wrote:
static inline int handle_mm_fault(...)
{
int ret = __handle_mm_fault(...);
if (unlikely(ret == VM_FAULT_RACE))
ret = VM_FAULT_MINOR;
return ret;
}
because VM_FAULT_RACE is some internal private thing.
It does add
On Mon, 1 Aug 2005, Linus Torvalds wrote:
On Mon, 1 Aug 2005, Hugh Dickins wrote:
Aside, that brings up an interesting question - why should readonly
mappings of writeable files (with VM_MAYWRITE set) disallow ptrace
write access while readonly mappings of readonly files not? Or am I
On Tue, 2 Aug 2005, Martin Schwidefsky wrote:
Why do we require the !pte_dirty(pte) check? I don't get it. If a writeable
clean pte is just fine then why do we check the dirty bit at all? Doesn't
pte_dirty() imply pte_write()?
Not quite. This is all about the peculiar ptrace case, which
On Tue, 2 Aug 2005, Linus Torvalds wrote:
On the other hand, this being s390, maybe nobody cares?
You have a cruel streak.
But have I just realized a non-s390 problem with your pte_dirty
technique? The ptep_set_wrprotect in fork's copy_one_pte.
That's specifically write-protecting the pte
On Tue, 2 Aug 2005, Linus Torvalds wrote:
On Tue, 2 Aug 2005, Hugh Dickins wrote:
But have I just realized a non-s390 problem with your pte_dirty
technique? The ptep_set_wrprotect in fork's copy_one_pte.
That's specifically write-protecting the pte to force COW, but leaving
On Tue, 2 Aug 2005, Linus Torvalds wrote:
Since we will have dropped the page table lock when calling
handle_mm_fault() (which will just re-get the lock and then drop it
again) _and_ since we don't actually mark the page dirty if it was
writable, it's entirely possible that the VM scanner
On Tue, 2 Aug 2005, Linus Torvalds wrote:
On Tue, 2 Aug 2005, Hugh Dickins wrote:
It might not be so bad. It's going to access the struct page anyway.
And clearing dirty from parent and child at fork time could save two
set_page_dirtys at exit time. But I'm not sure that we could batch
needed, another do_wp_page will follow.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.13-rc5/include/linux/mm.h 2005-08-02 12:07:14.0 +0100
+++ linux/include/linux/mm.h2005-08-02 21:14:58.0 +0100
@@ -629,6 +629,9 @@ static inline int page_mapped(struct pag
that: in rare case it's needed, another do_wp_page will follow.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.13-rc5/include/linux/mm.h 2005-08-02 12:07:14.0 +0100
+++ linux/include/linux/mm.h2005-08-02 21:14:58.0 +0100
@@ -629,6 +629,9 @@ static inline int page_mapped
On Wed, 3 Aug 2005, Nick Piggin wrote:
Hugh Dickins wrote:
Here we are: get_user_pages quite untested, let alone the racy case,
but I think it should work. Please all hack it around as you see fit,
I'll check mail when I get home, but won't be very responsive...
Seems OK to me. I
On Wed, 3 Aug 2005, Martin Schwidefsky wrote:
Hugh Dickins [EMAIL PROTECTED] wrote on 08/02/2005 10:55:31 PM:
Here we are: get_user_pages quite untested, let alone the racy case,
Ahh, just tested it and everythings seems to work (even for s390)..
I'm happy :-)
Thanks for testing, Martin
On Wed, 3 Aug 2005, Linus Torvalds wrote:
Ok, I applied this because it was reasonably pretty and I liked the
approach. It seems buggy, though, since it was using switch () to test
the bits (wrongly, afaik), and I'm going to apply the appended on top of
it. Holler quickly if you
On Thu, 4 Aug 2005, Robin Holt wrote:
On Wed, Aug 03, 2005 at 12:31:34PM +0100, Hugh Dickins wrote:
On Wed, 3 Aug 2005, Robin Holt wrote:
On Mon, Aug 01, 2005 at 11:18:42AM -0700, Linus Torvalds wrote:
Can somebody who saw the problem in the first place please verify?
OK. I took
On Thu, 4 Aug 2005, Andi Kleen wrote:
I noticed that even 64bit architectures have a ridiculously low
max limit on shared memory segments by default:
#define SHMMAX 0x200 /* max shared seg size (bytes) */
#define SHMMNI 4096 /* max num of segs
On Thu, 4 Aug 2005, Matti Aarnio wrote:
SHM resources are non-swappable, thus I would not by default
let user programs go and allocate very much SHM spaces at all.
No, SHM resources are swappable.
Hugh
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
and MAJOR are the only ones 0.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.13-rc5-git2/arch/arm/mm/fault.c 2005-08-02 12:06:28.0 +0100
+++ linux/arch/arm/mm/fault.c 2005-08-04 16:06:57.0 +0100
@@ -240,8 +240,11 @@ do_page_fault(unsigned long addr, unsign
- worth including in 2.6.13, though not yet confirmed that
it fixes that specific report from Frank van Maarseveen.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.13-rc5-git2/mm/mremap.c 2005-06-17 20:48:29.0 +0100
+++ linux/mm/mremap.c 2005-08-03 16:22:33.0 +0100
@@ -229,6
On Thu, 5 Aug 2005, Andi Kleen wrote:
[EMAIL PROTECTED] (Danny ter Haar) writes:
Freeing unused kernel memory: 248k freed
VM: killing process hotplug
VM: killing process hotplug
VM: killing process hotplug
VM: killing process hotplug
Unable to handle kernel paging request at
.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.13-rc5-git3/mm/madvise.c2005-08-02 12:07:23.0 +0100
+++ linux/mm/madvise.c 2005-08-05 18:06:47.0 +0100
@@ -37,7 +37,7 @@ static long madvise_behavior(struct vm_a
if (new_flags == vma-vm_flags
On Fri, 5 Aug 2005, Dominik Karall wrote:
On Friday 05 August 2005 17:22, Ingo Molnar wrote:
please enable CONFIG_FRAME_POINTERS!
I'm sorry, but I think I can't enable CONFIG_FRAME_POINTERS.
Depends on: DEBUG_KERNEL (X86 !X86_64 || CRIS || M68K || M68KNOMMU ||
FRV || UML)
Seems to
On Fri, 5 Aug 2005, Prasanna Meda wrote:
Hugh Dickins wrote:
2. Correct initial value of prev when starting part way into a vma: as
in sys_mprotect and do_mlock, it needs to be set to vma in this case
(vma_merge handles only that minimum of cases shown in its comments
On Mon, 8 Aug 2005, Dipankar Sarma wrote:
On Wed, Aug 03, 2005 at 09:56:44AM +1000, Andrew Morton forwarded from Hugh:
Subject: two 2.6.13-rc3-mm3 oddities
One time my tmpfs-and-looped-tmpfs-kernel-builds collapsed with lots of
VFS: file-max limit 49778 reached
messages, which I
On Tue, 9 Aug 2005, Russell King wrote:
On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
That would work for swsusp, but there are other users that want to
know if a struct page is valid ram (eg. ioremap), so in that case
swsusp would not be able to mess with the flag.
The
On Tue, 9 Aug 2005, Nick Piggin wrote:
Hugh Dickins wrote:
I think Nick is treating the use of PageReserved in ioremap much too
reverentially. Fine to leave its removal from there to a later stage,
but why shouldn't that also be removed?
Well, as far as I had been able to gather
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
What we don't have is something to indicate the page does not point
to valid ram.
I have no problem keeping PG_reserved for that, and _ONLY_ for that.
Yes, if a table won't suffice.
(though i'd rather see it renamed then).
Definitely.
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
ioremap is making a similar check to the one remap_pfn_range used
to make; but I see no good reason for it at all. ioremap should be
allowed to map whatever the caller asked, just as memset is allowed
to set whatever the caller asked.
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
But you don't mind if they are refcounted, do you?
Just so long as they start out from 1 so never get freed.
Well, a refcounting bug would let them be freed and kaboom ... That's
why a PG_not_your_ram_dammit bit would be useful. It could
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
On Tue, 2005-08-09 at 15:50 +0100, Hugh Dickins wrote:
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
Well, a refcounting bug would let them be freed and kaboom ... That's
why a PG_not_your_ram_dammit bit would be useful. It could
Sorry for my delay in replying...
On Tue, 26 Jul 2005, Michael S. Tsirkin wrote:
Quoting Hugh Dickins [EMAIL PROTECTED]:
Subject: Re: [PATCH repost] PROT_DONTCOPY: ifiniband uverbs fork support
On Mon, 25 Jul 2005, Michael S. Tsirkin wrote:
This patch adds PROT_DONTCOPY to mmap
On Sat, 16 Dec 2006, Martin Michlmayr wrote:
* Marc Haber [EMAIL PROTECTED] [2006-12-09 10:26]:
Unfortunately, I am lacking the knowledge needed to do this in an
informed way. I am neither familiar enough with git nor do I possess
the necessary C powers.
I wonder if what you're seein is
601 - 700 of 4042 matches
Mail list logo
