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 (structJL> 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 isavailable for process and high 1GiB is for kernel. WHERE you'll put your"address space (struct vm)" ? Below 3GiB ? There are old process addressspaces (before point of no return that is; and after point of no returnthere are NO execve arguments available anymore) and they can fill all thisspace. 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 somewhereJL> and arrange for the vmscan code to scan it just like the other mms. (AJL> linked list of mms might be useful for another reason: so that vmscanJL> 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 surgicaloperation over linux's memory manager then you want to do if you want justexpand 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 youJL> 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 arrangeJL> for that to take a long time.

NO! They are locked only till type of file is determined and "point of noreturn is reached". It still can be long, of course.

JL> It doesn't have to be larger than RAM. Just 10 concurrent 10MBJL> attempted execves would be a DOS on most systems. You could limit it inJL> the same way that a limit on lockable user pages has been proposedJL> generally.

Are you looked on patch at all ? I've NOT removed limit. I just made itconfigurable at run-time (only root can do this obviously). And root is notsupposed to be stupid, you know...

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/