This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] NPTL proposed large page fix for pthread_create.


Steven Munroe wrote:
+	{
+	/* The stack is too small (or the guard too large), but this might not
+	   be an error.  If we are on a system that supports multiple page
+	   sizes,  the current page size may be larger then PTHREAD_STACK_MIN,
+	   but we need to allocate a minimum of two pages for guard and stack.
+	   In this case we can allocate the two page minimum.  */
+	  if ((size >= PTHREAD_STACK_MIN)
+	    && (PTHREAD_STACK_MIN< ((pagesize_m1 + 1)  * 2)))
+	    /* The requested size is >= PTHREAD_STACK_MIN,  so the application
+	       expect this to work. But PTHREAD_STACK_MIN is < 2 of the
+	       current pages,  so bump the stack size up to two pages at the
+	       current page size.  */
+	    size = (pagesize_m1 + 1) * 2;
+	  else
+	    /* Not the large page case so return EINVAL.  */
+	    return EINVAL;
+	}

This is completely bogus. The if expression change is OK, but if the stack is too small, it is too small. Why on earth would you think that if the test for the minimally required stack size fails you can just add a test like this to work around it? This second test is completely independent of the actual size needed.


If the modified test I checked in fails there is *nothing* which can be done. There is no negotiating about the required stack size. You cannot just ignore this fact. If all this means programs which work with normal page sizes now fail, then that's a sad outcome. Just another piece of evidence of the poor ABI design.


And as usual, you completely ignore the coding conventions. Well, I can ignore, too. I'll ignore every patch you sent which does not use the correct coding conventions.


--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]