Peter Wemm wrote: > > Note that this assumes none of the stack is used elsewhere; in the > > kernel example, ther is slightly over 3K used, on average, by the > > time you get to run. > > FWIW; This isn't correct for -current anymore. We have about 7.6K > of kernel stack now, and a guard page below it to force a double fault > in case of an oveflow. The pcb is above the kernel stack now, and the > user area is completely seperate.
That's a valid correction, though it's probably a mistake to take it as meaningful to the base question. I was aware that that had been changed in -current; I didn't know if auto-grow was supported (I thought it wasn't), and it wasn't a general answer (I probably should have not added the parenthetical aside about the FreeBSD specific 64MB user stack limit, actually). The point was supposed to be that if the question was asked in the context of wanting to use a lot of stack space, then there was a fundamental flaw in the design of the code involved. In general, it's bad to use stack if the only reason you are using it is to seperate context, which is the point I was trying to make. OpenSSL takes this one level worse, and uses stack to avoid the allocation and deallocation of context structures that are copies of context structures translated to parameters, and back (one could make a similar criticism of the FreeBSD VFS descriptor mechanism, but at least there was a valid design reason for that one 8-)). I guess I could offer the alternative argument that buffers that are allocated on the stack are subject to overflow in order to get malicious code to execute... and that avoiding such allocations makes such attacks much harder. The stack is really a necessary evil to handle the call graph; abusing it for other reasons makes my teeth itch. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
