All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Luebbe <jlu@pengutronix.de>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andy Lutomirski <luto@kernel.org>,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] proc: report eip and esp for all threads when coredumping
Date: Sun, 26 May 2019 21:41:28 +0200	[thread overview]
Message-ID: <87d0k5f1g7.fsf@linutronix.de> (raw)
In-Reply-To: <20190525143220.e771b7915d17f22dad1438fa@linux-foundation.org> (Andrew Morton's message of "Sat, 25 May 2019 14:32:20 -0700")

Hi Andrew,

On 2019-05-25, Andrew Morton <akpm@linux-foundation.org> wrote:
> Please send along a signed-off-by: for this?

From my response:

On 2019-05-25, John Ogness <john.ogness@linutronix.de> wrote:
> AFAICT core_state does not need to be set before the other lines. But
> there may be some side effects that I overlooked!

The changes I showed were more of a suggestion for Jan than an actual
patch. For a signed-off-by I'll need to do some deeper looking to make
sure what I suggested was safe. Also, we probably need a barrier to make
sure the task flag is cleared before setting core_state. Or instead, we
probably should set core_state after releasing the siglock, setting it
where the PF_DUMPCORE flag is set.

It seems to me that checking for a non-NULL core_state and checking for
the PF_DUMPCORE flag are both used throughout the kernel to identify
core dumps in action. So I think it makes sense to set them "at the same
time". (Or perhaps eliminate PF_DUMPCORE altogether and just use a
non-NULL core_state to identify core dumping.)

I will take a closer look at this.

John Ogness

  parent reply	other threads:[~2019-05-26 19:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 16:16 [PATCH] proc: report eip and esp for all threads when coredumping Jan Luebbe
2019-05-22 17:13 ` Alexey Dobriyan
2019-05-22 18:00 ` Andrew Morton
2019-05-23  8:15   ` Jan Lübbe
2019-05-24 23:50 ` John Ogness
     [not found]   ` <20190525143220.e771b7915d17f22dad1438fa@linux-foundation.org>
2019-05-26 19:41     ` John Ogness [this message]
2019-05-29  8:55       ` [PATCHv2] fs/proc: allow reporting eip/esp for all coredumping threads John Ogness
2019-05-29 21:55         ` Andrew Morton
2019-05-30  0:58         ` [PATCHv3] " John Ogness
2019-05-30  1:14           ` Andrew Morton
2019-06-03 19:54           ` Jan Lübbe

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=87d0k5f1g7.fsf@linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jlu@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    /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.