From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
To: Mark Gross <mgross@unix-os.sc.intel.com>
Cc: "Gross, Mark" <mark.gross@intel.com>,
"'Erich Focht'" <efocht@ess.nec.de>,
"'linux-kernel'" <linux-kernel@vger.kernel.org>,
"'Robert Love'" <rml@tech9.net>,
"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
"Luck, Tony" <tony.luck@intel.com>
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.
Date: Wed, 22 May 2002 20:12:18 -0500 [thread overview]
Message-ID: <20020522201218.B16554@crack.them.org> (raw)
In-Reply-To: <59885C5E3098D511AD690002A5072D3C057B489B@orsmsx111.jf.intel.com> <20020522183246.B16176@crack.them.org> <200205230009.g4N09Ow08254@unix-os.sc.intel.com>
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
next prev parent reply other threads:[~2002-05-23 1:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-21 23:08 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 Gross, Mark
2002-05-22 7:56 ` Vamsi Krishna S.
2002-05-22 14:11 ` Pavel Machek
2002-05-22 14:17 ` Pavel Machek
2002-05-22 17:43 ` Mark Gross
2002-05-22 19:22 ` Pavel Machek
2002-05-23 21:03 ` Martin Dalecki
2002-05-23 22:27 ` Pavel Machek
2002-05-22 22:07 ` PATCH Multithreaded core dumps for the 2.5.17 kernel was ....RE: PATCH Multithreaded core dump support for the 2.5.14 (aO Alan Cox
2002-05-22 23:29 ` Daniel Jacobowitz
2002-05-23 10:07 ` Pavel Machek
2002-05-22 23:32 ` 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 Daniel Jacobowitz
2002-05-22 21:09 ` Mark Gross
2002-05-23 1:12 ` Daniel Jacobowitz [this message]
2002-05-23 13:12 ` Mark Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020522201218.B16554@crack.them.org \
--to=dmj+@andrew.cmu.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=efocht@ess.nec.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.gross@intel.com \
--cc=mgross@unix-os.sc.intel.com \
--cc=rml@tech9.net \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.