data structure with
> embedded spinlock, the lock holder has a better chance of
> making progress.
>
> Signed-off-by: Rik van Riel
Looks fine to me other than the arbitrary-ness of 50
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fu
On Fri, Dec 21, 2012 at 3:50 PM, Rik van Riel wrote:
> diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
> index 33692ea..2a45eb0 100644
> --- a/arch/x86/include/asm/spinlock.h
> +++ b/arch/x86/include/asm/spinlock.h
> @@ -34,6 +34,8 @@
> # define UNLOCK_LOCK_PREFIX
>
On Fri, Dec 21, 2012 at 5:09 PM, Andy Lutomirski wrote:
> On Fri, Dec 21, 2012 at 4:59 PM, Michel Lespinasse wrote:
>> On Fri, Dec 21, 2012 at 4:36 PM, Andy Lutomirski wrote:
>>> Something's buggy here. My evil test case is stuck with lots of
>>> thre
On Fri, Dec 21, 2012 at 4:36 PM, Andy Lutomirski wrote:
> On Thu, Dec 20, 2012 at 4:49 PM, Michel Lespinasse wrote:
>> We have many vma manipulation functions that are fast in the typical case,
>> but can optionally be instructed to populate an unbounded number of ptes
>> w
20, 2012 at 4:49 PM, Michel Lespinasse wrote:
> We have many vma manipulation functions that are fast in the typical case,
> but can optionally be instructed to populate an unbounded number of ptes
> within the region they work on:
> - mmap with MAP_POPULATE or MAP_
mapping is also one that the user has
requested (using MAP_SHARED, MAP_LOCKED or mlock) to be populated.
Signed-off-by: Michel Lespinasse
---
include/linux/mm.h |1 +
include/linux/mman.h |4 +++-
mm/fremap.c | 12 ++--
mm/mlock.c | 19 ++-
mm
ause MAP_POPULATE wasn't being passed to
mmap_region().
The desired behavior is that we want the pages to be populated and locked
if the vma is marked as VM_LOCKED, or to be populated if the MAP_NONBLOCK
flag is not passed to remap_file_pages().
Signed-off-by: Michel Lespinasse
---
mm/fr
After the MAP_POPULATE handling has been moved to mmap_region() call sites,
the only remaining use of the flags argument is to pass the MAP_NORESERVE
flag. This can be just as easily handled by do_mmap_pgoff(), so do that
and remove the mmap_region() flags parameter.
Signed-off-by: Michel
n't release the mmap_sem
while allocating new stack pages. This is deemed acceptable, because the
stack vmas grow by a bounded number of pages at a time, and these are
anon pages so we don't have to read from disk to populate them.
Signed-off-by: Michel Lespinasse
---
include/linux/mm.
Signed-off-by: Michel Lespinasse
---
mm/mremap.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 1b61c2d3307a..c5a8bf344b1f 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -208,7 +208,7 @@ unsigned long
Signed-off-by: Michel Lespinasse
---
mm/mmap.c | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index a16fc499dbd1..4c8d39e64e80 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -240,6 +240,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk
-by: Andy Lutomirski
Signed-off-by: Michel Lespinasse
---
fs/aio.c |6 +-
include/linux/mm.h | 18 +++---
ipc/shm.c | 12 +++-
mm/mlock.c | 17 +++--
mm/mmap.c | 20 +++-
mm/nommu.c |5
Signed-off-by: Michel Lespinasse
---
mm/fremap.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/mm/fremap.c b/mm/fremap.c
index 2db886e31044..b42e32171530 100644
--- a/mm/fremap.c
+++ b/mm/fremap.c
@@ -129,6 +129,7 @@ SYSCALL_DEFINE5
On most architectures, def_flags is either 0 or VM_LOCKED depending on
whether mlockall(MCL_FUTURE) was called. However, this is not an absolute
rule as kvm support on s390 may set the VM_NOHUGEPAGE flag in def_flags.
We don't want mlockall to clear that.
Signed-off-by: Michel Lespi
while we're trying to populate them. It adds a new VM_POPULATE flag
on the mappings we do want to populate, so that if userspace replaces
them with mappings it doesn't want populated, mm_populate() won't
populate those replacement mappings.
Michel Lespinasse (9):
mm: make ml
Hi Simon,
On Wed, Dec 19, 2012 at 5:56 PM, Simon Jeons wrote:
> One question.
>
> I found that mainly callsite of expand_stack() is #PF, but it holds
> mmap_sem each time before call expand_stack(), how can hold a *shared*
> mmap_sem happen?
the #PF handler calls down_read(&mm->mmap_sem) before
On Sun, Dec 16, 2012 at 10:05 AM, Andy Lutomirski wrote:
> On Sun, Dec 16, 2012 at 4:39 AM, Michel Lespinasse wrote:
>> My main concern is that just downgrading the mmap_sem only hides the
>> problem: as soon as a writer gets queued on that mmap_sem,
>> reader/writer fairnes
On Fri, Dec 14, 2012 at 6:17 PM, Andy Lutomirski wrote:
> This is a serious cause of mmap_sem contention. MAP_POPULATE
> and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> Changes from v1:
>
> The non-unlocking versions of do_mma
gt; On Sat, Nov 24, 2012 at 9:40 PM, Michel Lespinasse wrote:
>>> On Thu, Nov 22, 2012 at 9:49 PM, Michel Lespinasse
>>> wrote:
>>>> On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin
>>>> wrote:
>>>>> The following patch fixed the problem
On Sun, Dec 2, 2012 at 7:12 AM, Ingo Molnar wrote:
> Subject: [PATCH] mm/rmap, migration: Make rmap_walk_anon() and
> try_to_unmap_anon() more scalable
>
> rmap_walk_anon() and try_to_unmap_anon() appears to be too
> careful about locking the anon vma: while it needs protection
> against anon vma
k during stack expansion is
expected to be small: glibc doesn't use expandable stacks for the
threads it creates, so having multiple growable stacks is actually
uncommon and we don't expect the page table lock to get bounced
between threads.
Signed-off-by: Michel Lespinasse
---
we mutex_lock()ed we'll now down_write().
Looks good.
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
ou forgot to rename anon_vma_unlock() too.
But really, this is nitpicking. I like the idea behind the patch, and
after giving it a close look, I couldn't find anything wrong with it.
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged
On Mon, Dec 3, 2012 at 6:17 AM, Mel Gorman wrote:
> On Sat, Dec 01, 2012 at 09:15:38PM +0100, Ingo Molnar wrote:
>> @@ -732,7 +732,7 @@ static int page_referenced_anon(struct p
>> struct anon_vma_chain *avc;
>> int referenced = 0;
>>
>> - anon_vma = page_lock_anon_vma(page);
>> +
On Mon, Dec 3, 2012 at 3:01 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 22:56:27 -0800
> Michel Lespinasse wrote:
>
>> expand_stack() runs with a shared mmap_sem lock. Because of this, there
>> could be multiple concurrent stack expansions in the same mm, which may
>
n a given mm would share the same anon_vma, which we
already lock here. However this turned out to be difficult - all of the
schemes I tried for refcounting the growable anon_vma and clearing
turned out ugly. So, I'm now proposing only the minimal fix.
Signed-off-by: Michel Lespinasse
---
m
On Mon, Nov 26, 2012 at 5:16 PM, Sasha Levin wrote:
> I've built today's -next, and got the following BUG pretty quickly (2-3
> hours):
>
> [ 1556.479284] BUG: unable to handle kernel paging request at 00412000
> [ 1556.480036] IP: [] validate_mm+0x34/0x130
> [ 1556.480036] PGD 31739067 P
Since nothing depends on the max_high field values anymore, we can just
remove the field and the code that was used to maintain it.
Signed-off-by: Michel Lespinasse
---
tools/kvm/include/kvm/rbtree-interval.h | 13 ---
tools/kvm/util/rbtree-interval.c| 58
As the rbtree intervals are not overlapping, rb_int_search_single can
trivially be implemented without making use of the max_high field.
Signed-off-by: Michel Lespinasse
---
tools/kvm/util/rbtree-interval.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
diff
x27; could trigger an
integer overflow which would break the rbtree ordering.
Signed-off-by: Michel Lespinasse
---
tools/kvm/util/rbtree-interval.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/kvm/util/rbtree-interval.c b/tools/kvm/util/rbtree-interv
On Thu, Nov 22, 2012 at 9:49 PM, Michel Lespinasse wrote:
> On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin wrote:
>> The following patch fixed the problem for me:
>>
>> diff --git a/include/linux/rbtree_augmented.h
>> b/include/linux/rbtree_augmented.h
>> index
On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin wrote:
> Hi Michel,
>
> I've noticed a bug regarding search of ioports in the KVM tool. Since the KVM
> tool is
> using kernel's augmented rbtree implementation to represent an interval
> rbtree I dug a
> bit into the new implementation in the kernel,
gt; include/linux/compiler.h | 32 +--
> 5 files changed, 76 insertions(+), 42 deletions(-)
>
> Changes in v6:
> o Remove extraneous double negation
> o Fixed faulty macro expansion in last patch
Acked-by: Michel Lespinasse on the entire v6 series.
On Sat, Nov 17, 2012 at 1:53 PM, Shentino wrote:
> I'm actually curious if the architecture docs/software developer
> manuals for IA-32 mandate any TLB invalidations on a #PF
>
> Is there any official vendor documentation on the subject?
Yes. Quoting a prior email:
Actually, it is architected on
On Fri, Nov 9, 2012 at 6:13 AM, Sasha Levin wrote:
> While fuzzing with trinity inside a KVM tools (lkvm) guest, using today's
> -next
> kernel, I'm getting these:
>
> [ 117.007714] free gap 7fba0dd1c000, correct 7fba0dcfb000
> [ 117.019773] map_count 750 rb -1
> [ 117.028362] [ cu
updated,
and we want to make sure vma_rb_erase() runs before there are any
such stale rb_subtree_gap values in the rbtree.
(I don't know of a reproduceable test case for this particular issue)
Signed-off-by: Michel Lespinasse
---
mm/mmap.c |6 +++---
1 files changed, 3 insertions(+), 3 del
ap_update() would
fail to propagate the rb_subtree_gap updates as high up as necessary.
Signed-off-by: Michel Lespinasse
---
mm/mmap.c | 88 ++---
1 files changed, 55 insertions(+), 33 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index c
Levin for uncovering the problem and to Hugh Dickins
for coming up with a simpler test case)
Reported-by: Sasha Levin
Signed-off-by: Michel Lespinasse
---
mm/mmap.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 6
e exception that
the node being erased doesn't need to have an up to date rb_subtree_gap.
These 3 patches apply on top of the stack I previously sent (or equally,
on top of the last published mmotm).
Michel Lespinasse (3):
mm: ensure safe rb_subtree_gap update when inserting new VMA
mm: e
On Fri, Nov 9, 2012 at 11:33 PM, Al Viro wrote:
> Could you verify that this on top of for-next gets the things working again?
> It's a very lazy way to deal with that (we don't want to bother with
> restoring extras, at the very least), but the rest can go separately (and
> is shared with mainlin
On Fri, Nov 9, 2012 at 9:33 PM, Al Viro wrote:
> On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
>> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
>> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> >> Hi,
>> >>
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
> On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> Hi,
>>
>> I'm having an issue booting current linux-next kernels on my test
>> machines. Userspace crashes when it's supposed to pivot
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the loglevel=8 kernel parameter, the last messages I see are:
Checking root filesystem in pivot_root init.
[6.252717] usb 2-1: link qh256-0001/
this
> function)
> arch/tile/mm/hugetlbpage.c:256:20: note: each undeclared identifier is
> reported only once for each function it appears in
commit 86234092170b43771c3f6257cb320ff6e2c10c52
Author: Michel Lespinasse
Date: Thu Nov 8 22:13:58 2012 -0800
fix mm: use vm_unmapped_
reported only once for
> each function it appears in
commit 34550b95185c1ecfa8882664744c14edda385868
Author: Michel Lespinasse
Date: Thu Nov 8 22:14:34 2012 -0800
fix mm: augment vma rbtree with rb_subtree_gap
diff --git a/mm/mmap.c b/mm/mmap.c
index d12c69eaf23f..0b8f9d83e2e2 100644
-
ap.c:60:16: warning: unused variable 'start_addr'
> [-Wunused-variable]
>
> Introduced by commit "mm: use vm_unmapped_area() on arm architecture".
Sorry for the mistakes. The following changes should fix what's been reported
so far.
commit 1c98949798ce7a1d4a910775
On Tue, Nov 6, 2012 at 12:24 AM, Michel Lespinasse wrote:
> On Mon, Nov 5, 2012 at 5:41 AM, Michel Lespinasse wrote:
>> On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wrote:
>>> On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote:
>>>> Hmm, I attached a simple
On Mon, Nov 5, 2012 at 5:41 AM, Michel Lespinasse wrote:
> On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wrote:
>> On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote:
>>> Hmm, I attached a simple fix patch.
>>
>> Reviewed-by: Michel Lespinasse
>> (also ran s
Adding Sasha and Bob, which I forgot to CC in the original message.
On Mon, Nov 5, 2012 at 3:06 PM, Rik van Riel wrote:
> On 11/05/2012 05:46 PM, Michel Lespinasse wrote:
>>
>> Iterate vma->anon_vma_chain without anon_vma_lock may cause NULL ptr deref
>> in
>>
On Mon, Nov 5, 2012 at 5:25 PM, David Miller wrote:
> From: Michel Lespinasse
> Date: Mon, 5 Nov 2012 14:47:12 -0800
>
>> Update the sparc32 arch_get_unmapped_area function to make use of
>> vm_unmapped_area() instead of implementing a brute force search.
>>
>>
: Bob Liu
Signed-off-by: Michel Lespinasse
---
mm/mmap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 2d942353d681..9a796c41e7d9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -334,8 +334,10 @@ void validate_mm(struct mm_struct *mm)
h the desired arguments is quite shorter than
duplicating the brute force algorithm all over the place. There is
still a bit of repetition between various implementations of
arch_get_unmapped_area[_topdown] functions that could probably be
simplified somehow, but I feel we can keep that for a lat
tree walk is in the first cache line.
Signed-off-by: Michel Lespinasse
Signed-off-by: Rik van Riel
---
include/linux/mm_types.h | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 94fa52b28ee8..528da4abf8ee
gap length
- low/high address limits that the gap must fit into
- alignment mask and offset
Also update the generic arch_get_unmapped_area[_topdown] functions to
make use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van
A mmaps the file with pgoff 0, and program B mmaps the
file with pgoff 1. The old code would align the mmaps, resulting in
misaligned pages:
A: 0123
B: 123
After this patch, they are aligned so the pages line up:
A: 0123
B: 123
Signed-off-by: Michel Lespinasse
Proposed-by: Rik van Riel
Update the i386 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/x86/mm/hugetlbpage.c | 130 +
1 files changed, 25 insertions(+), 105
Update the arm arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/arm/mm/mmap.c | 119 ++--
1 files changed, 23 insertions(+), 96
Update the hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
fs/hugetlbfs/inode.c | 42 --
1 files changed, 8 insertions(+), 34 deletions(-)
diff
Update the x86_64 arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
---
arch/x86/include/asm/elf.h |6 +-
arch/x86/kernel/sys_x86_64.c | 151
When CONFIG_DEBUG_VM_RB is enabled, check that rb_subtree_gap is
correctly set for every vma and that mm->highest_vm_end is also correct.
Also add an explicit 'bug' variable to track if browse_rb() detected any
invalid condition.
Signed-off-by: Michel Lespinasse
Reviewed-by:
eck if the following gap is suitable.
This does have the potential to make unmapping VMAs more expensive,
especially for processes with very large numbers of VMAs, where the
VMA rbtree can grow quite deep.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
---
include/linux/mm_types.
Update the mips arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/mips/mm/mmap.c | 99 +--
1 files changed, 17 insertions(+), 82
Update the sparc64 arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sparc/kernel/sys_sparc_64.c | 132 +-
1 files changed, 30 insertions
Update the sparc64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sparc/mm/hugetlbpage.c | 123 ++
1 files changed, 30 insertions(+), 93
Update the sh arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sh/mm/mmap.c | 126 ++---
1 files changed, 24 insertions(+), 102
Update the tile hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/tile/mm/hugetlbpage.c | 139
1 files changed, 25 insertions(+), 114
Update the sparc32 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sparc/kernel/sys_sparc_32.c | 24 +---
1 files changed, 9 insertions(+), 15 deletions(-)
diff
On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wrote:
> On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote:
>> Hmm, I attached a simple fix patch.
>
> Reviewed-by: Michel Lespinasse
> (also ran some tests with it, but I could never reproduce the original
> issue anyway).
W
On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote:
> Hmm, I attached a simple fix patch.
Reviewed-by: Michel Lespinasse
(also ran some tests with it, but I could never reproduce the original
issue anyway).
Bob, it would be easier if you had sent the original patch inline
rather than as
On Sun, Nov 4, 2012 at 6:20 PM, Bob Liu wrote:
> The loop for each entry of vma->anon_vma_chain in validate_mm() is not
> protected by anon_vma lock.
> I think that may be the cause.
>
> Michel, What's your opinion？
Good catch, I think that's it. Somehow it had not occured to me to
verify the che
On Fri, Oct 26, 2012 at 5:48 AM, Andi Kleen wrote:
> Michel Lespinasse writes:
>
>> On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
>> wrote:
>>> On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
>>>>
>>>> That may not even be needed.
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
wrote:
> On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
>>
>> That may not even be needed. Apparently Intel chips
>> automatically flush an entry from the TLB when it
>> causes a page fault. I assume AMD chips do the same,
>> because flush_t
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
> ‘__attribute__’ before ‘void’
>
> This patch includes linux/compiler.h in rbtree_augmented.h so that the
> __always_inline macro is resolved correctly.
>
> Cc: Pekka Enberg
> Cc: Michel Lespinasse
> Cc: Ingo Molnar
> Signed-off-by: Will
On Fri, Oct 19, 2012 at 4:41 AM, Peter Zijlstra wrote:
> On Thu, 2012-10-18 at 17:20 -0400, Rik van Riel wrote:
>> Having the function name indicate what the function is used
>> for makes the code a little easier to read. Furthermore,
>> the fault handling code largely consists of do__page
>>
#include somehow got duplicated on its way to linus's tree
(probably as a conflict resolution as things got sent through multiple trees)
Signed-off-by: Michel Lespinasse
---
tools/perf/util/include/linux/rbtree.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/
On Wed, Oct 3, 2012 at 7:46 AM, Daniel Santos wrote:
> On 10/03/2012 09:01 AM, Steven Rostedt wrote:
>> You don't need to use get_maintainers. It's more of a help tool to find
>> maintainers and not something that is mandatory. Not everyone that has
>> ever touched one of these files needs to be C
On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos wrote:
> BUILD_BUG_ON42(arg)
> BUILD_BUG_ON_CONST42(arg)
>
> Prior to gcc 4.2, the optimizer was unable to determine that many
> constant values stored in structs were indeed compile-time constants and
> optimize them out. Sometimes, it will find an
On Fri, Sep 28, 2012 at 4:20 PM, Daniel Santos wrote:
> Negative sized arrays wont create a compile-time error in some cases
> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> the error function attribute that will. This patch modifies
> BUILD_BUG_ON to behave like BUILD_
> is reflected.
>
> Reported-by: Hugh Dickens
> Signed-off-by: David Rientjes
Looks good, thanks!
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "u
On Fri, Sep 14, 2012 at 3:46 PM, Michel Lespinasse wrote:
> On Fri, Sep 14, 2012 at 3:14 PM, Sasha Levin wrote:
>> On 09/04/2012 11:20 AM, Michel Lespinasse wrote:
>>> Add a CONFIG_DEBUG_VM_RB build option for the previously existing
>>> DEBUG_MM_RB code. Now that Andi
On Fri, Sep 14, 2012 at 3:14 PM, Sasha Levin wrote:
> On 09/04/2012 11:20 AM, Michel Lespinasse wrote:
>> Add a CONFIG_DEBUG_VM_RB build option for the previously existing
>> DEBUG_MM_RB code. Now that Andi Kleen modified it to avoid using
>> recursive algorithms, we can
On Thu, Sep 13, 2012 at 11:14 AM, Jiri Slaby wrote:
> Hi,
>
> I've just get the following BUG with today's -next. It happens every
> time I try to update packages.
>
> kernel BUG at mm/huge_memory.c:1428!
That is very likely my bug.
Do you have the message that should be printed right above the
On Fri, Sep 07, 2012 at 03:55:14PM -0700, Andrew Morton wrote:
> On Fri, 7 Sep 2012 15:29:36 -0700
> Michel Lespinasse wrote:
>
> > > Ho hum. I don't think I can be bothered untangling all this.
> >
> > I don't think you should have to do it yourself e
On Fri, Sep 07, 2012 at 03:55:14PM -0700, Andrew Morton wrote:
> On Fri, 7 Sep 2012 15:29:36 -0700
> Michel Lespinasse wrote:
>
> > > Ho hum. I don't think I can be bothered untangling all this.
> >
> > I don't think you should have to do it yourself e
On Fri, Sep 7, 2012 at 3:13 PM, Andrew Morton wrote:
> On Tue, 4 Sep 2012 02:20:51 -0700
> Michel Lespinasse wrote:
>
>> This commit updates the generic interval tree code that was
>> introduced in "mm: replace vma prio_tree with an interval tree".
>>
>
pdate, so there is no chance that
rmap would miss the vmas that are being updated.
Change-Id: I6a6127d3c1fc1ab4af2acfc7ed2d269b963f6792
Signed-off-by: Michel Lespinasse
---
include/linux/mm.h | 14 +
include/linux/rmap.h | 11 ---
mm/huge_memory.c |5 ++-
mm/interv
On Tue, Sep 4, 2012 at 3:16 PM, Andrea Arcangeli wrote:
> I would suggest to do the strict fix as above in as patch 1/8 and push
> it in -mm, and to do only the optimization removal in 3/8. I think
> we want it in -stable too later, so it'll make life easier to
> cherry-pick the commit if it's mer
On Tue, Sep 04, 2012 at 04:27:45PM +0200, Andrea Arcangeli wrote:
> Hi Michel,
>
> On Tue, Sep 04, 2012 at 02:20:52AM -0700, Michel Lespinasse wrote:
> > This change fixes an anon_vma locking issue in the following situation:
> > - vma has no anon_vma
> > - next has an
the
nonlinear and interval tree cases, with vma_interval_tree_insert_after()
which handles only the interval tree case and has an API that is more
consistent with the other interval tree handling functions.
The nonlinear case is now handled explicitly in kernel/fork.c dup_mmap().
Signed-off-b
_vma_moveto_tail() ordering function with proper anon_vma locking
in move_ptes(). Once we have the anon interval tree in place, we will
re-introduce an optimization to avoid taking these locks in the most
common cases.
Signed-off-by: Michel Lespinasse
---
include/linux/rmap.h |1 -
mm/mmap.c
s locked during the update, so there is no chance that
rmap would miss the vmas that are being updated.
Signed-off-by: Michel Lespinasse
---
include/linux/mm.h | 14
include/linux/rmap.h | 11 +
mm/huge_memory.c |5 ++-
mm/interval_tree.c | 14 +++
goffs have not changed since the
nodes were inserted on the anon vma interval tree (as it is important
that the nodes be reindexed after each such update).
Signed-off-by: Michel Lespinasse
---
include/linux/mm.h |3 +++
include/linux/rmap.h |3 +++
lib/Kconfig.debug|9
ies resolved in tree insertion order.
Signed-off-by: Michel Lespinasse
---
fs/exec.c |2 +-
include/linux/mm.h |6 +++-
mm/mmap.c |7 -
mm/mremap.c| 57 +++
4 files changed, 49 insertions(+), 23 deletions(-
Signed-off-by: Michel Lespinasse
---
mm/huge_memory.c |4
mm/rmap.c| 48 +---
2 files changed, 21 insertions(+), 31 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index fe119cb71b41..91b65f962320 100644
--- a/mm/huge_memo
xt is being expanded.
This change also removes an optimization which avoided taking anon_vma
lock during brk adjustments. We could probably make that optimization
work again, but the following anon rmap change would break it,
so I kept things as simple as possible here.
Signed-off-by: Michel Lespi
original location. I don't expect this
to be very frequent, though, so move_ptes() should be as efficient as it
was before patch 3 for all likely cases.
Michel Lespinasse (7):
mm: interval tree updates
mm: fix potential anon_vma locking issue in mprotect()
mm anon rmap: remove anon_vma_m
On Fri, Aug 31, 2012 at 1:35 AM, Adrian Hunter wrote:
> On 31/08/12 11:15, Andrew Morton wrote:
>> On Fri, 31 Aug 2012 01:07:24 -0700 Michel Lespinasse
>> wrote:
>>> I thought Andrew had a patch
>>> rbtree-adjust-root-color-in-rb_insert_color-only-when-necess
On Fri, Aug 31, 2012 at 1:01 AM, Adrian Hunter wrote:
> This breaks tools/perf build in linux-next:
>
> ../../lib/rbtree.c: In function 'rb_insert_color':
> ../../lib/rbtree.c:95:9: error: 'true' undeclared (first use in this function)
> ../../lib/rbtree.c:95:9: note: each undeclared identifier is
On Thu, Aug 30, 2012 at 2:34 PM, Andrew Morton
wrote:
> On Tue, 7 Aug 2012 00:25:38 -0700
> Michel Lespinasse wrote:
>
>> This patchset goes over the rbtree changes that have been already integrated
>> into Andrew's -mm tree, as well as the augmented rbtree prop
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
> Instead of adding an atomic count for page references, we could limit
> the anon_vma stacking depth. In fork, we would only clone anon_vmas
> that have a low enough generation count. I think that's not great
>
401 - 500 of 610 matches
Mail list logo
