Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sun, 5 Mar 2000 19:08:11 +0300 (MSK) | Subject | Re: [FIX] Re: Argument list too long: out of environment space |
| |
In <20000305123822.B3138@pcep-jamie.cern.ch> Jamie Lokier (lk@tantalophile.demon.co.uk) wrote: JL> Khimenko Victor wrote: >> > Feel free to remove the limit altogether and make it dynamic. Something >> > involving an extra struct mm which you are filling up ptrace-style might >> > be appropriate. It must be pageable if it can be arbitrarily large. >> >> Is it really needed ? This is HARD problem. Since you need to keep in >> one address space both arguments passed to execve and new argv >> array. You can try to scan source arguments and make clever rearrange >> of strings in memory (this is not simple: think about something like >> execl("bin/echo",plong_string,plong_string+10,0); for example) or you >> can just clone current process and move agruments from one process to >> another... Both ways looks EXTREMALLY hairy to me and not needed in >> most cases
JL> There's a much simpler method. Just create a new address space (struct JL> mm) and copy into it the same way as ptrace does.
1. What "ptrace does" ? Where is code you are reffering to ? 2. I can be wrong but AFAIK kernel memory is split this way: low 3GiB is available for process and high 1GiB is for kernel. WHERE you'll put your "address space (struct vm)" ? Below 3GiB ? There are old process address spaces (before point of no return that is; and after point of no return there are NO execve arguments available anymore) and they can fill all this space. Above 3GiB ? It's kernel space and it's not designed to be swapable. I'm not sure if kernel can survive if you'll create swapable "struct vm" there but you'll get LOTS of interesting problems for sure.
JL> To make it pageable, simply store the address of the new mm somewhere JL> and arrange for the vmscan code to scan it just like the other mms. (A JL> linked list of mms might be useful for another reason: so that vmscan JL> doesn't repeatedly scan the same mm when it is shared between threads).
Yes, you can do this. In theory. On practice it's MUCH more deep surgical operation over linux's memory manager then you want to do if you want just expand limit for number of arguments.
>> (of course ability to sucessfully call execve with argv >> bigger then amount of RAM in system is sexy but how often it's really >> needed?).
JL> If you remove the argv limit but don't make execve pageable, then you JL> have a DOS attack. A nasty one: you can lock XXX megabytes instantly. JL> The pages are locked until the new file is mapped, and you can arrange JL> for that to take a long time.
NO! They are locked only till type of file is determined and "point of no return is reached". It still can be long, of course.
JL> It doesn't have to be larger than RAM. Just 10 concurrent 10MB JL> attempted execves would be a DOS on most systems. You could limit it in JL> the same way that a limit on lockable user pages has been proposed JL> generally.
Are you looked on patch at all ? I've NOT removed limit. I just made it configurable at run-time (only root can do this obviously). And root is not supposed to be stupid, you know...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |