On Wed, 2013-10-23 at 02:53 -0700, wal...@google.com wrote:
> On Sun, Oct 20, 2013 at 08:26:15PM -0700, Davidlohr Bueso wrote:
> > From: Davidlohr Bueso
> > Subject: [PATCH v2 3/3] vdso: preallocate new vmas
> >
> > With the exception of um and tile, architectures that use
> > the install_special
On Sun, Oct 20, 2013 at 08:26:15PM -0700, Davidlohr Bueso wrote:
> From: Davidlohr Bueso
> Subject: [PATCH v2 3/3] vdso: preallocate new vmas
>
> With the exception of um and tile, architectures that use
> the install_special_mapping() function, when setting up a
> new vma at program startup, do
From: Davidlohr Bueso
Subject: [PATCH v2 3/3] vdso: preallocate new vmas
With the exception of um and tile, architectures that use
the install_special_mapping() function, when setting up a
new vma at program startup, do so with the mmap_sem lock
held for writing. Unless there's an error, this pro
Am 18.10.2013 02:50, schrieb Davidlohr Bueso:
> With the exception of um and tile, architectures that use
> the install_special_mapping() function, when setting up a
> new vma at program startup, do so with the mmap_sem lock
> held for writing. Unless there's an error, this process
> ends up alloca
This seems somewhat insane:
int install_special_mapping(struct mm_struct *mm,
unsigned long addr, unsigned long len,
+ unsigned long vm_flags, struct page **pages,
+ struct vm_area_struct **vma_prealloc)
{
With the exception of um and tile, architectures that use
the install_special_mapping() function, when setting up a
new vma at program startup, do so with the mmap_sem lock
held for writing. Unless there's an error, this process
ends up allocating a new vma through kmem_cache_zalloc,
and inserting
6 matches
Mail list logo
