Currently __vma_unlink_common handles two cases:
* has_prev
* or not
When has_prev is false, it is obvious prev is calculated from
vma->vm_prev in __vma_unlink_common.
When has_prev is true, the prev is passed through from __vma_unlink_prev
in __vma_adjust for non-case 8. And at the beginning next is calculated
from vma->vm_next, which implies vma is next->vm_prev.
The above statement sounds a little complicated, while to think in
another point of view, no matter whether vma and next is swapped, the
mmap link list still preserves its property. It is proper to access
vma->vm_prev.
Signed-off-by: Wei Yang <[email protected]>
---
mm/mmap.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index b8072630766f..3d56340fea36 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -675,23 +675,17 @@ static void __insert_vm_struct(struct mm_struct *mm, struct vm_area_struct *vma)
static __always_inline void __vma_unlink_common(struct mm_struct *mm,
struct vm_area_struct *vma,
- struct vm_area_struct *prev,
- bool has_prev,
struct vm_area_struct *ignore)
{
- struct vm_area_struct *next;
+ struct vm_area_struct *prev, *next;
vma_rb_erase_ignore(vma, &mm->mm_rb, ignore);
next = vma->vm_next;
- if (has_prev)
+ prev = vma->vm_prev;
+ if (prev)
prev->vm_next = next;
- else {
- prev = vma->vm_prev;
- if (prev)
- prev->vm_next = next;
- else
- mm->mmap = next;
- }
+ else
+ mm->mmap = next;
if (next)
next->vm_prev = prev;
@@ -703,7 +697,7 @@ static inline void __vma_unlink_prev(struct mm_struct *mm,
struct vm_area_struct *vma,
struct vm_area_struct *prev)
{
- __vma_unlink_common(mm, vma, prev, true, vma);
+ __vma_unlink_common(mm, vma, vma);
}
/*
@@ -891,7 +885,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
* "next" (which is stored in post-swap()
* "vma").
*/
- __vma_unlink_common(mm, next, NULL, false, vma);
+ __vma_unlink_common(mm, next, vma);
if (file)
__remove_shared_vm_struct(next, file, mapping);
} else if (insert) {
--
2.17.1
Just make the code a little easy to read.
Signed-off-by: Wei Yang <[email protected]>
---
Note: For nommu part, the code is not tested.
---
mm/internal.h | 1 +
mm/mmap.c | 12 +-----------
mm/nommu.c | 8 +-------
mm/util.c | 14 ++++++++++++++
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index 41a49574acc3..4736aeb37dae 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -291,6 +291,7 @@ static inline bool is_data_mapping(vm_flags_t flags)
/* mm/util.c */
void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
struct vm_area_struct *prev);
+void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma);
#ifdef CONFIG_MMU
extern long populate_vma_page_range(struct vm_area_struct *vma,
diff --git a/mm/mmap.c b/mm/mmap.c
index 3fde0ec18554..aa66753b175e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -677,18 +677,8 @@ static __always_inline void __vma_unlink_common(struct mm_struct *mm,
struct vm_area_struct *vma,
struct vm_area_struct *ignore)
{
- struct vm_area_struct *prev, *next;
-
vma_rb_erase_ignore(vma, &mm->mm_rb, ignore);
- next = vma->vm_next;
- prev = vma->vm_prev;
- if (prev)
- prev->vm_next = next;
- else
- mm->mmap = next;
- if (next)
- next->vm_prev = prev;
-
+ __vma_unlink_list(mm, vma);
/* Kill the cache */
vmacache_invalidate(mm);
}
diff --git a/mm/nommu.c b/mm/nommu.c
index 12a66fbeb988..1a403f65b99e 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -673,13 +673,7 @@ static void delete_vma_from_mm(struct vm_area_struct *vma)
/* remove from the MM's tree and list */
rb_erase(&vma->vm_rb, &mm->mm_rb);
- if (vma->vm_prev)
- vma->vm_prev->vm_next = vma->vm_next;
- else
- mm->mmap = vma->vm_next;
-
- if (vma->vm_next)
- vma->vm_next->vm_prev = vma->vm_prev;
+ __vma_unlink_list(mm, vma);
}
/*
diff --git a/mm/util.c b/mm/util.c
index 80632db29247..5f113cd0acad 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -281,6 +281,20 @@ void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
next->vm_prev = vma;
}
+void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma)
+{
+ struct vm_area_struct *prev, *next;
+
+ next = vma->vm_next;
+ prev = vma->vm_prev;
+ if (prev)
+ prev->vm_next = next;
+ else
+ mm->mmap = next;
+ if (next)
+ next->vm_prev = prev;
+}
+
/* Check if the vma is being used as a stack by this task */
int vma_is_stack_for_current(struct vm_area_struct *vma)
{
--
2.17.1
The third parameter of __vma_unlink_common could differentiate these two
types. __vma_unlink_prev is not necessary now.
Signed-off-by: Wei Yang <[email protected]>
---
mm/mmap.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 3d56340fea36..3fde0ec18554 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -693,13 +693,6 @@ static __always_inline void __vma_unlink_common(struct mm_struct *mm,
vmacache_invalidate(mm);
}
-static inline void __vma_unlink_prev(struct mm_struct *mm,
- struct vm_area_struct *vma,
- struct vm_area_struct *prev)
-{
- __vma_unlink_common(mm, vma, vma);
-}
-
/*
* We cannot adjust vm_start, vm_end, vm_pgoff fields of a vma that
* is already present in an i_mmap tree without adjusting the tree.
@@ -874,7 +867,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
* us to remove next before dropping the locks.
*/
if (remove_next != 3)
- __vma_unlink_prev(mm, next, vma);
+ __vma_unlink_common(mm, next, next);
else
/*
* vma is not before next if they've been
--
2.17.1
Btw, is there any good reason we don't use a list_head for vma linkage?
On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>Btw, is there any good reason we don't use a list_head for vma linkage?
Not sure, maybe there is some historical reason?
--
Wei Yang
Help you, Help me
On 8/14/19 8:57 AM, Wei Yang wrote:
> On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>>Btw, is there any good reason we don't use a list_head for vma linkage?
>
> Not sure, maybe there is some historical reason?
Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
list be doubly linked") and I guess it was just simpler to add the vm_prev link.
Conversion to list_head might be an interesting project for some "advanced
beginner" in the kernel :)
On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>On 8/14/19 8:57 AM, Wei Yang wrote:
>> On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>>>Btw, is there any good reason we don't use a list_head for vma linkage?
>>
>> Not sure, maybe there is some historical reason?
>
>Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>
>Conversion to list_head might be an interesting project for some "advanced
>beginner" in the kernel :)
Seems it will touch many code ...
--
Wei Yang
Help you, Help me
On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
> On 8/14/19 8:57 AM, Wei Yang wrote:
> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
> >>Btw, is there any good reason we don't use a list_head for vma linkage?
> >
> > Not sure, maybe there is some historical reason?
>
> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>
> Conversion to list_head might be an interesting project for some "advanced
> beginner" in the kernel :)
I'm working to get rid of vm_prev and vm_next, so it would probably be
wasted effort.
On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
>On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>> On 8/14/19 8:57 AM, Wei Yang wrote:
>> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>> >>Btw, is there any good reason we don't use a list_head for vma linkage?
>> >
>> > Not sure, maybe there is some historical reason?
>>
>> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>>
>> Conversion to list_head might be an interesting project for some "advanced
>> beginner" in the kernel :)
>
>I'm working to get rid of vm_prev and vm_next, so it would probably be
>wasted effort.
You mean replace it with list_head?
--
Wei Yang
Help you, Help me
On Tue, Aug 20, 2019 at 05:54:17PM -0700, Matthew Wilcox wrote:
>On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
>> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
>> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>> >> On 8/14/19 8:57 AM, Wei Yang wrote:
>> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
>> >> >
>> >> > Not sure, maybe there is some historical reason?
>> >>
>> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>> >>
>> >> Conversion to list_head might be an interesting project for some "advanced
>> >> beginner" in the kernel :)
>> >
>> >I'm working to get rid of vm_prev and vm_next, so it would probably be
>> >wasted effort.
>>
>> You mean replace it with list_head?
>
>No, replace the rbtree with a new tree. https://lwn.net/Articles/787629/
Sounds interesting.
While I am not sure the plan is settled down, and how long it would take to
replace the rb_tree with maple tree. I guess it would probably take some time
to get merged upstream.
IMHO, it would be good to have this cleanup in current kernel. Do you agree?
--
Wei Yang
Help you, Help me
On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
> >> On 8/14/19 8:57 AM, Wei Yang wrote:
> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
> >> >
> >> > Not sure, maybe there is some historical reason?
> >>
> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
> >>
> >> Conversion to list_head might be an interesting project for some "advanced
> >> beginner" in the kernel :)
> >
> >I'm working to get rid of vm_prev and vm_next, so it would probably be
> >wasted effort.
>
> You mean replace it with list_head?
No, replace the rbtree with a new tree. https://lwn.net/Articles/787629/
On Wed, Aug 21, 2019 at 09:22:44AM +0800, Wei Yang wrote:
> On Tue, Aug 20, 2019 at 05:54:17PM -0700, Matthew Wilcox wrote:
> >On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
> >> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
> >> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
> >> >> On 8/14/19 8:57 AM, Wei Yang wrote:
> >> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
> >> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
> >> >> >
> >> >> > Not sure, maybe there is some historical reason?
> >> >>
> >> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
> >> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
> >> >>
> >> >> Conversion to list_head might be an interesting project for some "advanced
> >> >> beginner" in the kernel :)
> >> >
> >> >I'm working to get rid of vm_prev and vm_next, so it would probably be
> >> >wasted effort.
> >>
> >> You mean replace it with list_head?
> >
> >No, replace the rbtree with a new tree. https://lwn.net/Articles/787629/
>
> Sounds interesting.
>
> While I am not sure the plan is settled down, and how long it would take to
> replace the rb_tree with maple tree. I guess it would probably take some time
> to get merged upstream.
>
> IMHO, it would be good to have this cleanup in current kernel. Do you agree?
The three cleanups you've posted are fine. Doing more work (ie the
list_head) seems like wasted effort to me.
On Tue, Aug 20, 2019 at 06:59:39PM -0700, Matthew Wilcox wrote:
>On Wed, Aug 21, 2019 at 09:22:44AM +0800, Wei Yang wrote:
>> On Tue, Aug 20, 2019 at 05:54:17PM -0700, Matthew Wilcox wrote:
>> >On Wed, Aug 21, 2019 at 08:52:34AM +0800, Wei Yang wrote:
>> >> On Tue, Aug 20, 2019 at 10:26:29AM -0700, Matthew Wilcox wrote:
>> >> >On Wed, Aug 14, 2019 at 11:19:37AM +0200, Vlastimil Babka wrote:
>> >> >> On 8/14/19 8:57 AM, Wei Yang wrote:
>> >> >> > On Tue, Aug 13, 2019 at 10:16:11PM -0700, Christoph Hellwig wrote:
>> >> >> >>Btw, is there any good reason we don't use a list_head for vma linkage?
>> >> >> >
>> >> >> > Not sure, maybe there is some historical reason?
>> >> >>
>> >> >> Seems it was single-linked until 2010 commit 297c5eee3724 ("mm: make the vma
>> >> >> list be doubly linked") and I guess it was just simpler to add the vm_prev link.
>> >> >>
>> >> >> Conversion to list_head might be an interesting project for some "advanced
>> >> >> beginner" in the kernel :)
>> >> >
>> >> >I'm working to get rid of vm_prev and vm_next, so it would probably be
>> >> >wasted effort.
>> >>
>> >> You mean replace it with list_head?
>> >
>> >No, replace the rbtree with a new tree. https://lwn.net/Articles/787629/
>>
>> Sounds interesting.
>>
>> While I am not sure the plan is settled down, and how long it would take to
>> replace the rb_tree with maple tree. I guess it would probably take some time
>> to get merged upstream.
>>
>> IMHO, it would be good to have this cleanup in current kernel. Do you agree?
>
>The three cleanups you've posted are fine. Doing more work (ie the
>list_head) seems like wasted effort to me.
Ah, got your point. I misunderstand it.
--
Wei Yang
Help you, Help me