[PATCH origin/google/grte/v5-2.27/master] nptl: use mmap and munmap for stack allocation

[PATCH origin/google/grte/v5-2.27/master] nptl: use mmap and munmap for stack allocation

[Nilay Vaish]

[-- Attachment #1.1: Type: text/plain, Size: 243 bytes --]

We made this change so that we can capture thread stack allocations.
__mmap and __munmap cannot be overridden at runtime.  mmap and munmap
can be overidden at runtime and we are thus able to capture when either
of these functions were called.

[-- Attachment #2: 0001-nptl-use-mmap-and-munmap-for-stack-allocation.patch --]
[-- Type: text/x-patch, Size: 2238 bytes --]

From 17d684c996c880ffe1103d94a072dba8cdb52905 Mon Sep 17 00:00:00 2001
From: Nilay Vaish <nilayvaish@google.com>
Date: Sat, 22 Oct 2022 15:23:22 -0700
Subject: [PATCH origin/google/grte/v5-2.27/master] nptl: use mmap and munmap
 for stack allocation
To: libc-alpha@sourceware.org
Cc: maskray@google.com,
    dxf@google.com

We made this change so that we can capture thread stack allocations.
__mmap and __munmap cannot be overridden at runtime.  mmap and munmap
can be overidden at runtime and we are thus able to capture when either
of these functions were called.
---
 nptl/allocatestack.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/nptl/allocatestack.c b/nptl/allocatestack.c
index 9f6a75695e..1989ca7c86 100644
--- a/nptl/allocatestack.c
+++ b/nptl/allocatestack.c
@@ -276,7 +276,7 @@ __free_stacks (size_t limit)
 
 	  /* Remove this block.  This should never fail.  If it does
 	     something is really wrong.  */
-	  if (__munmap (curr->stackblock, curr->stackblock_size) != 0)
+	  if (munmap (curr->stackblock, curr->stackblock_size) != 0)
 	    abort ();
 
 	  /* Maybe we have freed enough.  */
@@ -558,7 +558,7 @@ allocate_stack (const struct pthread_attr *attr, struct pthread **pdp,
 	  /* If a guard page is required, avoid committing memory by first
 	     allocate with PROT_NONE and then reserve with required permission
 	     excluding the guard page.  */
-	  mem = __mmap (NULL, size, (guardsize == 0) ? prot : PROT_NONE,
+	  mem = mmap (NULL, size, (guardsize == 0) ? prot : PROT_NONE,
 			MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0);
 
 	  if (__glibc_unlikely (mem == MAP_FAILED))
@@ -585,7 +585,7 @@ allocate_stack (const struct pthread_attr *attr, struct pthread **pdp,
 					    pagesize_m1);
 	      if (setup_stack_prot (mem, size, guard, guardsize, prot) != 0)
 		{
-		  __munmap (mem, size);
+		  munmap (mem, size);
 		  return errno;
 		}
 	    }
@@ -628,7 +628,7 @@ allocate_stack (const struct pthread_attr *attr, struct pthread **pdp,
 	      assert (errno == ENOMEM);
 
 	      /* Free the stack memory we just allocated.  */
-	      (void) __munmap (mem, size);
+	      (void) munmap (mem, size);
 
 	      return errno;
 	    }
-- 
2.38.0.135.g90850a2211-goog

Re: [PATCH origin/google/grte/v5-2.27/master] nptl: use mmap and munmap for stack allocation

[Florian Weimer]

* Nilay Vaish via Libc-alpha:

> We made this change so that we can capture thread stack allocations.
> __mmap and __munmap cannot be overridden at runtime.  mmap and munmap
> can be overidden at runtime and we are thus able to capture when either
> of these functions were called.

Not sure if you are proposing this for general discussion?

This will need localplt.data updates on all architectures to avoid
check-localplt failures.  It also introduces a linknamespace issue with
C11 thread support: technically, an application using C11 threads could
define mmap or munmap symbols for arbitrary use (and different behavior)
because those names are not reserved in C11.

If this is intended to become a supported interface, perhaps we should
document it in the manual.  On the other hand, I do not see how this
could work in general, especially not with static linking.  glibc may
have to call mmap in certain places where the process or thread is not
fully initialized.

Thanks,
Florian

Re: [PATCH origin/google/grte/v5-2.27/master] nptl: use mmap and munmap for stack allocation

[Nilay Vaish]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Hi Florian, this patch is only meant for the google/grte branch.

Thanks!

On Wed, Oct 26, 2022 at 12:37 AM Florian Weimer <fweimer@redhat.com> wrote:

> * Nilay Vaish via Libc-alpha:
>
> > We made this change so that we can capture thread stack allocations.
> > __mmap and __munmap cannot be overridden at runtime.  mmap and munmap
> > can be overidden at runtime and we are thus able to capture when either
> > of these functions were called.
>
> Not sure if you are proposing this for general discussion?
>
> This will need localplt.data updates on all architectures to avoid
> check-localplt failures.  It also introduces a linknamespace issue with
> C11 thread support: technically, an application using C11 threads could
> define mmap or munmap symbols for arbitrary use (and different behavior)
> because those names are not reserved in C11.
>
> If this is intended to become a supported interface, perhaps we should
> document it in the manual.  On the other hand, I do not see how this
> could work in general, especially not with static linking.  glibc may
> have to call mmap in certain places where the process or thread is not
> fully initialized.
>
> Thanks,
> Florian
>
>