On Wed, Jan 16, 2002 at 04:32:59PM +0100, Erik Mouw wrote: > > OK, I was gonna say 'I dunno' but, looking closer at it, it looks like it > > handles the cases where we were called from an invalid ds or es, or if we can't > > iret (bad cs/esp/ss/eip/whatever). In the first 2, it just writes 0 to them, in > > the last case, it kills the process. yep. but what I don't understand is why. Remember these values were saved on to the stack using SAVE_ALL during the entry point. So when did they become bad ? eip would make perfect sense I guess (e.g. unmapping that text page) but I don't see how the segment registers etc. could get corrupted. > In the old days you had to call verify_area() before you touched a > userland buffer with copy_from_user() et. al. That was slow because the > kernel actually checked the process memory space to see if the memory > was valid, and in 99% of the cases the memory *was* indeed safe to > access. That made it a prime candidate for speeding up, and the > __ex_table section magic exactly did that. > > I think you can still find the magic explained in a linux-kernel It's not this case, the exception table for that is actually in __copy_to_user itself (I get that bit ;) regards john regards john -- "Now why did you have to go and mess up the child's head, so you can get another gold waterbed ? You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ..." -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
