public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: mmap-rb-7 [was Re: /proc/<n>/maps growing...]
@ 2001-09-03 17:09 Manfred Spraul
  2001-09-03 17:20 ` Andrea Arcangeli
  0 siblings, 1 reply; 3+ messages in thread
From: Manfred Spraul @ 2001-09-03 17:09 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: torvalds, linux-kernel

> +/*
> + * vma->vm_start/vm_end cannot change under us because the caller is
required
> + * to hold the mmap_sem in write mode. We need to get the spinlock
only
> + * before relocating the vma range ourself.
> + */

There is one exception to that rule: a growable stack grows with
mmap_sem only acquired in read mode. vm_start can change on platforms
where the stack grows down, probably vm_end changes on platforms where
the stack grows upwards.

> - lock_vma_mappings(vma);
> - spin_lock(&vma->vm_mm->page_table_lock);
>  vma->vm_pgoff += (end - vma->vm_start) >> PAGE_SHIFT;
> + lock_vma_mappings(vma);
> + spin_lock(&mm->page_table_lock);
> vma->vm_start = end;

Could be wrong with concurrent stack faults.

--
    Manfred


^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: /proc/<n>/maps growing...
@ 2001-08-06 13:29 Andrea Arcangeli
  2001-08-06 17:27 ` Linus Torvalds
  0 siblings, 1 reply; 3+ messages in thread
From: Andrea Arcangeli @ 2001-08-06 13:29 UTC (permalink / raw)
  To: David S. Miller; +Cc: Chris Wedgwood, David Luyer, linux-kernel, Linus Torvalds

On Mon, Aug 06, 2001 at 06:06:14AM -0700, David S. Miller wrote:
> I wouldn't classify it as a horrible hack... but.

The part I find worse is that we just walk the tree two times.

I believe the best way is to allocate always the new vma, and to hide
the merging into the lowlevel of a new insert_vm_struct (with a special
function ala merge_segments that we can share with mprotect like in 2.2).

For example we could limit such special function to merge only the
anonymous mappings if we don't want to solve the locking issues (the
abortion), so it could remain simple but generic and optimized to avoid
walking the tree, allocating and freeing a slab cache is O(1) operation
when there's no memory pressore, much better than browsing a tree two
times at every malloc with a two liner that avoids hitting the
max_limit while we recall malloc. (of course for mremap we'll keep
browsing the tree twice but we cannot avoid that)

Andrea

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-09-03 17:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-03 17:09 mmap-rb-7 [was Re: /proc/<n>/maps growing...] Manfred Spraul
2001-09-03 17:20 ` Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2001-08-06 13:29 /proc/<n>/maps growing Andrea Arcangeli
2001-08-06 17:27 ` Linus Torvalds
2001-09-03 15:44   ` mmap-rb-7 [was Re: /proc/<n>/maps growing...] Andrea Arcangeli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox