Messages in this thread |  | | Date | Wed, 22 May 2002 20:12:18 -0500 | From | Daniel Jacobowitz <> | Subject | Re: PATCH Multithreaded core dumps for the 2.5.17 kernel was ....RE: PATCH Multithreaded core dump support for the 2.5.14 (and 15) kernel. |
| |
On Wed, May 22, 2002 at 05:09:01PM -0400, Mark Gross wrote: > On Wednesday 22 May 2002 07:32 pm, Daniel Jacobowitz wrote: > > > > What about other things which take mmap_sem? I believe at least ptrace > > is involved. The notion of avoiding taking a semaphore like this is a > > somewhat risky one. > > Yes access_process_vm down_writes the mmap_sem. However; it can only read > and write to existing user pages. As long as it doesn't delete any of them > its not a problem. It won't cause a dead lock or panic during the core dump > processing if this happens. > > The only process I know that could honestly use this ptrace function is GDB > doing live debugging. > > > > > Why shouldn't you take the semaphore as before in elf_core_dump, if you > > know that no suspended process has it - which you do if you hold it > > while suspending them? > > For Ia64 those down_writes are just a pain. If a user application is > crashing because someone is being rude with GDB corrupting its user pages > then I don't think its worth the hassle of protecting the core dumped user > page mm data from being messed up by a GDB user. > > I would like to leave the down_write out of elf_core_dump, but it could be > put back if its felt that its needed. > > Opinions? Comments?
I'm not worried about the application crashing. I'm worried about oopsing if someone is poking at the mmap_sem while we are pretending to have it. If that is not a valid concern, there should at least be a big red flag saying so.
-- Daniel Jacobowitz Debian GNU/Linux Developer MontaVista Software Carnegie Mellon University - 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/
|  |