Messages in this thread | | | Date | Tue, 27 Jun 2006 18:07:23 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] binfmt: turn MAX_ARG_PAGES into a sysctl tunable |
| |
On Tue, 27 Jun 2006, Ingo Molnar wrote: > > at copy_strings_kernel() time we dont yet know where in the target VM to > install the pages. A binformat might want to install all sorts of stuff > on the stack first, before it constructs the envp and copies the strings > themselves. So we dont know the precise alignment needed. > > delaying the copying to setup_arg_pages() time does not seem to work > either, because that gets called after the old MM has been destroyed.
Well, I think we could just change the place the MM is destroyed. We shouldn't destroy it until we're done with it ;)
However, I don't think that actually matters. The only thing we _need_ to know is what the stack top is going to be, and we know that fairly early. The fact that we _also_ add various magic flags onto the stack is independent of copying the strings themselves, since the flags ordering is not actually something that matters for the _strings_, but for the actual setup of the pointers _to_ the strings.
And that's actually where we could potentially be better off without the current page[] array, because we could just do it using the user space image (and the hardware support for a TLB) itself rather than walk the array by hand.
I don't think it's a huge deal. In the end, we'll have to put a limit on the argument space _somewhere_. I don't like the current page[] array, and it's silly to make the limit so low, but on the other hand, in order to avoid excessive time in the kernel by badly behaved apps, and because any good application _needs_ to be able to handle the limited argument space anyway, I actually suspect it really doesn't matter in the end.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |